7919 Commits

  • fix: preserve platform-specific core shell env vars (#16707)
    ## Why
    
    We were seeing failures in the following tests as part of trying to get
    all the tests running under Bazel on Windows in CI
    (https://github.com/openai/codex/pull/16528):
    
    ```
    suite::shell_command::unicode_output::with_login
    suite::shell_command::unicode_output::without_login
    ```
    
    Certainly `PATHEXT` should have been included in the extra `CORE_VARS`
    list, so we fix that up here, but also take things a step further for
    now by forcibly ensuring it is set on Windows in the return value of
    `create_env()`. Once we get the Windows Bazel build working reliably
    (i.e., after #16528 is merged), we should come back to this and confirm
    we can remove the special case in `create_env()`.
    
    ## What
    
    - Split core env inheritance into `COMMON_CORE_VARS` plus
    platform-specific allowlists for Windows and Unix in
    [`exec_env.rs`](https://github.com/openai/codex/blob/1b55c88fbf585b32cd553cb9d02ec817f2ad6ebc/codex-rs/core/src/exec_env.rs#L45-L81).
    - Preserve `PATHEXT`, `USERNAME`, and `USERPROFILE` on Windows, and
    `HOME` / locale vars on Unix.
    - Backfill a default `PATHEXT` in `create_env()` on Windows if the
    parent env does not provide one, so child process launch still works in
    stripped-down Bazel environments.
    - Extend the Windows exec-env test to assert mixed-case `PathExt`
    survives case-insensitive core filtering, and document why the
    shell-command Unicode test goes through a child process.
    
    ## Verification
    
    - `cargo test -p codex-core exec_env::tests`
  • Add remote --cd forwarding for app-server sessions (#16700)
    Addresses #16124
    
    Problem: `codex --remote --cd <path>` canonicalized the path locally and
    then omitted it from remote thread lifecycle requests, so remote-only
    working directories failed or were ignored.
    
    Solution: Keep remote startup on the local cwd, forward explicit `--cd`
    values verbatim to `thread/start`, `thread/resume`, and `thread/fork`,
    and cover the behavior with `codex-tui` tests.
    
    Testing: I manually tested `--remote --cd` with both absolute and
    relative paths and validated correct behavior.
    
    
    ---
    
    Update based on code review feedback:
    
    Problem: Remote `--cd` was forwarded to `thread/resume` and
    `thread/fork`, but not to `thread/list` lookups, so `--resume --last`
    and picker flows could select a session from the wrong cwd; relative cwd
    filters also failed against stored absolute paths.
    
    Solution: Apply explicit remote `--cd` to `thread/list` lookups for
    `--last` and picker flows, normalize relative cwd filters on the
    app-server before exact matching, and document/test the behavior.
  • Fix macOS malloc diagnostics leaking into TUI composer (#16699)
    Addresses #11555
    
    Problem: macOS malloc stack-logging diagnostics could leak into the TUI
    composer and get misclassified as pasted user input.
    
    Solution: Strip `MallocStackLogging*` and `MallocLogFile*` during macOS
    pre-main hardening and document the additional env cleanup.
  • Fix macOS sandbox panic in Codex HTTP client (#16670)
    Addresses #15640
    
    Problem: `codex exec` panicked on macOS when sandboxed proxy discovery
    hit a NULL `SCDynamicStore` handle in `system-configuration`.
    
    Solution: Bump `hyper-util` and `system-configuration` to versions that
    handle denied `configd` lookups safely, and refresh the Bazel lockfile.
    
    Testing: Verified using the manual `printf '(version 1) (allow default)
    (deny mach-lookup (global-name
    "com.apple.SystemConfiguration.configd"))' > /tmp/deny-configd.sb
    sandbox-exec -f /tmp/deny-configd.sb codex exec -s danger-full-access
    "echo test"`. Prior to the fix, this caused a panic.
  • Suppress bwrap warning when sandboxing is bypassed (#16667)
    Addresses #15282
    
    Problem: Codex warned about missing system bubblewrap even when
    sandboxing was disabled.
    
    Solution: Gate the bwrap warning on the active sandbox policy and skip
    it for danger-full-access and external-sandbox modes.
  • Fix MCP tool listing for hyphenated server names (#16674)
    Addresses #16671 and #14927
    
    Problem: `mcpServerStatus/list` rebuilt MCP tool groups from sanitized
    tool prefixes but looked them up by unsanitized server names, so
    hyphenated servers rendered as having no tools in `/mcp`. This was
    reported as a regression when the TUI switched to use the app server.
    
    Solution: Build each server's tool map using the original server name's
    sanitized prefix, include effective runtime MCP servers in the status
    response, and add a regression test for hyphenated server names.
  • Fix stale /copy output after commentary-only turns (#16648)
    Addresses #16454
    
    Problem: `/copy` could keep stale output after a turn with
    commentary-only assistant text.
    
    Solution: Cache the latest non-empty agent message during a turn and
    promote it on turn completion.
  • remove temporary ownership re-exports (#16626)
    Stacked on #16508.
    
    This removes the temporary `codex-core` / `codex-login` re-export shims
    from the ownership split and rewrites callsites to import directly from
    `codex-model-provider-info`, `codex-models-manager`, `codex-api`,
    `codex-protocol`, `codex-feedback`, and `codex-response-debug-context`.
    
    No behavior change intended; this is the mechanical import cleanup layer
    split out from the ownership move.
    
    ---------
    
    Co-authored-by: Codex <noreply@openai.com>
  • fix: use cmd.exe in Windows unicode shell test (#16668)
    ## Why
    
    This is a follow-up to #16665. The Windows `unicode_output` test should
    still exercise a child process so it verifies PowerShell's UTF-8 output
    configuration, but `$env:COMSPEC` depends on that environment variable
    surviving the curated Bazel test environment.
    
    Using `cmd.exe` keeps the child-process coverage while avoiding both
    bare `cmd` + `PATHEXT` lookup and `$env:COMSPEC` env passthrough
    assumptions.
    
    ## What
    
    - Run `cmd.exe /c echo naïve_café` in the Windows branch of
    `unicode_output`.
    
    ## Verification
    
    - `cargo test -p codex-core unicode_output`
  • fix: use COMSPEC in Windows unicode shell test (#16665)
    ## Why
    
    Windows Bazel shell tests launch PowerShell with a curated environment,
    so `PATHEXT` may be absent. The existing `unicode_output` test invokes
    bare `cmd`, which can fail before the test exercises UTF-8 child-process
    output.
    
    ## What
    
    - Use `$env:COMSPEC /c echo naïve_café` in the Windows branch of
    `unicode_output`.
    - Preserve the external child-process path instead of switching the test
    to a PowerShell builtin.
    
    ## Verification
    
    - `cargo test -p codex-core unicode_output`
  • fix: changes to test that should help them pass on Windows under Bazel (#16662)
    https://github.com/openai/codex/pull/16460 was a large PR created by
    Codex to try to get the tests to pass under Bazel on Windows. Indeed, it
    successfully ran all of the tests under `//codex-rs/core:` with its
    changes to `codex-rs/core/`, though the full set of changes seems to be
    too broad.
    
    This PR tries to port the key changes, which are:
    
    - Under Bazel, the `USERNAME` environment variable is not guaranteed to
    be set on Windows, so for tests that need a non-empty env var as a
    convenient substitute for an env var containing an API key, just use
    `PATH`. Note that `PATH` is unlikely to contain characters that are not
    allowed in an HTTP header value.
    - Specify `"powershell.exe"` instead of just `"powershell"` in case the
    `PATHEXT` env var gets lost in the shuffle.
  • extract models manager and related ownership from core (#16508)
    ## Summary
    - split `models-manager` out of `core` and add `ModelsManagerConfig`
    plus `Config::to_models_manager_config()` so model metadata paths stop
    depending on `core::Config`
    - move login-owned/auth-owned code out of `core` into `codex-login`,
    move model provider config into `codex-model-provider-info`, move API
    bridge mapping into `codex-api`, move protocol-owned types/impls into
    `codex-protocol`, and move response debug helpers into a dedicated
    `response-debug-context` crate
    - move feedback tag emission into `codex-feedback`, relocate tests to
    the crates that now own the code, and keep broad temporary re-exports so
    this PR avoids a giant import-only rewrite
    
    ## Major moves and decisions
    - created `codex-models-manager` as the owner for model
    cache/catalog/config/model info logic, including the new
    `ModelsManagerConfig` struct
    - created `codex-model-provider-info` as the owner for provider config
    parsing/defaults and kept temporary `codex-login`/`codex-core`
    re-exports for old import paths
    - moved `api_bridge` error mapping + `CoreAuthProvider` into
    `codex-api`, while `codex-login::api_bridge` temporarily re-exports
    those symbols and keeps the `auth_provider_from_auth` wrapper
    - moved `auth_env_telemetry` and `provider_auth` ownership to
    `codex-login`
    - moved `CodexErr` ownership to `codex-protocol::error`, plus
    `StreamOutput`, `bytes_to_string_smart`, and network policy helpers to
    protocol-owned modules
    - created `codex-response-debug-context` for
    `extract_response_debug_context`, `telemetry_transport_error_message`,
    and related response-debug plumbing instead of leaving that behavior in
    `core`
    - moved `FeedbackRequestTags`, `emit_feedback_request_tags`, and
    `emit_feedback_request_tags_with_auth_env` to `codex-feedback`
    - deferred removal of temporary re-exports and the mechanical import
    rewrites to a stacked follow-up PR so this PR stays reviewable
    
    ## Test moves
    - moved auth refresh coverage from `core/tests/suite/auth_refresh.rs` to
    `login/tests/suite/auth_refresh.rs`
    - moved text encoding coverage from
    `core/tests/suite/text_encoding_fix.rs` to
    `protocol/src/exec_output_tests.rs`
    - moved model info override coverage from
    `core/tests/suite/model_info_overrides.rs` to
    `models-manager/src/model_info_overrides_tests.rs`
    
    ---------
    
    Co-authored-by: Codex <noreply@openai.com>
  • Fix deprecated login --api-key parsing (#16658)
    Addresses #16655
    
    Problem: `codex login --api-key` failed in Clap before Codex could show
    the deprecation guidance.
    
    Solution: Allow the hidden `--api-key` flag to parse with zero or one
    values so both forms reach the `--with-api-key` message.
  • build: fix Bazel lzma-sys wiring (#16634)
    This seems to be required to fix bazel builds on an applied devbox
    
    ## Summary
    - add the Bazel `xz` module
    - wire `lzma-sys` directly to `@xz//:lzma` and disable its build script
    - refresh `MODULE.bazel.lock`
    
    ## Validation
    - `just bazel-lock-update`
    - `just bazel-lock-check`
    - `bazel run //codex-rs/cli:codex --run_under="cd $PWD &&" -- --version`
    - `just bazel-codex --version`
    
    Co-authored-by: Codex <noreply@openai.com>
  • test: use cmd.exe for ProviderAuthScript on Windows (#16629)
    ## Why
    
    The Windows `ProviderAuthScript` test helpers do not need PowerShell.
    Running them through `cmd.exe` is enough to emit the next fixture token
    and rotate `tokens.txt`, and it avoids a PowerShell-specific dependency
    in these tests.
    
    ## What changed
    
    - Replaced the Windows `print-token.ps1` fixtures with `print-token.cmd`
    in `codex-rs/core/src/models_manager/manager_tests.rs` and
    `codex-rs/login/src/auth/auth_tests.rs`.
    - Switched the failing external-auth helper in
    `codex-rs/login/src/auth/auth_tests.rs` from `powershell.exe -Command
    'exit 1'` to `cmd.exe /d /s /c 'exit /b 1'`.
    - Updated Windows timeout comments so they no longer call out PowerShell
    specifically.
    
    ## Verification
    
    - `cargo test -p codex-login`
    - `cargo test -p codex-core` (fails in unrelated
    `core/src/config/config_tests.rs` assertions in this checkout)
  • app-server: make thread/shellCommand tests shell-aware (#16635)
    ## Why
    `thread/shellCommand` executes the raw command string through the
    current user shell, which is PowerShell on Windows. The two v2
    app-server tests in `app-server/tests/suite/v2/thread_shell_command.rs`
    used POSIX `printf`, so Bazel CI on Windows failed with `printf` not
    being recognized as a PowerShell command.
    
    For reference, the user-shell task wraps commands with the active shell
    before execution:
    [`core/src/tasks/user_shell.rs`](https://github.com/openai/codex/blob/7a3eec6fdb356bd71f80582119eb829179ff0da1/codex-rs/core/src/tasks/user_shell.rs#L120-L126).
    
    ## What Changed
    Added a test-local helper that builds a shell-appropriate output command
    and expected newline sequence from `default_user_shell()`:
    
    - PowerShell: `Write-Output '...'` with `\r\n`
    - Cmd: `echo ...` with `\r\n`
    - POSIX shells: `printf '%s\n' ...` with `\n`
    
    Both `thread_shell_command_runs_as_standalone_turn_and_persists_history`
    and `thread_shell_command_uses_existing_active_turn` now use that
    helper.
    
    ## Verification
    - `cargo test -p codex-app-server thread_shell_command`
  • fix: address unused variable on windows (#16633)
    This slipped in during https://github.com/openai/codex/pull/16578. I am
    still working on getting Windows working properly with Bazel on PRs.
  • Auto-trust cwd on thread start (#16492)
    - Persist trusted cwd state during thread/start when the resolved
    sandbox is elevated.
    - Add app-server coverage for trusted root resolution and confirm
    turn/start does not mutate trust.
  • core: cut codex-core compile time 48% with native async SessionTask (#16631)
    ## Why
    
    This continues the compile-time cleanup from #16630. `SessionTask`
    implementations are monomorphized, but `Session` stores the task behind
    a `dyn` boundary so it can drive and abort heterogenous turn tasks
    uniformly. That means we can move the `#[async_trait]` expansion off the
    implementation trait, keep a small boxed adapter only at the storage
    boundary, and preserve the existing task lifecycle semantics while
    reducing the amount of generated async-trait glue in `codex-core`.
    
    One measurement caveat showed up while exploring this: a warm
    incremental benchmark based on `touch core/src/tasks/mod.rs && cargo
    check -p codex-core --lib` was basically flat, but that was the wrong
    benchmark for this change. Using package-clean `codex-core` rebuilds,
    like #16630, shows the real win.
    
    Relevant pre-change code:
    
    - [`SessionTask` with
    `#[async_trait]`](https://github.com/openai/codex/blob/3c7f013f9735e67796c70d95f75f436b7f97e3ec/codex-rs/core/src/tasks/mod.rs#L129-L182)
    - [`RunningTask` storing `Arc<dyn
    SessionTask>`](https://github.com/openai/codex/blob/3c7f013f9735e67796c70d95f75f436b7f97e3ec/codex-rs/core/src/state/turn.rs#L69-L77)
    
    ## What changed
    
    - Switched `SessionTask::{run, abort}` to native RPITIT futures with
    explicit `Send` bounds.
    - Added a private `AnySessionTask` adapter that boxes those futures only
    at the `Arc<dyn ...>` storage boundary.
    - Updated `RunningTask` to store `Arc<dyn AnySessionTask>` and removed
    `#[async_trait]` from the concrete task impls plus test-only
    `SessionTask` impls.
    
    ## Timing
    
    Benchmarked package-clean `codex-core` rebuilds with dependencies left
    warm:
    
    ```shell
    cargo check -p codex-core --lib >/dev/null
    cargo clean -p codex-core >/dev/null
    /usr/bin/time -p cargo +nightly rustc -p codex-core --lib -- \
      -Z time-passes \
      -Z time-passes-format=json >/dev/null
    ```
    
    | revision | rustc `total` | process `real` | `generate_crate_metadata`
    | `MIR_borrow_checking` | `monomorphization_collector_graph_walk` |
    | --- | ---: | ---: | ---: | ---: | ---: |
    | parent `3c7f013f9735` | 67.21s | 67.71s | 24.61s | 23.43s | 22.43s |
    | this PR `2cafd783ac22` | 35.08s | 35.60s | 8.01s | 7.25s | 7.15s |
    | delta | -47.8% | -47.4% | -67.5% | -69.1% | -68.1% |
    
    For completeness, the warm touched-file benchmark stayed flat (`1.96s`
    parent vs `1.97s` this PR), which is why that benchmark should not be
    used to evaluate this refactor.
    
    ## Verification
    
    - Ran `cargo test -p codex-core`; this change compiled and task-related
    tests passed before hitting the same unrelated 5
    `config::tests::*guardian*` failures already present on the parent
    stack.
  • core: cut codex-core compile time 63% with native async ToolHandler (#16630)
    ## Why
    
    `ToolHandler` was still paying a large compile-time tax from
    `#[async_trait]` on every concrete handler impl, even though the only
    object-safe boundary the registry actually stores is the internal
    `AnyToolHandler` adapter.
    
    This PR removes that macro-generated async wrapper layer from concrete
    `ToolHandler` impls while keeping the existing object-safe shim in
    `AnyToolHandler`. In practice, that gets essentially the same
    compile-time win as the larger type-erasure refactor in #16627, but with
    a much smaller diff and without changing the public shape of
    `ToolHandler<Output = T>`.
    
    That tradeoff matters here because this is a broad `codex-core` hotspot
    and reviewers should be able to judge the compile-time impact from hard
    numbers, not vibes.
    
    ## Headline result
    
    On a clean `codex-core` package rebuild (`cargo clean -p codex-core`
    before each command), rustc `total` dropped from **187.15s to 68.98s**
    versus the shared `0bd31dc382bd` baseline: **-63.1%**.
    
    The biggest hot passes dropped by roughly **71-72%**:
    
    | Metric | Baseline `0bd31dc382bd` | This PR `41f7ac0adeac` | Delta |
    |---|---:|---:|---:|
    | `total` | 187.15s | 68.98s | **-63.1%** |
    | `generate_crate_metadata` | 84.53s | 24.49s | **-71.0%** |
    | `MIR_borrow_checking` | 84.13s | 24.58s | **-70.8%** |
    | `monomorphization_collector_graph_walk` | 79.74s | 22.19s | **-72.2%**
    |
    | `evaluate_obligation` self-time | 180.62s | 46.91s | **-74.0%** |
    
    Important caveat: `-Z time-passes` timings are nested, so
    `generate_crate_metadata` and `monomorphization_collector_graph_walk`
    are mostly overlapping, not additive.
    
    ## Why this PR over #16627
    
    #16627 already proved that the `ToolHandler` stack was the right
    hotspot, but it got there by making `ToolHandler` object-safe and
    changing every handler to return `BoxFuture<Result<AnyToolResult, _>>`
    directly.
    
    This PR keeps the lower-churn shape:
    
    - `ToolHandler` remains generic over `type Output`.
    - Concrete handlers use native RPITIT futures with explicit `Send`
    bounds.
    - `AnyToolHandler` remains the only object-safe adapter and still does
    the boxing at the registry boundary, as before.
    - The implementation diff is only **33 files, +28/-77**.
    
    The measurements are at least comparable, and in this run this PR is
    slightly faster than #16627 on the pass-level total:
    
    | Metric | #16627 | This PR | Delta |
    |---|---:|---:|---:|
    | `total` | 79.90s | 68.98s | **-13.7%** |
    | `generate_crate_metadata` | 25.88s | 24.49s | **-5.4%** |
    | `monomorphization_collector_graph_walk` | 23.54s | 22.19s | **-5.7%**
    |
    | `evaluate_obligation` self-time | 43.29s | 46.91s | +8.4% |
    
    ## Profile data
    
    ### Crate-level timings
    
    `cargo +nightly build -p codex-core --lib -Z unstable-options
    --timings=json` after `cargo clean -p codex-core`.
    
    Baseline data below is reused from the shared parent `0bd31dc382bd`
    profile because this PR and #16627 are both one commit on top of that
    same parent.
    
    | Crate | Baseline `duration` | This PR `duration` | Delta | Baseline
    `rmeta_time` | This PR `rmeta_time` | Delta |
    |---|---:|---:|---:|---:|---:|---:|
    | `codex_core` | 187.380776583s | 69.171113833s | **-63.1%** |
    174.474507208s | 55.873015583s | **-68.0%** |
    | `starlark` | 17.90s | 16.773824125s | -6.3% | n/a | 8.8999965s | n/a |
    
    ### Pass-level timings
    
    `cargo +nightly rustc -p codex-core --lib -- -Z time-passes -Z
    time-passes-format=json` after `cargo clean -p codex-core`.
    
    | Pass | Baseline | This PR | Delta |
    |---|---:|---:|---:|
    | `total` | 187.150662083s | 68.978770375s | **-63.1%** |
    | `generate_crate_metadata` | 84.531864625s | 24.487462958s | **-71.0%**
    |
    | `MIR_borrow_checking` | 84.131389375s | 24.575553875s | **-70.8%** |
    | `monomorphization_collector_graph_walk` | 79.737515042s |
    22.190207417s | **-72.2%** |
    | `codegen_crate` | 12.362532292s | 12.695237625s | +2.7% |
    | `type_check_crate` | 4.4765405s | 5.442019542s | +21.6% |
    | `coherence_checking` | 3.311121208s | 4.239935292s | +28.0% |
    | process `real` / `user` / `sys` | 187.70s / 201.87s / 4.99s | 69.52s /
    85.90s / 2.92s | n/a |
    
    ### Self-profile query summary
    
    `cargo +nightly rustc -p codex-core --lib -- -Z self-profile=... -Z
    self-profile-events=default,query-keys,args,llvm,artifact-sizes` after
    `cargo clean -p codex-core`, summarized with `measureme summarize -p
    0.5`.
    
    | Query / phase | Baseline self time | This PR self time | Delta |
    Baseline total time | This PR total time | Baseline item count | This PR
    item count | Baseline cache hits | This PR cache hits |
    |---|---:|---:|---:|---:|---:|---:|---:|---:|---:|
    | `evaluate_obligation` | 180.62s | 46.91s | **-74.0%** | 182.08s |
    48.37s | 572,234 | 388,659 | 1,130,998 | 1,058,553 |
    | `mir_borrowck` | 1.42s | 1.49s | +4.9% | 93.77s | 29.59s | n/a | 6,184
    | n/a | 15,298 |
    | `typeck` | 1.84s | 1.87s | +1.6% | 2.38s | 2.44s | n/a | 9,367 | n/a |
    79,247 |
    | `LLVM_module_codegen_emit_obj` | n/a | 17.12s | n/a | 17.01s | 17.12s
    | n/a | 256 | n/a | 0 |
    | `LLVM_passes` | n/a | 13.07s | n/a | 12.95s | 13.07s | n/a | 1 | n/a |
    0 |
    | `codegen_module` | n/a | 12.33s | n/a | 12.22s | 13.64s | n/a | 256 |
    n/a | 0 |
    | `items_of_instance` | n/a | 676.00ms | n/a | n/a | 24.96s | n/a |
    99,990 | n/a | 0 |
    | `type_op_prove_predicate` | n/a | 660.79ms | n/a | n/a | 24.78s | n/a
    | 78,762 | n/a | 235,877 |
    
    | Summary | Baseline | This PR |
    |---|---:|---:|
    | `evaluate_obligation` % of total CPU | 70.821% | 38.880% |
    | self-profile total CPU time | 255.042999997s | 120.661175956s |
    | process `real` / `user` / `sys` | 220.96s / 235.02s / 7.09s | 86.35s /
    103.66s / 3.54s |
    
    ### Artifact sizes
    
    From the same `measureme summarize` output:
    
    | Artifact | Baseline | This PR | Delta |
    |---|---:|---:|---:|
    | `crate_metadata` | 26,534,471 bytes | 26,545,248 bytes | +10,777 |
    | `dep_graph` | 253,181,425 bytes | 239,240,806 bytes | -13,940,619 |
    | `linked_artifact` | 565,366,624 bytes | 562,673,176 bytes | -2,693,448
    |
    | `object_file` | 513,127,264 bytes | 510,464,096 bytes | -2,663,168 |
    | `query_cache` | 137,440,945 bytes | 136,982,566 bytes | -458,379 |
    | `cgu_instructions` | 3,586,307 bytes | 3,575,121 bytes | -11,186 |
    | `codegen_unit_size_estimate` | 2,084,846 bytes | 2,078,773 bytes |
    -6,073 |
    | `work_product_index` | 19,565 bytes | 19,565 bytes | 0 |
    
    ### Baseline hotspots before this change
    
    These are the top normalized obligation buckets from the shared baseline
    profile:
    
    | Obligation bucket | Samples | Duration |
    |---|---:|---:|
    | `outlives:tasks::review::ReviewTask` | 1,067 | 6.33s |
    | `outlives:tools::handlers::unified_exec::UnifiedExecHandler` | 896 |
    5.63s |
    | `trait:T as tools::registry::ToolHandler` | 876 | 5.45s |
    | `outlives:tools::handlers::shell::ShellHandler` | 888 | 5.37s |
    | `outlives:tools::handlers::shell::ShellCommandHandler` | 870 | 5.29s |
    |
    `outlives:tools::runtimes::shell::unix_escalation::CoreShellActionProvider`
    | 637 | 3.73s |
    | `outlives:tools::handlers::mcp::McpHandler` | 695 | 3.61s |
    | `outlives:tasks::regular::RegularTask` | 726 | 3.57s |
    
    Top `items_of_instance` entries before this change were mostly concrete
    async handler/task impls:
    
    | Instance | Duration |
    |---|---:|
    | `tasks::regular::{impl#2}::run` | 3.79s |
    | `tools::handlers::mcp::{impl#0}::handle` | 3.27s |
    | `tools::runtimes::shell::unix_escalation::{impl#2}::determine_action`
    | 3.09s |
    | `tools::handlers::agent_jobs::{impl#11}::handle` | 3.07s |
    | `tools::handlers::multi_agents::spawn::{impl#1}::handle` | 2.84s |
    | `tasks::review::{impl#4}::run` | 2.82s |
    | `tools::handlers::multi_agents_v2::spawn::{impl#2}::handle` | 2.80s |
    | `tools::handlers::multi_agents::resume_agent::{impl#1}::handle` |
    2.73s |
    | `tools::handlers::unified_exec::{impl#2}::handle` | 2.54s |
    | `tasks::compact::{impl#4}::run` | 2.45s |
    
    ## What changed
    
    Relevant pre-change registry shape:
    [`codex-rs/core/src/tools/registry.rs`](https://github.com/openai/codex/blob/0bd31dc382bd1c33dc2bb6b97069c76aa10ba14b/codex-rs/core/src/tools/registry.rs#L38-L219)
    
    Current registry shape in this PR:
    [`codex-rs/core/src/tools/registry.rs`](https://github.com/openai/codex/blob/41f7ac0adeac81d667541853d6546267d6083613/codex-rs/core/src/tools/registry.rs#L38-L203)
    
    - `ToolHandler::{is_mutating, handle}` now return native `impl Future +
    Send` futures instead of using `#[async_trait]`.
    - `AnyToolHandler` remains the object-safe adapter and boxes those
    futures at the registry boundary with explicit lifetimes.
    - Concrete handlers and the registry test handler drop `#[async_trait]`
    but otherwise keep their async method bodies intact.
    - Representative examples:
    [`codex-rs/core/src/tools/handlers/shell.rs`](https://github.com/openai/codex/blob/41f7ac0adeac81d667541853d6546267d6083613/codex-rs/core/src/tools/handlers/shell.rs#L223-L379),
    [`codex-rs/core/src/tools/handlers/unified_exec.rs`](https://github.com/openai/codex/blob/41f7ac0adeac81d667541853d6546267d6083613/codex-rs/core/src/tools/handlers/unified_exec.rs),
    [`codex-rs/core/src/tools/registry_tests.rs`](https://github.com/openai/codex/blob/41f7ac0adeac81d667541853d6546267d6083613/codex-rs/core/src/tools/registry_tests.rs)
    
    ## Tradeoff
    
    This is intentionally less invasive than #16627: it does **not** move
    result boxing into every concrete handler and does **not** change
    `ToolHandler` into an object-safe trait.
    
    Instead, it keeps the existing registry-level type-erasure boundary and
    only removes the macro-generated async wrapper layer from concrete
    impls. So the runtime boxing story stays basically the same as before,
    while the compile-time savings are still large.
    
    ## Verification
    
    Existing verification for this branch still applies:
    
    - Ran `cargo test -p codex-core`; this change compiled and the suite
    reached the known unrelated `config::tests::*guardian*` failures, with
    no local diff under `codex-rs/core/src/config/`.
    
    Profiling commands used for the tables above:
    
    - `cargo clean -p codex-core`
    - `cargo +nightly build -p codex-core --lib -Z unstable-options
    --timings=json`
    - `cargo +nightly rustc -p codex-core --lib -- -Z time-passes -Z
    time-passes-format=json`
    - `cargo +nightly rustc -p codex-core --lib -- -Z self-profile=... -Z
    self-profile-events=default,query-keys,args,llvm,artifact-sizes`
    - `measureme summarize -p 0.5`
  • fix(tui): handle zellij redraw and composer rendering (#16578)
    ## TL;DR
    
    Fixes the issues when using Codex CLI with Zellij multiplexer. Before
    this PR there would be no scrollback when using it inside a zellij
    terminal.
    
    ## Problem
    
    Addresses #2558
    
    Zellij does not support ANSI scroll-region manipulation (`DECSTBM` /
    Reverse Index) or the alternate screen buffer in the way traditional
    terminals do. When codex's TUI runs inside Zellij, two things break: (1)
    inline history insertion corrupts the display because the scroll-region
    escape sequences are silently dropped or mishandled, and (2) the
    composer textarea renders with inherited background/foreground styles
    that produce unreadable text against Zellij's pane chrome.
    
    ## Mental model
    
    The fix introduces a **Zellij mode** — a runtime boolean detected once
    at startup via `codex_terminal_detection::terminal_info().is_zellij()` —
    that gates two subsystems onto Zellij-safe terminal strategies:
    
    - **History insertion** (`insert_history.rs`): Instead of using
    `DECSTBM` scroll regions and Reverse Index (`ESC M`) to slide content
    above the viewport, Zellij mode scrolls the screen by emitting `\n` at
    the bottom row and then writes history lines at absolute positions. This
    avoids every escape sequence Zellij mishandles.
    - **Viewport expansion** (`tui.rs`): When the viewport grows taller than
    available space, the standard path uses `scroll_region_up` on the
    backend. Zellij mode instead emits newlines at the screen bottom to push
    content up, then invalidates the ratatui diff buffer so the next draw is
    a full repaint.
    - **Composer rendering** (`chat_composer.rs`, `textarea.rs`): All text
    rendering in the input area uses an explicit `base_style` with
    `Color::Reset` foreground, preventing Zellij's pane styling from
    bleeding into the textarea. The prompt chevron (`›`) and placeholder
    text use explicit color constants instead of relying on `.bold()` /
    `.dim()` modifiers that render inconsistently under Zellij.
    
    ## Non-goals
    
    - This change does not fix or improve Zellij's terminal emulation
    itself.
    - It does not rearchitect the inline viewport model; it adds a parallel
    code path gated on detection.
    - It does not touch the alternate-screen disable logic (that already
    existed and continues to use `is_zellij` via the same detection).
    
    ## Tradeoffs
    
    - **Code duplication in `insert_history.rs`**: The Zellij and Standard
    branches share the line-rendering loop (color setup, span merging,
    `write_spans`) but differ in the scrolling preamble. The duplication is
    intentional — merging them would force a complex conditional state
    machine that's harder to reason about than two flat sequences.
    - **`invalidate_viewport` after every Zellij history flush or viewport
    expansion**: This forces a full repaint on every draw cycle in Zellij,
    which is more expensive than ratatui's normal diff-based rendering. This
    is necessary because Zellij's lack of scroll-region support means the
    diff buffer's assumptions about what's on screen are invalid after we
    manually move content.
    - **Explicit colors vs semantic modifiers**: Replacing `.bold()` /
    `.dim()` with `Color::Cyan` / `Color::DarkGray` / `Color::White` in the
    Zellij branch sacrifices theme-awareness for correctness. If the project
    ever adopts a theming system, Zellij styling will need to participate.
    
    ## Architecture
    
    The Zellij detection flag flows through three layers:
    
    1. **`codex_terminal_detection`** — `TerminalInfo::is_zellij()` (new
    convenience method) reads the already-detected `Multiplexer` variant.
    2. **`Tui` struct** — caches `is_zellij` at construction; passes it into
    `update_inline_viewport`, `flush_pending_history_lines`, and
    `insert_history_lines_with_mode`.
    3. **`ChatComposer` struct** — independently caches `is_zellij` at
    construction; uses it in `render_textarea` for style decisions.
    
    The two caches (`Tui.is_zellij` and `ChatComposer.is_zellij`) are read
    from the same global `OnceLock<TerminalInfo>`, so they always agree.
    
    ## Observability
    
    No new logging, metrics, or tracing is introduced. Diagnosis depends on:
    - Whether `ZELLIJ` or `ZELLIJ_SESSION_NAME` env vars are set (the
    detection heuristic).
    - Visual inspection of the rendered TUI inside Zellij vs a standard
    terminal.
    - The insta snapshot `zellij_empty_composer` captures the Zellij-mode
    render path.
    
    ## Tests
    
    - `terminal_info_reports_is_zellij` — unit test in `terminal-detection`
    confirming the convenience method.
    - `zellij_empty_composer_snapshot` — insta snapshot in `chat_composer`
    validating the Zellij render path for an empty composer.
    - `vt100_zellij_mode_inserts_history_and_updates_viewport` — integration
    test in `insert_history` verifying that Zellij-mode history insertion
    writes content and shifts the viewport.
    
    ---------
    
    Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
  • Fix fork source display in /status (expose forked_from_id in app server) (#16596)
    Addresses #16560
    
    Problem: `/status` stopped showing the source thread id in forked TUI
    sessions after the app-server migration.
    
    Solution: Carry fork source ids through app-server v2 thread data and
    the TUI session adapter, and update TUI fixtures so `/status` matches
    the old TUI behavior.
  • fix: add shell fallback paths for pwsh/powershell that work on GitHub Actions Windows runners (#16617)
    Recently, I merged a number of PRs to increase startup timeouts for
    scripts that ran under PowerShell, but in the failure for
    `suite::codex_tool::test_shell_command_approval_triggers_elicitation`, I
    found this in the error logs when running on Bazel with BuildBuddy:
    
    ```
    [mcp stderr] 2026-04-02T19:54:10.758951Z ERROR codex_core::tools::router: error=Exit code: 1
    [mcp stderr] Wall time: 0.2 seconds
    [mcp stderr] Output:
    [mcp stderr] 'New-Item' is not recognized as an internal or external command,
    [mcp stderr] operable program or batch file.
    [mcp stderr] 
    ```
    
    This error implies that the command was run under `cmd.exe` instead of
    `pwsh.exe`. Under GitHub Actions, I suspect that the `%PATH%` that is
    passed to our Bazel builder is scrubbed such that our tests cannot find
    PowerShell where GitHub installs it. Having these explicit fallback
    paths should help.
    
    While we could enable these only for tests, I don't see any harm in
    keeping them in production, as well.
  • Fix stale turn steering during TUI review follow-ups (#16588)
    Addresses #16389
    
    Problem: `/review` follow-ups can crash when app-server TUI steers with
    a stale active turn id; #14717 introduced the client-side race, and
    #15714 only handled the “no active turn” half.
    
    Solution: Treat turn-id mismatch as stale cached state too, sync to the
    server’s current turn id, retry once, and let review turns fall into the
    existing queue path.
  • Fix resume picker stale thread names (#16601)
    Addresses #16562
    
    Problem: Resume picker could keep a stale backend-provided thread title
    instead of the latest name from session_index.jsonl.
    
    Solution: Always backfill/override picker row names from local
    session_index.jsonl and cover stale-name replacement with a regression
    test.
  • Fix resume picker initial loading state (#16591)
    Addresses #16514
    
    Problem: Resume picker could show “No sessions yet” before the initial
    session fetch finished.
    
    Solution: Render a loading message while the first page is pending, and
    keep the empty state for truly empty results.
  • fix: increase timeout to account for slow PowerShell startup (#16608)
    Similar to https://github.com/openai/codex/pull/16604, I am seeing
    failures on Windows Bazel that could be due to PowerShell startup
    timeouts, so try increasing.
  • fix: add more detail to test assertion (#16606)
    In https://github.com/openai/codex/pull/16528, I am trying to get tests
    running under Bazel on Windows, but currently I see:
    
    ```
    thread 'suite::user_shell_cmd::user_shell_command_does_not_set_network_sandbox_env_var' (10220) panicked at core/tests\suite\user_shell_cmd.rs:358:5:
    assertion failed: `(left == right)`
    
    Diff < left / right > :
    <1
    >0
    ```
    
    This PR updates the `assert_eq!()` to provide more information to help
    diagnose the failure.
    
    ---
    [//]: # (BEGIN SAPLING FOOTER)
    Stack created with [Sapling](https://sapling-scm.com). Best reviewed
    with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16606).
    * #16608
    * __->__ #16606
  • test: deflake external bearer auth token tests on Windows (#16604)
    ## Why
    
    `external_bearer_only_auth_manager_uses_cached_provider_token` can fail
    on Windows when cold `powershell.exe` startup exceeds the provider-auth
    helper's 1s timeout. When that happens,
    `AuthManager::resolve_external_api_key_auth()` [logs the resolver error
    and returns
    `None`](https://github.com/openai/codex/blob/024b08b411fe/codex-rs/login/src/auth/manager.rs#L1449-L1455),
    which is exactly the assertion failure from the flake.
    
    ## What
    
    - Invoke `powershell.exe` explicitly in the Windows provider-auth test
    helpers in `login/src/auth/auth_tests.rs`.
    - Increase the helper timeout to `10_000` ms and document why that slack
    exists.
    
    ## Verification
    
    - `cargo test -p codex-login`
  • Fix non-determinism in rules_rs/crate_git_repository.bzl (#16590)
    Running multiple builds with no changes causes some differences, we see
    that
    https://app.buildbuddy.io/compare/a9719629-1660-4735-a477-d66357f234fb...df85310b-eb5c-4c10-8b79-4d0449ba6cdd#file
    shows the file-differences between two Bazel builds.
    
    These differences are caused by a non-deterministic `.git` entry in the
    rules_rs crates that are created with `crate_git_repository`.
    
    As a way to make these deterministic, we can remove this entry after we
    download the git source, so that the input to the compile action is
    deterministic.
    
    ### CLA
    
    I have read the CLA Document and I hereby sign the CLA
  • chore: move codex-exec unit tests into sibling files (#16581)
    ## Why
    
    `codex-rs/exec/src/lib.rs` already keeps unit tests in a sibling
    `lib_tests.rs` module so the implementation stays top-heavy and easier
    to read. This applies that same layout to the rest of
    `codex-rs/exec/src` so each production file keeps its entry points and
    helpers ahead of test code.
    
    ## What
    
    - Move inline unit tests out of `cli.rs`, `main.rs`,
    `event_processor_with_human_output.rs`, and
    `event_processor_with_jsonl_output.rs` into sibling `*_tests.rs` files.
    - Keep test modules wired through `#[cfg(test)]` plus `#[path = "..."]
    mod tests;`, matching the `lib.rs` pattern.
    - Preserve the existing test coverage and assertions while making this a
    source-layout-only refactor.
    
    ## Verification
    
    - `cargo test -p codex-exec`
  • ci: upload compact Bazel execution logs for bazel.yml (#16577)
    ## Why
    
    The main Bazel CI lanes need compact execution logs to investigate cache
    misses and unexpected rebuilds, but local users of the shared wrapper
    should not pay that log-generation cost by default.
    
    ## What Changed
    
    -
    [`.github/scripts/run-bazel-ci.sh`](https://github.com/openai/codex/blob/a6ec239a24fd21507bb75a28f17277653f52e3a2/.github/scripts/run-bazel-ci.sh#L149-L153)
    now appends `--execution_log_compact_file=...` only when
    `CODEX_BAZEL_EXECUTION_LOG_COMPACT_DIR` is set; the caller owns creating
    that directory.
    -
    [`.github/workflows/bazel.yml`](https://github.com/openai/codex/blob/a6ec239a24fd21507bb75a28f17277653f52e3a2/.github/workflows/bazel.yml#L66-L174)
    enables that env var only for the main `test` and `clippy` jobs, creates
    the temp log directory in each job, and uploads the resulting `*.zst`
    files from `runner.temp`.
    
    ## Verification
    
    - `bash -n .github/scripts/run-bazel-ci.sh`
    - Parsed `.github/workflows/bazel.yml` as YAML.
    - Ran a local opt-in wrapper smoke test and confirmed it writes
    `execution-log-cquery-local-*.zst` when the caller pre-creates
    `CODEX_BAZEL_EXECUTION_LOG_COMPACT_DIR`.
  • [codex] Remove codex-core config type shim (#16529)
    ## Why
    
    This finishes the config-type move out of `codex-core` by removing the
    temporary compatibility shim in `codex_core::config::types`. Callers now
    depend on `codex-config` directly, which keeps these config model types
    owned by the config crate instead of re-expanding `codex-core` as a
    transitive API surface.
    
    ## What Changed
    
    - Removed the `codex-rs/core/src/config/types.rs` re-export shim and the
    `core::config::ApprovalsReviewer` re-export.
    - Updated `codex-core`, `codex-cli`, `codex-tui`, `codex-app-server`,
    `codex-mcp-server`, and `codex-linux-sandbox` call sites to import
    `codex_config::types` directly.
    - Added explicit `codex-config` dependencies to downstream crates that
    previously relied on the `codex-core` re-export.
    - Regenerated `codex-rs/core/config.schema.json` after updating the
    config docs path reference.
  • fix: move some test utilities out of codex-rs/core/src/tools/spec.rs (#16524)
    The `#[cfg(test)]` in `codex-rs/core/src/tools/spec.rs` smelled funny to
    me and it turns out these members were straightforward to move.
  • [codex] Move config types into codex-config (#16523)
    ## Why
    
    `codex-rs/core/src/config/types.rs` is a plain config-type module with
    no dependency on `codex-core`. Moving it into `codex-config` shrinks the
    core crate and gives config-only consumers a more natural dependency
    boundary.
    
    ## What Changed
    
    - Added `codex_config::types` with the moved structs, enums, constants,
    and unit tests.
    - Kept `codex_core::config::types` as a compatibility re-export to avoid
    a broad call-site migration in this PR.
    - Switched notice-table writes in `core/src/config/edit.rs` to a local
    `NOTICE_TABLE_KEY` constant.
    - Added the `wildmatch` runtime dependency and `tempfile` test
    dependency to `codex-config`.
  • Move tool registry plan tests into codex-tools (#16521)
    ## Why
    
    #16513 moved pure tool-registry planning into `codex-tools`, but much of
    the corresponding spec/feature-gating coverage still lived in
    `codex-core`. That leaves the tests for planner behavior in the crate
    that no longer owns that logic and makes the next extraction steps
    harder to review.
    
    ## What
    
    Move the planner-only `spec_tests.rs` coverage into
    `codex-rs/tools/src/tool_registry_plan_tests.rs` and wire it up from
    `codex-rs/tools/src/tool_registry_plan.rs` using the crate-local `#[path
    = "tool_registry_plan_tests.rs"] mod tests;` pattern.
    
    The `codex-core` test file now keeps the core-side integration checks:
    router-visible model tool lists, namespaced handler alias registration,
    shell adapter behavior, and MCP schema edge cases that still exercise
    the `core` binding layer.
    
    ## Verification
    
    - `cargo test -p codex-tools`
    - `cargo test -p codex-core tools::spec::tests`
  • Extract tool registry planning into codex-tools (#16513)
    ## Why
    This is a larger step in the `codex-core` -> `codex-tools` migration
    called out in `AGENTS.md`.
    
    `codex-rs/core/src/tools/spec.rs` had become mostly pure tool-spec
    assembly plus handler registration. That made it hard to move more of
    the tool-definition layer into `codex-tools`, because the runtime
    binding and the crate-independent planning logic were still interleaved
    in one function.
    
    Splitting those concerns gives `codex-tools` ownership of the
    declarative registry plan while keeping `codex-core` responsible for
    instantiating concrete handlers.
    
    ## What Changed
    - Add a `codex-tools` registry-plan layer in
    `codex-rs/tools/src/tool_registry_plan.rs` and
    `codex-rs/tools/src/tool_registry_plan_types.rs`.
    - Move feature-gated tool-spec assembly, MCP/dynamic tool conversion,
    tool-search aliases, and code-mode nested-plan expansion into
    `codex-tools`.
    - Keep `codex-rs/core/src/tools/spec.rs` as the core-side adapter that
    maps each planned handler kind to concrete runtime handler instances.
    - Update `spec_tests.rs` to import the moved `codex_tools` symbols
    directly instead of relying on top-level `spec.rs` re-exports.
    
    This is intended to be a straight refactor with no behavior change and
    no new test surface.
    
    ## Verification
    - `cargo test -p codex-tools`
    - `cargo test -p codex-core tools::spec::tests`
    
    ---
    [//]: # (BEGIN SAPLING FOOTER)
    Stack created with [Sapling](https://sapling-scm.com). Best reviewed
    with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16513).
    * #16521
    * __->__ #16513
  • fix: add update to Cargo.lock that was missed in #16512 (#16516)
    This PR updates `Cargo.lock` to remove `codex-core` from
    `mcp_test_support`, which corresponds to
    `codex-rs/mcp-server/tests/common/Cargo.toml`. As noted in #16512, it
    updated that crate to drop its `codex-core` dependency.
  • core: remove cross-crate re-exports from lib.rs (#16512)
    ## Why
    
    `codex-core` was re-exporting APIs owned by sibling `codex-*` crates,
    which made downstream crates depend on `codex-core` as a proxy module
    instead of the actual owner crate.
    
    Removing those forwards makes crate boundaries explicit and lets leaf
    crates drop unnecessary `codex-core` dependencies. In this PR, this
    reduces the dependency on `codex-core` to `codex-login` in the following
    files:
    
    ```
    codex-rs/backend-client/Cargo.toml
    codex-rs/mcp-server/tests/common/Cargo.toml
    ```
    
    ## What
    
    - Remove `codex-rs/core/src/lib.rs` re-exports for symbols owned by
    `codex-login`, `codex-mcp`, `codex-rollout`, `codex-analytics`,
    `codex-protocol`, `codex-shell-command`, `codex-sandboxing`,
    `codex-tools`, and `codex-utils-path`.
    - Delete the `default_client` forwarding shim in `codex-rs/core`.
    - Update in-crate and downstream callsites to import directly from the
    owning `codex-*` crate.
    - Add direct Cargo dependencies where callsites now target the owner
    crate, and remove `codex-core` from `codex-rs/backend-client`.
  • Extract code-mode nested tool collection into codex-tools (#16509)
    ## Why
    This is another small step in the `codex-core` -> `codex-tools`
    migration described in `AGENTS.md`.
    
    `core/src/tools/spec.rs` and `core/src/tools/code_mode/mod.rs` were both
    hand-rolling the same pure transformation: convert visible `ToolSpec`s
    into code-mode nested tool definitions, then sort and deduplicate by
    tool name. That logic does not depend on core runtime state or handlers,
    so keeping it in `codex-core` makes `spec.rs` harder to peel out later
    than it needs to be.
    
    ## What Changed
    - Add `collect_code_mode_tool_definitions()` to
    `codex-rs/tools/src/code_mode.rs`.
    - Reuse that helper from `codex-rs/core/src/tools/spec.rs` when
    assembling the `exec` tool description.
    - Reuse the same helper from `codex-rs/core/src/tools/code_mode/mod.rs`
    when exposing nested tool metadata to the code-mode runtime.
    
    This is intended to be a straight refactor with no behavior change and
    no new test surface.
    
    ## Verification
    - `cargo test -p codex-tools`
    - `cargo test -p codex-core tools::spec::tests`
    - `cargo test -p codex-core code_mode_only_`