Repository navigation
Sync upstream/main (2026-01-04) - #141
Conversation
# Terminal Detection Metadata for Per-Terminal Scroll Scaling
## Summary
Expand terminal detection into structured metadata (`TerminalInfo`) with
multiplexer awareness, plus a testable environment shim and
characterization tests.
## Context / Motivation
- TUI2 owns its viewport and scrolling model (see
`codex-rs/tui2/docs/tui_viewport_and_history.md`), so scroll behavior
must be consistent across terminals and independent of terminal
scrollback quirks.
- Prior investigations show mouse wheel scroll deltas vary noticeably by
terminal. To tune scroll scaling (line increments per wheel tick) we
need reliable terminal identification, including when running inside
tmux/zellij.
- tmux is especially tricky because it can mask the underlying terminal;
we now consult `tmux display-message` client termtype/name to attribute
sessions to the actual terminal rather than tmux itself.
- This remains backwards compatible with the existing OpenTelemetry
user-agent token because `user_agent()` is still derived from the same
environment signals (now via `TerminalInfo`).
## Changes
- Introduce `TerminalInfo`, `TerminalName`, and `Multiplexer` with
`TERM_PROGRAM`/`TERM`/multiplexer detection and user-agent formatting in
`codex-rs/core/src/terminal.rs`.
- Add an injectable `Environment` trait + `FakeEnvironment` for testing,
and comprehensive characterization tests covering known terminals, tmux
client termtype/name, and zellij.
- Document module usage and detection order; update `terminal_info()` to
be the primary interface for callers.
## Testing
- `cargo test -p codex-core terminal::tests`
- manually checked ghostty, iTerm2, Terminal.app, vscode, tmux, zellij,
Warp, alacritty, kitty.
```
2025-12-18T07:07:49.191421Z INFO Detected terminal info terminal=TerminalInfo { name: Iterm2, term_program: Some("iTerm.app"), version: Some("3.6.6"), term: None, multiplexer: None }
2025-12-18T07:07:57.991776Z INFO Detected terminal info terminal=TerminalInfo { name: AppleTerminal, term_program: Some("Apple_Terminal"), version: Some("455.1"), term: None, multiplexer: None }
2025-12-18T07:08:07.732095Z INFO Detected terminal info terminal=TerminalInfo { name: WarpTerminal, term_program: Some("WarpTerminal"), version: Some("v0.2025.12.10.08.12.stable_03"), term: None, multiplexer: None }
2025-12-18T07:08:24.860316Z INFO Detected terminal info terminal=TerminalInfo { name: Kitty, term_program: None, version: None, term: None, multiplexer: None }
2025-12-18T07:08:38.302761Z INFO Detected terminal info terminal=TerminalInfo { name: Alacritty, term_program: None, version: None, term: None, multiplexer: None }
2025-12-18T07:08:50.887748Z INFO Detected terminal info terminal=TerminalInfo { name: VsCode, term_program: Some("vscode"), version: Some("1.107.1"), term: None, multiplexer: None }
2025-12-18T07:10:01.309802Z INFO Detected terminal info terminal=TerminalInfo { name: WezTerm, term_program: Some("WezTerm"), version: Some("20240203-110809-5046fc22"), term: None, multiplexer: None }
2025-12-18T08:05:17.009271Z INFO Detected terminal info terminal=TerminalInfo { name: Ghostty, term_program: Some("ghostty"), version: Some("1.2.3"), term: None, multiplexer: None }
2025-12-18T08:05:23.819973Z INFO Detected terminal info terminal=TerminalInfo { name: Ghostty, term_program: Some("ghostty"), version: Some("1.2.3"), term: Some("xterm-ghostty"), multiplexer: Some(Tmux { version: Some("3.6a") }) }
2025-12-18T08:05:35.572853Z INFO Detected terminal info terminal=TerminalInfo { name: Ghostty, term_program: Some("ghostty"), version: Some("1.2.3"), term: None, multiplexer: Some(Zellij) }
```
## Notes / Follow-ups
- Next step is to wire `TerminalInfo` into TUI2’s scroll scaling
configuration and add a per-terminal tuning table.
- The log output in TUI2 helps validate real-world detection before
applying behavior changes.
…280) this fixes sandbox errors (legacy and elevated) for commands that include pipes, which the model often favors.
See snapshots for view of edge cases This is still named `UnifiedExecSessions` for consistency across the code but should be renamed to `BackgroundTerminals` in a follow-up Example: <img width="945" height="687" alt="Screenshot 2025-12-18 at 20 12 53" src="https://github.com/user-attachments/assets/92f39ff2-243c-4006-b402-e3fa9e93c952" />
This implements the new config design where config _requirements_ are loaded separately (and with a special schema) as compared to config _settings_. In particular, on UNIX, with this PR, you could define `/etc/codex/requirements.toml` with: ```toml allowed_approval_policies = ["never", "on-request"] ``` to enforce that `Config.approval_policy` must be one of those two values when Codex runs. We plan to expand the set of things that can be restricted by `/etc/codex/requirements.toml` in short order. Note that requirements can come from several sources: - new MDM key on macOS (not implemented yet) - `/etc/codex/requirements.toml` - re-interpretation of legacy MDM key on macOS (`com.openai.codex/config_toml_base64`) - re-interpretation of legacy `/etc/codex/managed_config.toml` So our resolution strategy is to load TOML data from those sources, in order. Later TOMLs are "merged" into previous TOMLs, but any field that is already set cannot be overwritten. See `ConfigRequirementsToml::merge_unset_fields()`.
Add a v2 event for deprecation notices so we can get rid of `codex/event/deprecation_notice`.
<img width="200" alt="7ff2254b-e96f-42fc-8232-b4e76cb26248" src="https://github.com/user-attachments/assets/1f56799d-e2cd-4b69-9290-854943f7c6b6" />
Version `0.12.0` includes modelcontextprotocol/rust-sdk#590, which I will use in openai/codex#8142. Changes: - `rmcp::model::CustomClientNotification` was renamed to `rmcp::model::CustomNotification` - a bunch of types have a `meta` field now, but it is `Option`, so I added `meta: None` to a bunch of things
Allow SKILL.md to specify a more human-readable short description as skill metadata.
…st (#8142) Historically, `accept_elicitation_for_prompt_rule()` was flaky because we were using a notification to update the sandbox followed by a `shell` tool request that we expected to be subject to the new sandbox config, but because [rmcp](https://crates.io/crates/rmcp) MCP servers delegate each incoming message to a new Tokio task, messages are not guaranteed to be processed in order, so sometimes the `shell` tool call would run before the notification was processed. Prior to this PR, we relied on a generous `sleep()` between the notification and the request to reduce the change of the test flaking out. This PR implements a proper fix, which is to use a _request_ instead of a notification for the sandbox update so that we can wait for the response to the sandbox request before sending the request to the `shell` tool call. Previously, `rmcp` did not support custom requests, but I fixed that in modelcontextprotocol/rust-sdk#590, which made it into the `0.12.0` release (see #8288). This PR updates `shell-tool-mcp` to expect `"codex/sandbox-state/update"` as a _request_ instead of a notification and sends the appropriate ack. Note this behavior is tied to our custom `codex/sandbox-state` capability, which Codex honors as an MCP client, which is why `core/src/mcp_connection_manager.rs` had to be updated as part of this PR, as well. This PR also updates the docs at `shell-tool-mcp/README.md`.
regression: #8199 Signed-off-by: Koichi Shiraishi <zchee.io@gmail.com>
…onfigBuilder (#8276) openai/codex#8235 introduced `ConfigBuilder` and this PR updates all call non-test call sites to use it instead of `Config::load_from_base_config_with_overrides()`. This is important because `load_from_base_config_with_overrides()` uses an empty `ConfigRequirements`, which is a reasonable default for testing so the tests are not influenced by the settings on the host. This method is now guarded by `#[cfg(test)]` so it cannot be used by business logic. Because `ConfigBuilder::build()` is `async`, many of the test methods had to be migrated to be `async`, as well. On the bright side, this made it possible to eliminate a bunch of `block_on_future()` stuff.
## Description
Introduced `ExternalSandbox` policy to cover use case when sandbox
defined by outside environment, effectively it translates to
`SandboxMode#DangerFullAccess` for file system (since sandbox configured
on container level) and configurable `network_access` (either Restricted
or Enabled by outside environment).
as example you can configure `ExternalSandbox` policy as part of
`sendUserTurn` v1 app_server API:
```
{
"conversationId": <id>,
"cwd": <cwd>,
"approvalPolicy": "never",
"sandboxPolicy": {
"type": ""external-sandbox",
"network_access": "enabled"/"restricted"
},
"model": <model>,
"effort": <effort>,
....
}
```
Screenshots here but check the snapshot files to see it better <img width="712" height="408" alt="Screenshot 2025-12-18 at 11 58 02" src="https://github.com/user-attachments/assets/84a2c410-0767-4870-84d1-ae1c0d4c445e" /> <img width="523" height="352" alt="Screenshot 2025-12-18 at 11 17 41" src="https://github.com/user-attachments/assets/d029c7ea-0feb-4493-9dca-af43a0c70c52" />
Only display the skill name (not the folder), and truncate the skill description to a maximum of two lines.
Fix broken tests.
skills default on.
a new scope reads from /etc/codex
We were assembling the skill roots in two different places, and the admin root was missing in one of them. This change centralizes root selection into a helper so both paths stay in sync.
Keep windows OFF first.
# External (non-OpenAI) Pull Request Requirements Before opening this Pull Request, please read the dedicated "Contributing" markdown file or your PR may be closed: https://github.com/openai/codex/blob/main/docs/contributing.md If your PR conforms to our contribution guidelines, replace this text with a detailed and high quality description of your changes. Include a link to a bug report or enhancement request.
Fixes #8214 by removing the '--staged' flag from the undo git restore command. This ensures that while the working tree is reverted to the snapshot state, the user's staged changes (index) are preserved, preventing data loss. Also adds a regression test.
This will make it easier to test for expected errors in unit tests since we can compare based on the field values rather than the message (which might change over time). See openai/codex#8298 for an example. It also ensures more consistency in the way a `ConstraintError` is constructed.
This test was introduced in openai/codex#6507, but was not included in `mod.rs`. It does not appear that it was getting compiled?
Automated update of models.json. Co-authored-by: aibrahim-oai <219906144+aibrahim-oai@users.noreply.github.com>
Load managed requirements from MDM key `requirements_toml_base64`.
Tested on my Mac (using `defaults` to set the preference, though this
would be set by MDM in production):
```
➜ codex git:(gt/mdm-requirements) defaults read com.openai.codex requirements_toml_base64 | base64 -d
allowed_approval_policies = ["on-request"]
➜ codex git:(gt/mdm-requirements) just c --yolo
cargo run --bin codex -- "$@"
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.26s
Running `target/debug/codex --yolo`
Error loading configuration: value `Never` is not in the allowed set [OnRequest]
error: Recipe `codex` failed on line 11 with exit code 1
➜ codex git:(gt/mdm-requirements) defaults delete com.openai.codex requirements_toml_base64
➜ codex git:(gt/mdm-requirements) just c --yolo
cargo run --bin codex -- "$@"
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.24s
Running `target/debug/codex --yolo`
╭──────────────────────────────────────────────────────────╮
│ >_ OpenAI Codex (v0.0.0) │
│ │
│ model: codex-auto-balanced medium /model to change │
│ directory: ~/code/codex/codex-rs │
╰──────────────────────────────────────────────────────────╯
Tip: Start a fresh idea with /new; the previous session stays in history.
```
What changed
- Added `outputSchema` support to the app-server APIs, mirroring `codex
exec --output-schema` behavior.
- V1 `sendUserTurn` now accepts `outputSchema` and constrains the final
assistant message for that turn.
- V2 `turn/start` now accepts `outputSchema` and constrains the final
assistant message for that turn (explicitly per-turn only).
Core behavior
- `Op::UserTurn` already supported `final_output_json_schema`; now V1
`sendUserTurn` forwards `outputSchema` into that field.
- `Op::UserInput` now carries `final_output_json_schema` for per-turn
settings updates; core maps it into
`SessionSettingsUpdate.final_output_json_schema` so it applies to the
created turn context.
- V2 `turn/start` does NOT persist the schema via `OverrideTurnContext`
(it’s applied only for the current turn). Other overrides
(cwd/model/etc) keep their existing persistent behavior.
API / docs
- `codex-rs/app-server-protocol/src/protocol/v1.rs`: add `output_schema:
Option<serde_json::Value>` to `SendUserTurnParams` (serialized as
`outputSchema`).
- `codex-rs/app-server-protocol/src/protocol/v2.rs`: add `output_schema:
Option<JsonValue>` to `TurnStartParams` (serialized as `outputSchema`).
- `codex-rs/app-server/README.md`: document `outputSchema` for
`turn/start` and clarify it applies only to the current turn.
- `codex-rs/docs/codex_mcp_interface.md`: document `outputSchema` for v1
`sendUserTurn` and v2 `turn/start`.
Tests added/updated
- New app-server integration tests asserting `outputSchema` is forwarded
into outbound `/responses` requests as `text.format`:
- `codex-rs/app-server/tests/suite/output_schema.rs`
- `codex-rs/app-server/tests/suite/v2/output_schema.rs`
- Added per-turn semantics tests (schema does not leak to the next
turn):
- `send_user_turn_output_schema_is_per_turn_v1`
- `turn_start_output_schema_is_per_turn_v2`
- Added protocol wire-compat tests for the merged op:
- serialize omits `final_output_json_schema` when `None`
- deserialize works when field is missing
- serialize includes `final_output_json_schema` when `Some(schema)`
Call site updates (high level)
- Updated all `Op::UserInput { .. }` constructions to include
`final_output_json_schema`:
- `codex-rs/app-server/src/codex_message_processor.rs`
- `codex-rs/core/src/codex_delegate.rs`
- `codex-rs/mcp-server/src/codex_tool_runner.rs`
- `codex-rs/tui/src/chatwidget.rs`
- `codex-rs/tui2/src/chatwidget.rs`
- plus impacted core tests.
Validation
- `just fmt`
- `cargo test -p codex-core`
- `cargo test -p codex-app-server`
- `cargo test -p codex-mcp-server`
- `cargo test -p codex-tui`
- `cargo test -p codex-tui2`
- `cargo test -p codex-protocol`
- `cargo clippy --all-features --tests --profile dev --fix -- -D
warnings`
… (#8686) make sure if the Sandbox has to re-initialize with different Sandbox user SID, it still finds/updates the firewall rule instead of creating a new one.
Never treat .codex or .codex/.sandbox as a workspace root. Handle write permissions to .codex/.sandbox in a single method so that the sandbox setup/runner can write logs and other setup files to that directory.
This change improves the skills render section - Separate the skills list from usage rules with clear subheadings - Define skill more clearly upfront - Remove confusing trigger/discovery wording and make reference-following guidance more actionable
## Summary When using device-code login with a custom issuer (`--experimental_issuer`), Codex correctly uses that issuer for the auth flow — but the **terminal prompt still told users to open the default OpenAI device URL** (`https://auth.openai.com/codex/device`). That’s confusing and can send users to the **wrong domain** (especially for enterprise/staging issuers). This PR updates the prompt (and related URLs) to consistently use the configured issuer. 🎯 --- ## 🔧 What changed * 🔗 **Device auth prompt link** now uses the configured issuer (instead of a hard-coded OpenAI URL) * 🧭 **Redirect callback URL** is derived from the same issuer for consistency * 🧼 Minor cleanup: normalize the issuer base URL once and reuse it (avoids formatting quirks like trailing `/`) --- ## 🧪 Repro + Before/After ###▶️ Command ```bash codex login --device-auth --experimental_issuer https://auth.example.com ``` ### ❌ Before (wrong link shown) ```text 1. Open this link in your browser and sign in to your account https://auth.openai.com/codex/device ``` ### ✅ After (correct link shown) ```text 1. Open this link in your browser and sign in to your account https://auth.example.com/codex/device ``` Full example output (same as before, but with the correct URL): ```text Welcome to Codex [v0.72.0] OpenAI's command-line coding agent Follow these steps to sign in with ChatGPT using device code authorization: 1. Open this link in your browser and sign in to your account https://auth.example.com/codex/device 2. Enter this one-time code (expires in 15 minutes) BUT6-0M8K4 Device codes are a common phishing target. Never share this code. ``` --- ## ✅ Test plan * 🟦 `codex login --device-auth` (default issuer): output remains unchanged * 🟩 `codex login --device-auth --experimental_issuer https://auth.example.com`: * prompt link points to the issuer ✅ * callback URL is derived from the same issuer ✅ * no double slashes / mismatched domains ✅ Co-authored-by: Eric Traut <etraut@openai.com>
The elevated sandbox creates two new Windows users - CodexSandboxOffline and CodexSandboxOnline. This is necessary, so this PR does all that it can to "hide" those users. It uses the registry plus directory flags (on their home directories) to get them to show up as little as possible.
Adds an optional `justification` parameter to the `prefix_rule()`
execpolicy DSL so policy authors can attach human-readable rationale to
a rule. That justification is propagated through parsing/matching and
can be surfaced to the model (or approval UI) when a command is blocked
or requires approval.
When a command is rejected (or gated behind approval) due to policy, a
generic message makes it hard for the model/user to understand what went
wrong and what to do instead. Allowing policy authors to supply a short
justification improves debuggability and helps guide the model toward
compliant alternatives.
Example:
```python
prefix_rule(
pattern = ["git", "push"],
decision = "forbidden",
justification = "pushing is blocked in this repo",
)
```
If Codex tried to run `git push origin main`, now the failure would
include:
```
`git push origin main` rejected: pushing is blocked in this repo
```
whereas previously, all it was told was:
```
execpolicy forbids this command
```
|
Update: merged latest upstream/main (as of 2026-01-05) into this branch.\n\nChanges since initial PR: \n- Merge upstream/main (commit 3ff5b72)\n- rustfmt follow-up for seatbelt tests (commit c118d75)\n\nLocal validation: \n- codex-rs: just fmt; just fix -p codex-core; cargo test -p codex-core --tests (with a couple flaky long-running suites manually interrupted; key seatbelt + remote_models + verbosity tests re-run individually).\n- sdk/native: pnpm install; pnpm run build; pnpm test (in progress; fast-embed downloads model on first run and is slow on macOS). |
…753) We've seen reports that people who try to login on a remote/headless machine will open the login link on their own machine and got errors. Update the instructions to ask those users to use `codex login --device-auth` instead. <img width="1434" height="938" alt="CleanShot 2026-01-05 at 11 35 02@2x" src="https://github.com/user-attachments/assets/2b209953-6a42-4eb0-8b55-bb0733f2e373" />
Use ConfigLayerStack to get all folders while loading skills.
… (#8440) **Motivation** - Bring `codex exec resume` to parity with top‑level flags so global options (git check bypass, json, model, sandbox toggles) work after the subcommand, including when outside a git repo. **Description** - Exec CLI: mark `--skip-git-repo-check`, `--json`, `--model`, `--full-auto`, and `--dangerously-bypass-approvals-and-sandbox` as global so they’re accepted after `resume`. - Tests: add `exec_resume_accepts_global_flags_after_subcommand` to verify those flags work when passed after `resume`. **Testing** - `just fmt` - `cargo test -p codex-exec` (pass; ran with elevated perms to allow network/port binds) - Manual: exercised `codex exec resume` with global flags after the subcommand to confirm behavior.
|
More validation (2026-01-05):
Note: pnpm run test (which runs cargo test --workspace --all-features) can hit an intermittent hang in codex-core --test all during shutdown; tests appear to finish but the process sometimes doesn’t exit. Targeted nextest + SDK test runs above are clean. |
|
Validation update:
../typescript prepare$ pnpm run build
CLI Building entry: {"index":"src/index.ts","cli":"src/cli/index.ts"}
✓ Build verification passed,
✓ native binary present; skipping rebuild
console.warn console.log console.log Notes:
sdk/native/npm/darwin-x64 | WARN Unsupported platform: wanted: {"cpu":["x64"],"os":["darwin"],"libc":["any"]} (current: {"os":"darwin","cpu":"arm64","libc":"unknown"})
sdk/native/npm/darwin-x64 | WARN Unsupported platform: wanted: {"cpu":["x64"],"os":["darwin"],"libc":["any"]} (current: {"os":"darwin","cpu":"arm64","libc":"unknown"})
Analyzing /Users/bytedance/codex-native/codex-rs No unused dependencies!
sdk/native/npm/darwin-x64 | WARN Unsupported platform: wanted: {"cpu":["x64"],"os":["darwin"],"libc":["any"]} (current: {"os":"darwin","cpu":"arm64","libc":"unknown"})
running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 25 tests test result: ok. 25 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s running 6 tests test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s running 1 test test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.02s running 2 tests test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 20 tests test result: ok. 20 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 79 tests test result: ok. 79 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 5.72s running 20 tests test result: ok. 20 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.08s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 49 tests test result: ok. 49 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.04s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 17 tests test result: ok. 17 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.04s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 3 tests test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.02s running 5 tests test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 2 tests test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.28s running 6 tests test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.11s running 14 tests test result: ok. 14 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s running 1 test test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 11.41s running 6 tests test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 2.93s running 3 tests test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.28s running 1 test test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 12 tests test result: ok. 11 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out; finished in 0.01s running 1 test test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 28 tests test result: ok. 28 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 671 tests test result: ok. 667 passed; 0 failed; 4 ignored; 0 measured; 0 filtered out; finished in 16.26s running 566 tests |
|
More validation (2026-01-05):
CLI Building entry: {"index":"src/index.ts","cli":"src/cli/index.ts"}
✓ Build verification passed
✓ native binary present; skipping rebuild
ELIFECYCLE Test failed. See above for more details. (JS) (fast-embed test downloads the model on first run; then passes)
Note:
sdk/native/npm/darwin-x64 | WARN Unsupported platform: wanted: {"cpu":["x64"],"os":["darwin"],"libc":["any"]} (current: {"os":"darwin","cpu":"arm64","libc":"unknown"})
sdk/native/npm/darwin-x64 | WARN Unsupported platform: wanted: {"cpu":["x64"],"os":["darwin"],"libc":["any"]} (current: {"os":"darwin","cpu":"arm64","libc":"unknown"})
Analyzing /Users/bytedance/codex-native/codex-rs No unused dependencies!
sdk/native/npm/darwin-x64 | WARN Unsupported platform: wanted: {"cpu":["x64"],"os":["darwin"],"libc":["any"]} (current: {"os":"darwin","cpu":"arm64","libc":"unknown"})
running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 25 tests test result: ok. 25 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s running 6 tests test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s running 1 test test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.02s running 2 tests test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 20 tests test result: ok. 20 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 79 tests test result: ok. 79 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 5.93s running 20 tests test result: ok. 20 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.69s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 49 tests test result: ok. 49 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.04s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 17 tests test result: ok. 17 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.40s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 3 tests test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.02s running 5 tests test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 2 tests test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.26s running 6 tests test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.13s running 14 tests test result: ok. 14 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.03s running 1 test test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 4.71s running 6 tests test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.46s running 3 tests test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.28s running 1 test test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 12 tests test result: ok. 11 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out; finished in 0.00s running 1 test test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 28 tests test result: ok. 28 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 671 tests test result: ok. 667 passed; 0 failed; 4 ignored; 0 measured; 0 filtered out; finished in 14.73s running 566 tests |
|
More validation (2026-01-05):
✓ native binary present; skipping rebuild
console.warn console.log console.log
Note: running
sdk/native/npm/darwin-x64 | WARN Unsupported platform: wanted: {"cpu":["x64"],"os":["darwin"],"libc":["any"]} (current: {"os":"darwin","cpu":"arm64","libc":"unknown"})
sdk/native/npm/darwin-x64 | WARN Unsupported platform: wanted: {"cpu":["x64"],"os":["darwin"],"libc":["any"]} (current: {"os":"darwin","cpu":"arm64","libc":"unknown"})
Analyzing /Users/bytedance/codex-native/codex-rs No unused dependencies!
sdk/native/npm/darwin-x64 | WARN Unsupported platform: wanted: {"cpu":["x64"],"os":["darwin"],"libc":["any"]} (current: {"os":"darwin","cpu":"arm64","libc":"unknown"})
running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 25 tests test result: ok. 25 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s running 6 tests test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s running 1 test test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.03s running 2 tests test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 20 tests test result: ok. 20 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 79 tests test result: ok. 79 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 5.47s running 20 tests test result: ok. 20 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.23s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 49 tests test result: ok. 49 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.04s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 17 tests test result: ok. 17 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.68s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 3 tests test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.02s running 5 tests test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 2 tests test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.25s running 6 tests test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.12s running 14 tests test result: ok. 14 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.03s running 1 test test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 4.55s running 6 tests test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 2.04s running 3 tests test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.29s running 1 test test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 12 tests test result: ok. 11 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out; finished in 0.00s running 1 test test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 28 tests test result: ok. 28 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 671 tests test result: ok. 667 passed; 0 failed; 4 ignored; 0 measured; 0 filtered out; finished in 14.69s running 566 tests |
|
To use Codex here, create a Codex account and connect to github. |
2 similar comments
|
To use Codex here, create a Codex account and connect to github. |
|
To use Codex here, create a Codex account and connect to github. |
|
Updated branch with latest upstream/main (openai/codex @ 5f8776d) via merge commit ca706b7. Post-merge fixes/tests:
Note: the two exec-server tests can exceed the repo nextest slow-timeout (15s) on cold dotslash cache because they fetch a bash artifact from GitHub releases. |
Merges upstream/main into this fork.
Validation: