Commit Graph

2378 Commits

  • [hooks] add non-streaming (non-stdin style) shell-only PreToolUse support (#15211)
    - add `PreToolUse` hook for bash-like tool execution only at first
    - block shell execution before dispatch with deny-only hook behavior
    - introduces common.rs matcher framework for matching when hooks are run
    
    example run:
    
    ```
    › run three parallel echo commands, and the second one should echo "[block-pre-tool-use]" as a test
    
    
    • Running the three echo commands in parallel now and I’ll report the output directly.
    
    • Running PreToolUse hook: name for demo pre tool use hook
    
    • Running PreToolUse hook: name for demo pre tool use hook
    
    • Running PreToolUse hook: name for demo pre tool use hook
    
    PreToolUse hook (completed)
      warning: wizard-tower PreToolUse demo inspected Bash: echo "first parallel echo"
      
    PreToolUse hook (blocked)
      warning: wizard-tower PreToolUse demo blocked a Bash command on purpose.
      feedback: PreToolUse demo blocked the command. Remove [block-pre-tool-use] to continue.
    
    PreToolUse hook (completed)
      warning: wizard-tower PreToolUse demo inspected Bash: echo "third parallel echo"
    
    • Ran echo "first parallel echo"
      └ first parallel echo
    
    • Ran echo "third parallel echo"
      └ third parallel echo
    
    • Three little waves went out in parallel.
    
      1. printed first parallel echo
      2. was blocked before execution because it contained the exact test string [block-pre-tool-use]
      3. printed third parallel echo
    
      There was also an unrelated macOS defaults warning around the successful commands, but the echoes
      themselves worked fine. If you want, I can rerun the second one with a slightly modified string so
      it passes cleanly.
    ```
  • feat: new op type for sub-agents communication (#15556)
    Add `InterAgentCommunication` for v2 agent communication
  • feat: support disable skills by name. (#15378)
    Support disabling skills by name, primarily for plugin skills. We can’t
    use the path, since plugin skill paths may change across versions.
  • Thread guardian Responses API errors into denial rationale (#15516)
    ## Summary
    - capture the last guardian `EventMsg::Error` while waiting for review
    completion
    - reuse that error as the denial rationale when the review turn
    completes without an assessment payload
    - add a regression test for the `/responses` HTTP 400 path
    
    ## Testing
    - `just fmt`
    - `cargo test -p codex-core
    guardian_review_surfaces_responses_api_errors_in_rejection_reason`
    - `just argument-comment-lint -p codex-core`
    
    ## Notes
    - `cargo test -p codex-core` still fails on the pre-existing unrelated
    test
    `tools::js_repl::tests::js_repl_imported_local_files_can_access_repl_globals`
    in this environment (`mktemp ... Operation not permitted` while
    downloading `dotslash`)
    
    Co-authored-by: Codex <noreply@openai.com>
  • Fix: proactive auth refresh to reload guarded disk state first (#15357)
    ## Summary
    
    Fix a managed ChatGPT auth bug where a stale Codex process could
    proactively refresh using an old in-memory refresh token even after
    another process had already rotated auth on disk.
    
    This changes the proactive `AuthManager::auth()` path to reuse the
    existing guarded `refresh_token()` flow instead of calling the refresh
    endpoint directly from cached auth state.
    
    ## Original Issue
    
    Users reported repeated `codexd` log lines like:
    
    ```text
    ERROR codex_core::auth: Failed to refresh token: error sending request for url (https://auth.openai.com/oauth/token)
    ```
    
    In practice this showed up most often when multiple `codexd` processes
    were left running. Killing the extra processes stopped the noise, which
    suggested the issue was caused by stale auth state across processes
    rather than invalid user credentials.
    
    ## Diagnosis
    
    The bug was in the proactive refresh path used by `AuthManager::auth()`:
    
    - Process A could refresh successfully, rotate refresh token `R0` to
    `R1`, and persist the updated auth state plus `last_refresh` to disk.
    - Process B could keep an older auth snapshot cached in memory, still
    holding `R0` and the old `last_refresh`.
    - Later, when Process B called `auth()`, it checked staleness from its
    cached in-memory auth instead of first reloading from disk.
    - Because that cached `last_refresh` was stale, Process B would
    proactively call `/oauth/token` with stale refresh token `R0`.
    - On failure, `auth()` logged the refresh error but kept returning the
    same stale cached auth, so repeated `auth()` calls could keep retrying
    with dead state.
    
    This differed from the existing unauthorized-recovery flow, which
    already did the safer thing: guarded reload from disk first, then
    refresh only if the on-disk auth was unchanged.
    
    ## What Changed
    
    - Switched proactive refresh in `AuthManager::auth()` to:
      - do a pure staleness check on cached auth
      - call `refresh_token()` when stale
    - return the original cached auth on genuine refresh failure, preserving
    existing outward behavior
    - Removed the direct proactive refresh-from-cached-state path
    - Added regression tests covering:
      - stale cached auth with newer same-account auth already on disk
    - the same scenario even when the refresh endpoint would fail if called
    
    ## Why This Fix
    
    `refresh_token()` already contains the right cross-process safety
    behavior:
    
    - guarded reload from disk
    - same-account verification
    - skip-refresh when another process already changed auth
    
    Reusing that path makes proactive refresh consistent with unauthorized
    recovery and prevents stale processes from trying to refresh
    already-rotated tokens.
    
    ## Testing
    
    Test shape:
    
    - create a fresh temp `CODEX_HOME` from `~/.codex/auth.json`
    - force `last_refresh` to an old timestamp so proactive refresh is
    required
    - start two long-lived helper processes against the same auth file
    - start `B` first so it caches stale auth and sleeps
    - start `A` second so it refreshes first
    - point both at a local mock `/oauth/token` server
    - inspect whether `B` makes a second refresh request with the stale
    in-memory token, or reloads the rotated token from disk
    
    ### Before the fix
    
    The repro showed the bug clearly: the mock server saw two refreshes with
    the same stale token, `A` rotated to a new token, and `B` still returned
    the stale token instead of reloading from disk.
    
    ```text
    POST /oauth/token refresh_token=rt_j6s0...
    POST /oauth/token refresh_token=rt_j6s0...
    
    B:cached_before=rt_j6s0...
    B:cached_after=rt_j6s0...
    B:returned=rt_j6s0...
    
    A:cached_before=rt_j6s0...
    A:cached_after=rotated-refresh-token-logged-run-v2
    A:returned=rotated-refresh-token-logged-run-v2
    ```
    
    ### After the fix
    
    After the fix, the mock server saw only one refresh request. `A`
    refreshed once, and `B` started with the stale token but reloaded and
    returned the rotated token.
    
    ```text
    POST /oauth/token refresh_token=rt_j6s0...
    
    B:cached_before=rt_j6s0...
    B:cached_after=rotated-refresh-token-fix-branch
    B:returned=rotated-refresh-token-fix-branch
    
    A:cached_before=rt_j6s0...
    A:cached_after=rotated-refresh-token-fix-branch
    A:returned=rotated-refresh-token-fix-branch
    ```
    
    This shows the new behavior: `A` refreshes once, then `B` reuses the
    updated auth from disk instead of making a second refresh request with
    the stale token.
  • feat: structured multi-agent output (#15515)
    Send input now sends messages as assistant message and with this format:
    
    ```
    author: /root/worker_a
    recipient: /root/worker_a/tester
    other_recipients: []
    Content: bla bla bla. Actual content. Only text for now
    ```
  • tui: queue follow-ups during manual /compact (#15259)
    ## Summary
    - queue input after the user submits `/compact` until that manual
    compact turn ends
    - mirror the same behavior in the app-server TUI
    - add regressions for input queued before compact starts and while it is
    running
    
    Co-authored-by: Codex <noreply@openai.com>
  • fix: fall back to vendored bubblewrap when system bwrap lacks --argv0 (#15338)
    ## Why
    
    Fixes [#15283](https://github.com/openai/codex/issues/15283), where
    sandboxed tool calls fail on older distro `bubblewrap` builds because
    `/usr/bin/bwrap` does not understand `--argv0`. The upstream [bubblewrap
    v0.9.0 release
    notes](https://github.com/containers/bubblewrap/releases/tag/v0.9.0)
    explicitly call out `Add --argv0`. Flipping `use_legacy_landlock`
    globally works around that compatibility bug, but it also weakens the
    default Linux sandbox and breaks proxy-routed and split-policy cases
    called out in review.
    
    The follow-up Linux CI failure was in the new launcher test rather than
    the launcher logic: the fake `bwrap` helper stayed open for writing, so
    Linux would not exec it. This update also closes the user-visibility gap
    from review by surfacing the same startup warning when `/usr/bin/bwrap`
    is present but too old for `--argv0`, not only when it is missing.
    
    ## What Changed
    
    - keep `use_legacy_landlock` default-disabled
    - teach `codex-rs/linux-sandbox/src/launcher.rs` to fall back to the
    vendored bubblewrap build when `/usr/bin/bwrap` does not advertise
    `--argv0` support
    - add launcher tests for supported, unsupported, and missing system
    `bwrap`
    - write the fake `bwrap` test helper to a closed temp path so the
    supported-path launcher test works on Linux too
    - extend the startup warning path so Codex warns when `/usr/bin/bwrap`
    is missing or too old to support `--argv0`
    - mirror the warning/fallback wording across
    `codex-rs/linux-sandbox/README.md` and `codex-rs/core/README.md`,
    including that the fallback is the vendored bubblewrap compiled into the
    binary
    - cite the upstream `bubblewrap` release that introduced `--argv0`
    
    ## Verification
    
    - `bazel test --config=remote --platforms=//:rbe
    //codex-rs/linux-sandbox:linux-sandbox-unit-tests
    --test_filter=launcher::tests::prefers_system_bwrap_when_help_lists_argv0
    --test_output=errors`
    - `cargo test -p codex-core system_bwrap_warning`
    - `cargo check -p codex-exec -p codex-tui -p codex-tui-app-server -p
    codex-app-server`
    - `just argument-comment-lint`
  • core: snapshot fork startup context injection (#15443)
    ## Summary
    - add a snapshot-style core test for fork startup context injection
    followed by first-turn diff injection
    - capture the current duplicated startup-plus-turn context behavior
    without changing runtime logic
    
    ## Testing
    - not run locally; relying on CI
    - just fmt
    
    ---------
    
    Co-authored-by: Codex <noreply@openai.com>
  • Remove smart_approvals alias migration (#15464)
    Remove the legacy `smart_approvals` config migration from core config
    loading.
    
    This change:
    - stops rewriting `smart_approvals` into `guardian_approval`
    - stops backfilling `approvals_reviewer = "guardian_subagent"`
    - replaces the migration tests with regression coverage that asserts the
    deprecated key is ignored in root and profile scopes
    
    Verification:
    - `just fmt`
    - `cargo test -p codex-core smart_approvals_alias_is_ignored`
    - `cargo test -p codex-core approvals_reviewer_`
    - `just argument-comment-lint`
    
    Notes:
    - `cargo test -p codex-core` still hits an unrelated existing failure in
    `tools::js_repl::tests::js_repl_imported_local_files_can_access_repl_globals`;
    the JS REPL kernel exits after `mktemp` fails under the current
    environment.
    
    Enhancement request: requested cleanup to delete the `smart_approvals`
    alias migration; no public issue link is available.
    
    Co-authored-by: Codex <noreply@openai.com>
  • chore(exec_policy) ExecPolicyRequirementScenario tests (#15415)
    ## Summary
    Consolidate exec_policy_tests on `ExecApprovalRequirementScenario` for
    consistency.
    
    ## Testing
    - [x] These are tests
  • chore(context) Include guardian approval context (#15366)
    ## Summary
    Include the guardian context in the developer message for approvals
    
    ## Testing
    - [x] Updated unit tests
  • [plugins] Fix plugin explicit mention context management. (#15372)
    - [x] Fix plugin explicit mention context management.
  • Code mode on v8 (#15276)
    Moves Code Mode to a new crate with no dependencies on codex. This
    create encodes the code mode semantics that we want for lifetime,
    mounting, tool calling.
    
    The model-facing surface is mostly unchanged. `exec` still runs raw
    JavaScript, `wait` still resumes or terminates a `cell_id`, nested tools
    are still available through `tools.*`, and helpers like `text`, `image`,
    `store`, `load`, `notify`, `yield_control`, and `exit` still exist.
    
    The major change is underneath that surface:
    
    - Old code mode was an external Node runtime.
    - New code mode is an in-process V8 runtime embedded directly in Rust.
    - Old code mode managed cells inside a long-lived Node runner process.
    - New code mode manages cells in Rust, with one V8 runtime thread per
    active `exec`.
    - Old code mode used JSON protocol messages over child stdin/stdout plus
    Node worker-thread messages.
    - New code mode uses Rust channels and direct V8 callbacks/events.
    
    This PR also fixes the two migration regressions that fell out of that
    substrate change:
    
    - `wait { terminate: true }` now waits for the V8 runtime to actually
    stop before reporting termination.
    - synchronous top-level `exit()` now succeeds again instead of surfacing
    as a script error.
    
    ---
    
    - `core/src/tools/code_mode/*` is now mostly an adapter layer for the
    public `exec` / `wait` tools.
    - `code-mode/src/service.rs` owns cell sessions and async control flow
    in Rust.
    - `code-mode/src/runtime/*.rs` owns the embedded V8 isolate and
    JavaScript execution.
    - each `exec` spawns a dedicated runtime thread plus a Rust
    session-control task.
    - helper globals are installed directly into the V8 context instead of
    being injected through a source prelude.
    - helper modules like `tools.js` and `@openai/code_mode` are synthesized
    through V8 module resolution callbacks in Rust.
    
    ---
    
    Also added a benchmark for showing the speed of init and use of a code
    mode env:
    ```
    $ cargo bench -p codex-code-mode --bench exec_overhead -- --samples 30 --warm-iterations 25 --tool-counts 0,32,128
    Finished [`bench` profile [optimized]](https://doc.rust-lang.org/cargo/reference/profiles.html#default-profiles) target(s) in 0.18s
         Running benches/exec_overhead.rs (target/release/deps/exec_overhead-008c440d800545ae)
    exec_overhead: samples=30, warm_iterations=25, tool_counts=[0, 32, 128]
    scenario       tools samples    warmups      iters      mean/exec       p95/exec       rssΔ p50       rssΔ max
    cold_exec          0      30          0          1         1.13ms         1.20ms        8.05MiB        8.06MiB
    warm_exec          0      30          1         25       473.43us       512.49us      912.00KiB        1.33MiB
    cold_exec         32      30          0          1         1.03ms         1.15ms        8.08MiB        8.11MiB
    warm_exec         32      30          1         25       509.73us       545.76us      960.00KiB        1.30MiB
    cold_exec        128      30          0          1         1.14ms         1.19ms        8.30MiB        8.34MiB
    warm_exec        128      30          1         25       575.08us       591.03us      736.00KiB      864.00KiB
    memory uses a fresh-process max RSS delta for each scenario
    ```
    
    ---------
    
    Co-authored-by: Codex <noreply@openai.com>
  • fix(core) disable command_might_be_dangerous when unsandboxed (#15036)
    ## Summary
    If we are in a mode that is already explicitly un-sandboxed, then
    `ApprovalPolicy::Never` should not block dangerous commands.
    
    ## Testing
    - [x] Existing unit test covers old behavior
    - [x] Added a unit test for this new case
  • fix: allow restricted filesystem profiles to read helper executables (#15114)
    ## Summary
    
    This PR fixes restricted filesystem permission profiles so Codex's
    runtime-managed helper executables remain readable without requiring
    explicit user configuration.
    
    - add implicit readable roots for the configured `zsh` helper path and
    the main execve wrapper
    - allowlist the shared `$CODEX_HOME/tmp/arg0` root when the execve
    wrapper lives there, so session-specific helper paths keep working
    - dedupe injected paths and avoid adding duplicate read entries to the
    sandbox policy
    - add regression coverage for restricted read mode with helper
    executable overrides
    
    ## Testing 
    before this change: got this error when executing a shell command via
    zsh fork:
    ```
    "sandbox error: sandbox denied exec error, exit code: 127, stdout: , stderr: /etc/zprofile:11: operation not permitted: /usr/libexec/path_helper\nzsh:1: operation not permitted: .codex/skills/proxy-a/scripts/fetch_example.sh\n"
    ```
    
    saw this change went away after this change, meaning the readable roots
    and injected correctly.
  • chore(core) Remove Feature::PowershellUtf8 (#15128)
    ## Summary
    This feature has been enabled for powershell for a while now, let's get
    rid of the logic
    
    ## Testing
    - [x] Unit tests
  • [apps] Use ARC for yolo mode. (#15273)
    - [x] Use ARC for yolo mode.
  • feat: change multi-agent to use path-like system instead of uuids (#15313)
    This PR add an URI-based system to reference agents within a tree. This
    comes from a sync between research and engineering.
    
    The main agent (the one manually spawned by a user) is always called
    `/root`. Any sub-agent spawned by it will be `/root/agent_1` for example
    where `agent_1` is chosen by the model.
    
    Any agent can contact any agents using the path.
    
    Paths can be used either in absolute or relative to the calling agents
    
    Resume is not supported for now on this new path
  • Add remote test skill (#15324)
    Teach codex to run remote tests.
  • Add remote env CI matrix and integration test (#14869)
    `CODEX_TEST_REMOTE_ENV` will make `test_codex` start the executor
    "remotely" (inside a docker container) turning any integration test into
    remote test.
  • feat: prefer git for curated plugin sync (#15275)
    start with git clone, fallback to http.
  • Feat/restore image generation history (#15223)
    Restore image generation items in resumed thread history
  • Add guardian follow-up reminder (#15262)
    ## Summary
    - add a short guardian follow-up developer reminder before reused
    reviews
    - cache prior-review state on the guardian session instead of rescanning
    full history on each request
    - update guardian follow-up coverage and snapshot expectations
    
    ---------
    
    Co-authored-by: Codex <noreply@openai.com>
  • feat: Add One-Time Startup Remote Plugin Sync (#15264)
    For early users who have already enabled apps, we should enable plugins
    as part of the initial setup.
  • Use released DotSlash package for argument-comment lint (#15199)
    ## Why
    The argument-comment lint now has a packaged DotSlash artifact from
    [#15198](https://github.com/openai/codex/pull/15198), so the normal repo
    lint path should use that released payload instead of rebuilding the
    lint from source every time.
    
    That keeps `just clippy` and CI aligned with the shipped artifact while
    preserving a separate source-build path for people actively hacking on
    the lint crate.
    
    The current alpha package also exposed two integration wrinkles that the
    repo-side prebuilt wrapper needs to smooth over:
    - the bundled Dylint library filename includes the host triple, for
    example `@nightly-2025-09-18-aarch64-apple-darwin`, and Dylint derives
    `RUSTUP_TOOLCHAIN` from that filename
    - on Windows, Dylint's driver path also expects `RUSTUP_HOME` to be
    present in the environment
    
    Without those adjustments, the prebuilt CI jobs fail during `cargo
    metadata` or driver setup. This change makes the checked-in prebuilt
    wrapper normalize the packaged library name to the plain
    `nightly-2025-09-18` channel before invoking `cargo-dylint`, and it
    teaches both the wrapper and the packaged runner source to infer
    `RUSTUP_HOME` from `rustup show home` when the environment does not
    already provide it.
    
    After the prebuilt Windows lint job started running successfully, it
    also surfaced a handful of existing anonymous literal callsites in
    `windows-sandbox-rs`. This PR now annotates those callsites so the new
    cross-platform lint job is green on the current tree.
    
    ## What Changed
    - checked in the current
    `tools/argument-comment-lint/argument-comment-lint` DotSlash manifest
    - kept `tools/argument-comment-lint/run.sh` as the source-build wrapper
    for lint development
    - added `tools/argument-comment-lint/run-prebuilt-linter.sh` as the
    normal enforcement path, using the checked-in DotSlash package and
    bundled `cargo-dylint`
    - updated `just clippy` and `just argument-comment-lint` to use the
    prebuilt wrapper
    - split `.github/workflows/rust-ci.yml` so source-package checks live in
    a dedicated `argument_comment_lint_package` job, while the released lint
    runs in an `argument_comment_lint_prebuilt` matrix on Linux, macOS, and
    Windows
    - kept the pinned `nightly-2025-09-18` toolchain install in the prebuilt
    CI matrix, since the prebuilt package still relies on rustup-provided
    toolchain components
    - updated `tools/argument-comment-lint/run-prebuilt-linter.sh` to
    normalize host-qualified nightly library filenames, keep the `rustup`
    shim directory ahead of direct toolchain `cargo` binaries, and export
    `RUSTUP_HOME` when needed for Windows Dylint driver setup
    - updated `tools/argument-comment-lint/src/bin/argument-comment-lint.rs`
    so future published DotSlash artifacts apply the same nightly-filename
    normalization and `RUSTUP_HOME` inference internally
    - fixed the remaining Windows lint violations in
    `codex-rs/windows-sandbox-rs` by adding the required `/*param*/`
    comments at the reported callsites
    - documented the checked-in DotSlash file, wrapper split, archive
    layout, nightly prerequisite, and Windows `RUSTUP_HOME` requirement in
    `tools/argument-comment-lint/README.md`
  • Split features into codex-features crate (#15253)
    - Split the feature system into a new `codex-features` crate.
    - Cut `codex-core` and workspace consumers over to the new config and
    warning APIs.
    
    Co-authored-by: Ahmed Ibrahim <219906144+aibrahim-oai@users.noreply.github.com>
    Co-authored-by: Codex <noreply@openai.com>
  • fix: Distinguish missing and empty plugin products (#15263)
    Treat [] as no product allowed, empty as all products allowed.
  • [plugins] Install MCPs when calling plugin/install (#15195)
    - [x] Auth MCPs when installing plugins.
  • Move auth code into login crate (#15150)
    - Move the auth implementation and token data into codex-login.
    - Keep codex-core re-exporting that surface from codex-login for
    existing callers.
    
    ---------
    
    Co-authored-by: Codex <noreply@openai.com>
  • Refactor ExecServer filesystem split between local and remote (#15232)
    For each feature we have:
    1. Trait exposed on environment
    2. **Local Implementation** of the trait
    3. Remote implementation that uses the client to proxy via network
    4. Handler implementation that handles PRC requests and calls into
    **Local Implementation**
  • changed save directory to codex_home (#15222)
    saving image gen default save directory to
    codex_home/imagegen/thread_id/
  • Plumb MCP turn metadata through _meta (#15190)
    ## Summary
    
    Some background. We're looking to instrument GA turns end to end. Right
    now a big gap is grouping mcp tool calls with their codex sessions. We
    send session id and turn id headers to the responses call but not the
    mcp/wham calls.
    
    Ideally we could pass the args as headers like with responses, but given
    the setup of the rmcp client, we can't send as headers without either
    changing the rmcp package upstream to allow per request headers or
    introducing a mutex which break concurrency. An earlier attempt made the
    assumption that we had 1 client per thread, which allowed us to set
    headers at the start of a turn. @pakrym mentioned that this assumption
    might break in the near future.
    
    So the solution now is to package the turn metadata/session id into the
    _meta field in the post body and pull out in codex-backend.
    
    - send turn metadata to MCP servers via `tools/call` `_meta` instead of
    assuming per-thread request headers on shared clients
    - preserve the existing `_codex_apps` metadata while adding
    `x-codex-turn-metadata` for all MCP tool calls
    - extend tests to cover both custom MCP servers and the codex apps
    search flow
    
    ---------
    
    Co-authored-by: Codex <noreply@openai.com>
  • add specific tool guidance for Windows destructive commands (#15207)
    updated Windows shell/unified_exec tool descriptions:
    
    `exec_command`
    ```text
    Runs a command in a PTY, returning output or a session ID for ongoing interaction.
    
    Windows safety rules:
    - Do not compose destructive filesystem commands across shells. Do not enumerate paths in PowerShell and then pass them to `cmd /c`, batch builtins, or another shell for deletion or moving. Use one shell end-to-end, prefer native PowerShell cmdlets such as `Remove-Item` / `Move-Item` with `-LiteralPath`, and avoid string-built shell commands for file operations.
    - Before any recursive delete or move on Windows, verify the resolved absolute target paths stay within the intended workspace or explicitly named target directory. Never issue a recursive delete or move against a computed path if the final target has not been checked.
    ```
    
    `shell`
    ```text
    Runs a Powershell command (Windows) and returns its output. Arguments to `shell` will be passed to CreateProcessW(). Most commands should be prefixed with ["powershell.exe", "-Command"].
    
    Examples of valid command strings:
    
    - ls -a (show hidden): ["powershell.exe", "-Command", "Get-ChildItem -Force"]
    - recursive find by name: ["powershell.exe", "-Command", "Get-ChildItem -Recurse -Filter *.py"]
    - recursive grep: ["powershell.exe", "-Command", "Get-ChildItem -Path C:\\myrepo -Recurse | Select-String -Pattern 'TODO' -CaseSensitive"]
    - ps aux | grep python: ["powershell.exe", "-Command", "Get-Process | Where-Object { $_.ProcessName -like '*python*' }"]
    - setting an env var: ["powershell.exe", "-Command", "$env:FOO='bar'; echo $env:FOO"]
    - running an inline Python script: ["powershell.exe", "-Command", "@'\nprint('Hello, world!')\n'@ | python -"]
    
    Windows safety rules:
    - Do not compose destructive filesystem commands across shells. Do not enumerate paths in PowerShell and then pass them to `cmd /c`, batch builtins, or another shell for deletion or moving. Use one shell end-to-end, prefer native PowerShell cmdlets such as `Remove-Item` / `Move-Item` with `-LiteralPath`, and avoid string-built shell commands for file operations.
    - Before any recursive delete or move on Windows, verify the resolved absolute target paths stay within the intended workspace or explicitly named target directory. Never issue a recursive delete or move against a computed path if the final target has not been checked.
    ```
    
    `shell_command`
    ```text
    Runs a Powershell command (Windows) and returns its output.
    
    Examples of valid command strings:
    
    - ls -a (show hidden): "Get-ChildItem -Force"
    - recursive find by name: "Get-ChildItem -Recurse -Filter *.py"
    - recursive grep: "Get-ChildItem -Path C:\\myrepo -Recurse | Select-String -Pattern 'TODO' -CaseSensitive"
    - ps aux | grep python: "Get-Process | Where-Object { $_.ProcessName -like '*python*' }"
    - setting an env var: "$env:FOO='bar'; echo $env:FOO"
    - running an inline Python script: "@'\nprint('Hello, world!')\n'@ | python -"
    
    Windows safety rules:
    - Do not compose destructive filesystem commands across shells. Do not enumerate paths in PowerShell and then pass them to `cmd /c`, batch builtins, or another shell for deletion or moving. Use one shell end-to-end, prefer native PowerShell cmdlets such as `Remove-Item` / `Move-Item` with `-LiteralPath`, and avoid string-built shell commands for file operations.
    - Before any recursive delete or move on Windows, verify the resolved absolute target paths stay within the intended workspace or explicitly named target directory. Never issue a recursive delete or move against a computed path if the final target has not been checked.
    ```
  • Move terminal module to terminal-detection crate (#15216)
    - Move core/src/terminal.rs and its tests into a standalone
    terminal-detection workspace crate.
    - Update direct consumers to depend on codex-terminal-detection and
    import terminal APIs directly.
    
    ---------
    
    Co-authored-by: Codex <noreply@openai.com>
  • feat(tui): add /title terminal title configuration (#12334)
    ## Problem
    
    When multiple Codex sessions are open at once, terminal tabs and windows
    are hard to distinguish from each other. The existing status line only
    helps once the TUI is already focused, so it does not solve the "which
    tab is this?" problem.
    
    This PR adds a first-class `/title` command so the terminal window or
    tab title can carry a short, configurable summary of the current
    session.
    
    ## Screenshot
    
    <img width="849" height="320" alt="image"
    src="https://github.com/user-attachments/assets/8b112927-7890-45ed-bb1e-adf2f584663d"
    />
    
    ## Mental model
    
    `/statusline` and `/title` are separate status surfaces with different
    constraints. The status line is an in-app footer that can be denser and
    more detailed. The terminal title is external terminal metadata, so it
    needs short, stable segments that still make multiple sessions easy to
    tell apart.
    
    The `/title` configuration is an ordered list of compact items. By
    default it renders `spinner,project`, so active sessions show
    lightweight progress first while idle sessions still stay easy to
    disambiguate. Each configured item is omitted when its value is not
    currently available rather than forcing a placeholder.
    
    ## Non-goals
    
    This does not merge `/title` into `/statusline`, and it does not add an
    arbitrary free-form title string. The feature is intentionally limited
    to a small set of structured items so the title stays short and
    reviewable.
    
    This also does not attempt to restore whatever title the terminal or
    shell had before Codex started. When Codex clears the title, it clears
    the title Codex last wrote.
    
    ## Tradeoffs
    
    A separate `/title` command adds some conceptual overlap with
    `/statusline`, but it keeps title-specific constraints explicit instead
    of forcing the status line model to cover two different surfaces.
    
    Title refresh can happen frequently, so the implementation now shares
    parsing and git-branch orchestration between the status line and title
    paths, and caches the derived project-root name by cwd. That keeps the
    hot path cheap without introducing background polling.
    
    ## Architecture
    
    The TUI gets a new `/title` slash command and a dedicated picker UI for
    selecting and ordering terminal-title items. The chosen ids are
    persisted in `tui.terminal_title`, with `spinner` and `project` as the
    default when the config is unset. `status` remains available as a
    separate text item, so configurations like `spinner,status` render
    compact progress like `⠋ Working`.
    
    `ChatWidget` now refreshes both status surfaces through a shared
    `refresh_status_surfaces()` path. That shared path parses configured
    items once, warns on invalid ids once, synchronizes shared cached state
    such as git-branch lookup, then renders the footer status line and
    terminal title from the same snapshot.
    
    Low-level OSC title writes live in `codex-rs/tui/src/terminal_title.rs`,
    which owns the terminal write path and last-mile sanitization before
    emitting OSC 0.
    
    ## Security
    
    Terminal-title text is treated as untrusted display content before Codex
    emits it. The write path strips control characters, removes invisible
    and bidi formatting characters that can make the title visually
    misleading, normalizes whitespace, and caps the emitted length.
    
    References used while implementing this:
    
    - [xterm control
    sequences](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html)
    - [WezTerm escape sequences](https://wezterm.org/escape-sequences.html)
    - [CWE-150: Improper Neutralization of Escape, Meta, or Control
    Sequences](https://cwe.mitre.org/data/definitions/150.html)
    - [CERT VU#999008 (Trojan Source)](https://kb.cert.org/vuls/id/999008)
    - [Trojan Source disclosure site](https://trojansource.codes/)
    - [Unicode Bidirectional Algorithm (UAX
    #9)](https://www.unicode.org/reports/tr9/)
    - [Unicode Security Considerations (UTR
    #36)](https://www.unicode.org/reports/tr36/)
    
    ## Observability
    
    Unknown configured title item ids are warned about once instead of
    repeatedly spamming the transcript. Live preview applies immediately
    while the `/title` picker is open, and cancel rolls the in-memory title
    selection back to the pre-picker value.
    
    If terminal title writes fail, the TUI emits debug logs around set and
    clear attempts. The rendered status label intentionally collapses richer
    internal states into compact title text such as `Starting...`, `Ready`,
    `Thinking...`, `Working...`, `Waiting...`, and `Undoing...` when
    `status` is configured.
    
    ## Tests
    
    Ran:
    
    - `just fmt`
    - `cargo test -p codex-tui`
    
    At the moment, the red Windows `rust-ci` failures are due to existing
    `codex-core` `apply_patch_cli` stack-overflow tests that also reproduce
    on `main`. The `/title`-specific `codex-tui` suite is green.
  • Log automated reviewer approval sources distinctly (#15201)
    ## Summary
    
    - log guardian-reviewed tool approvals as `source=automated_reviewer` in
    `codex.tool_decision`
    - keep direct user approvals as `source=user` and config-driven
    approvals as `source=config`
    
    ## Testing
    
    -
    `/Users/gabec/.codex/skills/codex-oss-fastdev/scripts/codex-rs-fmt-quiet.sh`
    -
    `/Users/gabec/.codex/skills/codex-oss-fastdev/scripts/codex-rs-test-quiet.sh
    -p codex-otel` (fails in sandboxed loopback bind tests under
    `otel/tests/suite/otlp_http_loopback.rs`)
    - `cargo test -p codex-core guardian -- --nocapture` (original-tree run
    reached Guardian tests and only hit sandbox-related listener/proxy
    failures)
    
    Co-authored-by: Codex <noreply@openai.com>
  • Add experimental exec server URL handling (#15196)
    Add a config and attempt to start the server.
  • [hooks] use a user message > developer message for prompt continuation (#14867)
    ## Summary
    
    Persist Stop-hook continuation prompts as `user` messages instead of
    hidden `developer` messages + some requested integration tests
    
    This is a followup to @pakrym 's comment in
    https://github.com/openai/codex/pull/14532 to make sure stop-block
    continuation prompts match training for turn loops
    
    - Stop continuation now writes `<hook_prompt hook_run_id="...">stop
    hook's user prompt<hook_prompt>`
    - Introduces quick-xml dependency, though we already indirectly depended
    on it anyway via syntect
    - This PR only has about 500 lines of actual logic changes, the rest is
    tests/schema
    
    ## Testing
    
    Example run (with a sessionstart hook and 3 stop hooks) - this shows
    context added by session start, then two stop hooks sending their own
    additional prompts in a new turn. The model responds with a single
    message addressing both. Then when that turn ends, the hooks detect that
    they just ran using `stop_hook_active` and decide not to infinite loop
    
    test files for this (unzip, move codex -> .codex):
    [codex.zip](https://github.com/user-attachments/files/26075806/codex.zip)
    
    ```
    › cats
    
    
    • Running SessionStart hook: lighting the observatory
    
    SessionStart hook (completed)
      warning: Hi, I'm a session start hook for wizard-tower (startup).
      hook context: A wimboltine stonpet is an exotic cuisine from hyperspace
    
    • Cats are tiny zen wizards, my friend: equal parts nap, mystery, and chaos. If you want, we can talk
      cat facts, cat breeds, cat names, or build something cat-themed in this repo.
    
    • Running Stop hook: checking the tower wards
    
    • Running Stop hook: sacking the guards
    
    • Running Stop hook: hiring the guards
    
    Stop hook (completed)
      warning: Wizard Tower Stop hook reviewed the completed reply (177 chars).
    
    Stop hook (blocked)
      warning: Wizard Tower Stop hook continuing conversation
      feedback: cook the stonpet
    
    Stop hook (blocked)
      warning: Wizard Tower Stop hook continuing conversation
      feedback: eat the cooked stonpet
    
    • Stonpet’s cooked, aloha style: flash-seared over a blue quasiflame, glazed with nebula salt, and
      rested until the hyperspace juices settle.
    
      Now we eat with gratitude, my friend. One mindful bite in, and the flavor is pure cosmic surf:
      smoky, bright, and totally out of this dimension.
    
    • Running Stop hook: checking the tower wards
    
    • Running Stop hook: sacking the guards
    
    • Running Stop hook: hiring the guards
    
    Stop hook (completed)
      warning: Wizard Tower Stop hook reviewed the completed reply (285 chars).
    
    Stop hook (completed)
      warning: Wizard Tower Stop hook saw a second pass and stayed calm to avoid a loop.
    
    Stop hook (completed)
      warning: Wizard Tower Stop hook saw a second pass and stayed calm to avoid a loop.
    ```
  • Move environment abstraction into exec server (#15125)
    The idea is that codex-exec exposes an Environment struct with services
    on it. Each of those is a trait.
    
    Depending on construction parameters passed to Environment they are
    either backed by local or remote server but core doesn't see these
    differences.
  • feat: add graph representation of agent network (#15056)
    Add a representation of the agent graph. This is now used for:
    * Cascade close agents (when I close a parent, it close the kids)
    * Cascade resume (oposite)
    
    Later, this will also be used for post-compaction stuffing of the
    context
    
    Direct fix for: https://github.com/openai/codex/issues/14458
  • feat: support product-scoped plugins. (#15041)
    1. Added SessionSource::Custom(String) and --session-source.
      2. Enforced plugin and skill products by session_source.
      3. Applied the same filtering to curated background refresh.
  • Add thread/shellCommand to app server API surface (#14988)
    This PR adds a new `thread/shellCommand` app server API so clients can
    implement `!` shell commands. These commands are executed within the
    sandbox, and the command text and output are visible to the model.
    
    The internal implementation mirrors the current TUI `!` behavior.
    - persist shell command execution as `CommandExecution` thread items,
    including source and formatted output metadata
    - bridge live and replayed app-server command execution events back into
    the existing `tui_app_server` exec rendering path
    
    This PR also wires `tui_app_server` to submit `!` commands through the
    new API.