434 Commits

• 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>

  Ahmed Ibrahim · 2026-03-19 20:12:07 -07:00
  2e22885e79
• 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>

  Ahmed Ibrahim · 2026-03-19 18:58:17 -07:00
  2aa4873802
• 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>

  Ahmed Ibrahim · 2026-03-19 14:08:04 -07:00
  7eb19e5319
• 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.

  xl-openai · 2026-03-19 00:46:15 -07:00
  db5781a088
• Revert "fix: harden plugin feature gating" (#15102)

  Reverts openai/codex#15020
  
  I messed up the commit in my PR and accidentally merged changes that
  were still under review.

  xl-openai · 2026-03-18 15:19:29 -07:00
  86982ca1f9
• fix: harden plugin feature gating (#15020)

  1. Use requirement-resolved config.features as the plugin gate.
  2. Guard plugin/list, plugin/read, and related flows behind that gate.
  3. Skip bad marketplace.json files instead of failing the whole list.
  4. Simplify plugin state and caching.

  xl-openai · 2026-03-18 10:11:43 -07:00
  580f32ad2a
• fix: honor active permission profiles in sandbox debug (#14293)

  ## Summary
  - stop `codex sandbox` from forcing legacy `sandbox_mode` when active
  `[permissions]` profiles are configured
  - keep the legacy `read-only` / `workspace-write` fallback for legacy
  configs and reject `--full-auto` for profile-based configs
  - use split filesystem and network policies in the macOS/Linux debug
  sandbox helpers and add regressions for the config-loading behavior
  
  
  assuming "codex/docs/private/secret.txt" = "none"
  ```
  codex -c 'default_permissions="limited-read-test"' sandbox macos -- <command> ...
  
  codex sandbox macos -- cat codex/docs/private/secret.txt >/dev/null; echo EXIT:$?
  cat: codex/docs/private/secret.txt: Operation not permitted
  EXIT:1
  ```
  
  ---------
  
  Co-authored-by: celia-oai <celia@openai.com>

  viyatb-oai · 2026-03-18 01:52:02 +00:00
  6fe8a05dcb
• generate an internal json schema for RolloutLine (#14434)

  ### Why
  i'm working on something that parses and analyzes codex rollout logs,
  and i'd like to have a schema for generating a parser/validator.
  
  `codex app-server generate-internal-json-schema` writes an
  `RolloutLine.json` file
  
  while doing this, i noticed we have a writer <> reader mismatch issue on
  `FunctionCallOutputPayload` and reasoning item ID -- added some schemars
  annotations to fix those
  
  ### Test
  
  ```
  $ just codex app-server generate-internal-json-schema --out ./foo
  ```
  
  generates an `RolloutLine.json` file, which i validated against jsonl
  files on disk
  
  `just codex app-server --help` doesn't expose the
  `generate-internal-json-schema` option by default, but you can do `just
  codex app-server generate-internal-json-schema --help` if you know the
  command
  
  everything else still works
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Keyan Zhang · 2026-03-17 11:19:42 -07:00
  904dbd414f
• Apply argument comment lint across codex-rs (#14652)

  ## Why
  
  Once the repo-local lint exists, `codex-rs` needs to follow the
  checked-in convention and CI needs to keep it from drifting. This commit
  applies the fallback `/*param*/` style consistently across existing
  positional literal call sites without changing those APIs.
  
  The longer-term preference is still to avoid APIs that require comments
  by choosing clearer parameter types and call shapes. This PR is
  intentionally the mechanical follow-through for the places where the
  existing signatures stay in place.
  
  After rebasing onto newer `main`, the rollout also had to cover newly
  introduced `tui_app_server` call sites. That made it clear the first cut
  of the CI job was too expensive for the common path: it was spending
  almost as much time installing `cargo-dylint` and re-testing the lint
  crate as a representative test job spends running product tests. The CI
  update keeps the full workspace enforcement but trims that extra
  overhead from ordinary `codex-rs` PRs.
  
  ## What changed
  
  - keep a dedicated `argument_comment_lint` job in `rust-ci`
  - mechanically annotate remaining opaque positional literals across
  `codex-rs` with exact `/*param*/` comments, including the rebased
  `tui_app_server` call sites that now fall under the lint
  - keep the checked-in style aligned with the lint policy by using
  `/*param*/` and leaving string and char literals uncommented
  - cache `cargo-dylint`, `dylint-link`, and the relevant Cargo
  registry/git metadata in the lint job
  - split changed-path detection so the lint crate's own `cargo test` step
  runs only when `tools/argument-comment-lint/*` or `rust-ci.yml` changes
  - continue to run the repo wrapper over the `codex-rs` workspace, so
  product-code enforcement is unchanged
  
  Most of the code changes in this commit are intentionally mechanical
  comment rewrites or insertions driven by the lint itself.
  
  ## Verification
  
  - `./tools/argument-comment-lint/run.sh --workspace`
  - `cargo test -p codex-tui-app-server -p codex-tui`
  - parsed `.github/workflows/rust-ci.yml` locally with PyYAML
  
  ---
  
  * -> #14652
  * #14651

  Michael Bolin · 2026-03-16 16:48:15 -07:00
  b77fe8fefe
• Move TUI on top of app server (parallel code) (#14717)

  This PR replicates the `tui` code directory and creates a temporary
  parallel `tui_app_server` directory. It also implements a new feature
  flag `tui_app_server` to select between the two tui implementations.
  
  Once the new app-server-based TUI is stabilized, we'll delete the old
  `tui` directory and feature flag.

  Eric Traut · 2026-03-16 10:49:19 -06:00
  db89b73a9c
• Start TUI on embedded app server (#14512)

  This PR is part of the effort to move the TUI on top of the app server.
  In a previous PR, we introduced an in-process app server and moved
  `exec` on top of it.
  
  For the TUI, we want to do the migration in stages. The app server
  doesn't currently expose all of the functionality required by the TUI,
  so we're going to need to support a hybrid approach as we make the
  transition.
  
  This PR changes the TUI initialization to instantiate an in-process app
  server and access its `AuthManager` and `ThreadManager` rather than
  constructing its own copies. It also adds a placeholder TUI event
  handler that will eventually translate app server events into TUI
  events. App server notifications are accepted but ignored for now. It
  also adds proper shutdown of the app server when the TUI terminates.

  Eric Traut · 2026-03-13 12:04:41 -06:00
  9dba7337f2
• Use a private desktop for Windows sandbox instead of Winsta0\Default (#14400)

  ## Summary
  - launch Windows sandboxed children on a private desktop instead of
  `Winsta0\Default`
  - make private desktop the default while keeping
  `windows.sandbox_private_desktop=false` as the escape hatch
  - centralize process launch through the shared
  `create_process_as_user(...)` path
  - scope the private desktop ACL to the launching logon SID
  
  ## Why
  Today sandboxed Windows commands run on the visible shared desktop. That
  leaves an avoidable same-desktop attack surface for window interaction,
  spoofing, and related UI/input issues. This change moves sandboxed
  commands onto a dedicated per-launch desktop by default so the sandbox
  no longer shares `Winsta0\Default` with the user session.
  
  The implementation stays conservative on security with no silent
  fallback back to `Winsta0\Default`
  
  If private-desktop setup fails on a machine, users can still opt out
  explicitly with `windows.sandbox_private_desktop=false`.
  
  ## Validation
  - `cargo build -p codex-cli`
  - elevated-path `codex exec` desktop-name probe returned
  `CodexSandboxDesktop-*`
  - elevated-path `codex exec` smoke sweep for shell commands, nested
  `pwsh`, jobs, and hidden `notepad` launch
  - unelevated-path full private-desktop compatibility sweep via `codex
  exec` with `-c windows.sandbox=unelevated`

  iceweasel-oai · 2026-03-13 10:13:39 -07:00
  6b3d82daca
• use scopes_supported for OAuth when present on MCP servers (#14419)

  Fixes [#8889](https://github.com/openai/codex/issues/8889).
  
  ## Summary
  - Discover and use advertised MCP OAuth `scopes_supported` when no
  explicit or configured scopes are present.
  - Apply the same scope precedence across `mcp add`, `mcp login`, skill
  dependency auto-login, and app-server MCP OAuth login.
  - Keep discovered scopes ephemeral and non-persistent.
  - Retry once without scopes for CLI and skill auto-login flows if the
  OAuth provider rejects discovered scopes.
  
  ## Motivation
  Some MCP servers advertise the scopes they expect clients to request
  during OAuth, but Codex was ignoring that metadata and typically
  starting OAuth with no scopes unless the user manually passed `--scopes`
  or configured `server.scopes`.
  
  That made compliant MCP servers harder to use out of the box and is the
  behavior described in
  [#8889](https://github.com/openai/codex/issues/8889).
  
  This change also brings our behavior in line with the MCP authorization
  spec's scope selection guidance:
  
  https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#scope-selection-strategy
  
  ## Behavior
  Scope selection now follows this order everywhere:
  1. Explicit request scopes / CLI `--scopes`
  2. Configured `server.scopes`
  3. Discovered `scopes_supported`
  4. Legacy empty-scope behavior
  
  Compatibility notes:
  - Existing working setups keep the same behavior because explicit and
  configured scopes still win.
  - Discovered scopes are never written back into config or token storage.
  - If discovery is missing, malformed, or empty, behavior falls back to
  the previous empty-scope path.
  - App-server login gets the same precedence rules, but does not add a
  transparent retry path in this change.
  
  ## Implementation
  - Extend streamable HTTP OAuth discovery to parse and normalize
  `scopes_supported`.
  - Add a shared MCP scope resolver in `core` so all login entrypoints use
  the same precedence rules.
  - Preserve provider callback errors from the OAuth flow so CLI/skill
  flows can safely distinguish provider rejections from other failures.
  - Reuse discovered scopes from the existing OAuth support check where
  possible instead of persisting new config.

  jgershen-oai · 2026-03-12 11:57:06 -07:00
  3e96c867fe
• fix(cli): support legacy use_linux_sandbox_bwrap flag (#14473)

  ## Summary
  - restore `use_linux_sandbox_bwrap` as a removed feature key so older
  `--enable` callers parse again
  - keep it as a no-op by leaving runtime behavior unchanged
  - add regression coverage for the legacy `--enable` path
  
  ## Testing
  - Not run (updated and pushed quickly)

  viyatb-oai · 2026-03-12 16:33:58 +00:00
  a30b807efe
• refactor: make bubblewrap the default Linux sandbox (#13996)

  ## Summary
  - make bubblewrap the default Linux sandbox and keep
  `use_legacy_landlock` as the only override
  - remove `use_linux_sandbox_bwrap` from feature, config, schema, and
  docs surfaces
  - update Linux sandbox selection, CLI/config plumbing, and related
  tests/docs to match the new default
  - fold in the follow-up CI fixes for request-permissions responses and
  Linux read-only sandbox error text

  viyatb-oai · 2026-03-11 23:31:18 -07:00
  04892b4ceb
• feat: simplify DB further (#13771)
  jif-oai · 2026-03-07 03:48:36 -08:00
  cf143bf71e
• feat: add auth login diagnostics (#13797)

  ## Problem
  
  Browser login failures historically leave support with an incomplete
  picture. HARs can show that the browser completed OAuth and reached the
  localhost callback, but they do not explain why the native client failed
  on the final `/oauth/token` exchange. Direct `codex login` also relied
  mostly on terminal stderr and the browser error page, so even when the
  login crate emitted better sign-in diagnostics through TUI or app-server
  flows, the one-shot CLI path still did not leave behind an easy artifact
  to collect.
  
  ## Mental model
  
  This implementation treats the browser page, the returned `io::Error`,
  and the normal structured log as separate surfaces with different safety
  requirements. The browser page and returned error preserve the detail
  that operators need to diagnose failures. The structured log stays
  narrower: it records reviewed lifecycle events, parsed safe fields, and
  redacted transport errors without becoming a sink for secrets or
  arbitrary backend bodies.
  
  Direct `codex login` now adds a fourth support surface: a small
  file-backed log at `codex-login.log` under the configured `log_dir`.
  That artifact carries the same login-target events as the other
  entrypoints without changing the existing stderr/browser UX.
  
  ## Non-goals
  
  This does not add auth logging to normal runtime requests, and it does
  not try to infer precise transport root causes from brittle string
  matching. The scope remains the browser-login callback flow in the
  `login` crate plus a direct-CLI wrapper that persists those events to
  disk.
  
  This also does not try to reuse the TUI logging stack wholesale. The TUI
  path initializes feedback, OpenTelemetry, and other session-oriented
  layers that are useful for an interactive app but unnecessary for a
  one-shot login command.
  
  ## Tradeoffs
  
  The implementation favors fidelity for caller-visible errors and
  restraint for persistent logs. Parsed JSON token-endpoint errors are
  logged safely by field. Non-JSON token-endpoint bodies remain available
  to the returned error so CLI and browser surfaces still show backend
  detail. Transport errors keep their real `reqwest` message, but attached
  URLs are surgically redacted. Custom issuer URLs are sanitized before
  logging.
  
  On the CLI side, the code intentionally duplicates a narrow slice of the
  TUI file-logging setup instead of sharing the full initializer. That
  keeps `codex login` easy to reason about and avoids coupling it to
  interactive-session layers that the command does not need.
  
  ## Architecture
  
  The core auth behavior lives in `codex-rs/login/src/server.rs`. The
  callback path now logs callback receipt, callback validation,
  token-exchange start, token-exchange success, token-endpoint non-2xx
  responses, and transport failures. App-server consumers still use this
  same login-server path via `run_login_server(...)`, so the same
  instrumentation benefits TUI, Electron, and VS Code extension flows.
  
  The direct CLI path in `codex-rs/cli/src/login.rs` now installs a small
  file-backed tracing layer for login commands only. That writes
  `codex-login.log` under `log_dir` with login-specific targets such as
  `codex_cli::login` and `codex_login::server`.
  
  ## Observability
  
  The main signals come from the `login` crate target and are
  intentionally scoped to sign-in. Structured logs include redacted issuer
  URLs, redacted transport errors, HTTP status, and parsed token-endpoint
  fields when available. The callback-layer log intentionally avoids
  `%err` on token-endpoint failures so arbitrary backend bodies do not get
  copied into the normal log file.
  
  Direct `codex login` now leaves a durable artifact for both failure and
  success cases. Example output from the new file-backed CLI path:
  
  Failing callback:
  
  ```text
  2026-03-06T22:08:54.143612Z  INFO codex_cli::login: starting browser login flow
  2026-03-06T22:09:03.431699Z  INFO codex_login::server: received login callback path=/auth/callback has_code=false has_state=true has_error=true state_valid=true
  2026-03-06T22:09:03.431745Z  WARN codex_login::server: oauth callback returned error error_code="access_denied" has_error_description=true
  ```
  
  Succeeded callback and token exchange:
  
  ```text
  2026-03-06T22:09:14.065559Z  INFO codex_cli::login: starting browser login flow
  2026-03-06T22:09:36.431678Z  INFO codex_login::server: received login callback path=/auth/callback has_code=true has_state=true has_error=false state_valid=true
  2026-03-06T22:09:36.436977Z  INFO codex_login::server: starting oauth token exchange issuer=https://auth.openai.com/ redirect_uri=http://localhost:1455/auth/callback
  2026-03-06T22:09:36.685438Z  INFO codex_login::server: oauth token exchange succeeded status=200 OK
  ```
  
  ## Tests
  
  - `cargo test -p codex-login`
  - `cargo clippy -p codex-login --tests -- -D warnings`
  - `cargo test -p codex-cli`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - manual direct `codex login` smoke tests for both a failing callback
  and a successful browser login
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Josh McKinney · 2026-03-06 15:00:37 -08:00
  4e68fb96e2
• feat(app-server-test-client): OTEL setup for tracing (#13493)

  ### Overview
  This PR:
  - Updates `app-server-test-client` to load OTEL settings from
  `$CODEX_HOME/config.toml` and initializes its own OTEL provider.
  - Add real client root spans to app-server test client traces.
  
  This updates `codex-app-server-test-client` so its Datadog traces
  reflect the full client-driven flow instead of a set of server spans
  stitched together under a synthetic parent.
  
  Before this change, the test client generated a fake `traceparent` once
  and reused it for every JSON-RPC request. That kept the requests in one
  trace, but there was no real client span at the top, so Datadog ended up
  showing the sequence in a slightly misleading way, where all RPCs were
  anchored under `initialize`.
  
  Now the test client:
  - loads OTEL settings from the normal Codex config path, including
  `$CODEX_HOME/config.toml` and existing --config overrides
  - initializes tracing the same way other Codex binaries do when trace
  export is enabled
  - creates a real client root span for each scripted command
  - creates per-request client spans for JSON-RPC methods like
  `initialize`, `thread/start`, and `turn/start`
  - injects W3C trace context from the current client span into
  request.trace instead of reusing a fabricated carrier
  
  This gives us a cleaner trace shape in Datadog:
  - one trace URL for the whole scripted flow
  - a visible client root span
  - proper client/server parent-child relationships for each app-server
  request

  Owen Lin · 2026-03-04 13:30:09 -08:00
  8dfd654196
• feat: load from plugins (#12864)

  Support loading plugins.
  
  Plugins can now be enabled via [plugins.<name>] in config.toml. They are
  loaded as first-class entities through PluginsManager, and their default
  skills/ and .mcp.json contributions are integrated into the existing
  skills and MCP flows.

  xl-openai · 2026-03-01 10:50:56 -08:00
  752402c4fe
• feat: add debug clear-memories command to hard-wipe memories state (#13085)

  #### what
  adds a `codex debug clear-memories` command to help with clearing all
  memories state from disk, sqlite db, and marking threads as
  `memory_mode=disabled` so they don't get resummarized when the
  `memories` feature is re-enabled.
  
  #### tests
  add tests

  sayan-oai · 2026-02-27 17:45:55 -08:00
  033ef9cb9d
• Add oauth_resource handling for MCP login flows (#12866)

  Addresses bug https://github.com/openai/codex/issues/12589
  
  Builds on community PR #12763.
  
  This adds `oauth_resource` support for MCP `streamable_http` servers and
  wires it through the relevant config and login paths. It fixes the bug
  where the configured OAuth resource was not reliably included in the
  authorization request, causing MCP login to omit the expected
  `resource` parameter.

  Eric Traut · 2026-02-26 20:10:12 -08:00
  cee009d117
• fix: sort codex features list alphabetically (#12944)

  ## Why
  
  `codex features list` currently prints features in declaration order
  from `codex_core::features::FEATURES`. That makes the output harder to
  scan when looking for a specific flag, and the order can change for
  reasons unrelated to the CLI.
  
  ## What changed
  
  - Sort the `codex features list` rows by feature key before printing
  them in `codex-rs/cli/src/main.rs`.
  - Add an integration test in `codex-rs/cli/tests/features.rs` that runs
  `codex features list` and asserts the feature-name column is
  alphabetized.
  
  ## Verification
  
  - Added `features_list_is_sorted_alphabetically_by_feature_name`.
  - Ran `cargo test -p codex-cli`.

  Michael Bolin · 2026-02-26 14:44:39 -08:00
  fd719d3828
• Clarify device auth login hint (#12813)

  Mention device auth for remote login

  xl-openai · 2026-02-25 18:15:27 -08:00
  2c1f225427
• feat(network-proxy): add embedded OTEL policy audit logging (#12046)

  **PR Summary**
  
  This PR adds embedded-only OTEL policy audit logging for
  `codex-network-proxy` and threads audit metadata from `codex-core` into
  managed proxy startup.
  
  ### What changed
  - Added structured audit event emission in `network_policy.rs` with
  target `codex_otel.network_proxy`.
  - Emitted:
  - `codex.network_proxy.domain_policy_decision` once per domain-policy
  evaluation.
    - `codex.network_proxy.block_decision` for non-domain denies.
  - Added required policy/network fields, RFC3339 UTC millisecond
  `event.timestamp`, and fallback defaults (`http.request.method="none"`,
  `client.address="unknown"`).
  - Added non-domain deny audit emission in HTTP/SOCKS handlers for
  mode-guard and proxy-state denies, including unix-socket deny paths.
  - Added `REASON_UNIX_SOCKET_UNSUPPORTED` and used it for unsupported
  unix-socket auditing.
  - Added `NetworkProxyAuditMetadata` to runtime/state, re-exported from
  `lib.rs` and `state.rs`.
  - Added `start_proxy_with_audit_metadata(...)` in core config, with
  `start_proxy()` delegating to default metadata.
  - Wired metadata construction in `codex.rs` from session/auth context,
  including originator sanitization for OTEL-safe tagging.
  - Updated `network-proxy/README.md` with embedded-mode audit schema and
  behavior notes.
  - Refactored HTTP block-audit emission to a small local helper to reduce
  duplication.
  - Preserved existing unix-socket proxy-disabled host/path behavior for
  responses and blocked history while using an audit-only endpoint
  override (`server.address="unix-socket"`, `server.port=0`).
  
  ### Explicit exclusions
  - No standalone proxy OTEL startup work.
  - No `main.rs` binary wiring.
  - No `standalone_otel.rs`.
  - No standalone docs/tests.
  
  ### Tests
  - Extended `network_policy.rs` tests for event mapping, metadata
  propagation, fallbacks, timestamp format, and target prefix.
  - Extended HTTP tests to assert unix-socket deny block audit events.
  - Extended SOCKS tests to cover deny emission from handler deny
  branches.
  - Added/updated core tests to verify audit metadata threading into
  managed proxy state.
  
  ### Validation run
  - `just fmt`
  - `cargo test -p codex-network-proxy` ✅
  - `cargo test -p codex-core` ran with one unrelated flaky timeout
  (`shell_snapshot::tests::snapshot_shell_does_not_inherit_stdin`), and
  the test passed when rerun directly ✅
  
  ---------
  
  Co-authored-by: viyatb-oai <viyatb@openai.com>

  mcgrew-oai · 2026-02-25 11:46:37 -05:00
  9a393c9b6f
• feat: pass helper executable paths via Arg0DispatchPaths (#12719)

  ## Why
  
  `codex-rs/core/src/tools/runtimes/shell/unix_escalation.rs` previously
  located `codex-execve-wrapper` by scanning `PATH` and sibling
  directories. That lookup is brittle and can select the wrong binary when
  the runtime environment differs from startup assumptions.
  
  We already pass `codex-linux-sandbox` from `codex-arg0`;
  `codex-execve-wrapper` should use the same startup-driven path plumbing.
  
  ## What changed
  
  - Introduced `Arg0DispatchPaths` in `codex-arg0` to carry both helper
  executable paths:
    - `codex_linux_sandbox_exe`
    - `main_execve_wrapper_exe`
  - Updated `arg0_dispatch_or_else()` to pass `Arg0DispatchPaths` to
  top-level binaries and preserve helper paths created in
  `prepend_path_entry_for_codex_aliases()`.
  - Threaded `Arg0DispatchPaths` through entrypoints in `cli`, `exec`,
  `tui`, `app-server`, and `mcp-server`.
  - Added `main_execve_wrapper_exe` to core configuration plumbing
  (`Config`, `ConfigOverrides`, and `SessionServices`).
  - Updated zsh-fork shell escalation to consume the configured
  `main_execve_wrapper_exe` and removed path-sniffing fallback logic.
  - Updated app-server config reload paths so reloaded configs keep the
  same startup-provided helper executable paths.
  
  ## References
  
  - [`Arg0DispatchPaths`
  definition](https://github.com/openai/codex/blob/e355b43d5c2a771f045296a6deae10d7c9c36ec6/codex-rs/arg0/src/lib.rs#L20-L24)
  - [`arg0_dispatch_or_else()` forwarding both
  paths](https://github.com/openai/codex/blob/e355b43d5c2a771f045296a6deae10d7c9c36ec6/codex-rs/arg0/src/lib.rs#L145-L176)
  - [zsh-fork escalation using configured wrapper
  path](https://github.com/openai/codex/blob/e355b43d5c2a771f045296a6deae10d7c9c36ec6/codex-rs/core/src/tools/runtimes/shell/unix_escalation.rs#L109-L150)
  
  ## Testing
  
  - `cargo check -p codex-arg0 -p codex-core -p codex-exec -p codex-tui -p
  codex-mcp-server -p codex-app-server`
  - `cargo test -p codex-arg0`
  - `cargo test -p codex-core tools::runtimes::shell::unix_escalation:: --
  --nocapture`

  Michael Bolin · 2026-02-24 17:44:38 -08:00
  e88f74d140
• feat: run zsh fork shell tool via shell-escalation (#12649)

  ## Why
  
  This PR switches the `shell_command` zsh-fork path over to
  `codex-shell-escalation` so the new shell tool can use the shared
  exec-wrapper/escalation protocol instead of the `zsh_exec_bridge`
  implementation that was introduced in
  https://github.com/openai/codex/pull/12052. `zsh_exec_bridge` relied on
  UNIX domain sockets, which is not as tamper-proof as the FD-based
  approach in `codex-shell-escalation`.
  
  ## What Changed
  
  - Added a Unix zsh-fork runtime adapter in `core`
  (`core/src/tools/runtimes/shell/unix_escalation.rs`) that:
  - runs zsh-fork commands through
  `codex_shell_escalation::run_escalate_server`
    - bridges exec-policy / approval decisions into `ShellActionProvider`
  - executes escalated commands via a `ShellCommandExecutor` that calls
  `process_exec_tool_call`
  - Updated `ShellRuntime` / `ShellCommandHandler` / tool spec wiring to
  select a `shell_command` backend (`classic` vs `zsh-fork`) while leaving
  the generic `shell` tool path unchanged.
  - Removed the `zsh_exec_bridge`-based session service and deleted
  `core/src/zsh_exec_bridge/mod.rs`.
  - Moved exec-wrapper entrypoint dispatch to `arg0` by handling the
  `codex-execve-wrapper` arg0 alias there, and removed the old
  `codex_core::maybe_run_zsh_exec_wrapper_mode()` hooks from `cli` and
  `app-server` mains.
  - Added the needed `codex-shell-escalation` dependencies for `core` and
  `arg0`.
  
  ## Tests
  
  - `cargo test -p codex-core
  shell_zsh_fork_prefers_shell_command_over_unified_exec`
  - `cargo test -p codex-app-server turn_start_shell_zsh_fork --
  --nocapture`
  - verifies zsh-fork command execution and approval flows through the new
  backend
  - includes subcommand approve/decline coverage using the shared zsh
  DotSlash fixture in `app-server/tests/suite/zsh`
  - To test manually, I added the following to `~/.codex/config.toml`:
  
  ```toml
  zsh_path = "/Users/mbolin/code/codex3/codex-rs/app-server/tests/suite/zsh"
  
  [features]
  shell_zsh_fork = true
  ```
  
  Then I ran `just c` to run the dev build of Codex with these changes and
  sent it the message:
  
  ```
  run `echo $0`
  ```
  
  And it replied with:
  
  ```
    echo $0 printed:
  
    /Users/mbolin/code/codex3/codex-rs/app-server/tests/suite/zsh
  
    In this tool context, $0 reflects the script path used to invoke the shell, not just zsh.
  ```
  
  so the tool appears to be wired up correctly.
  
  ## Notes
  
  - The zsh subcommand-decline integration test now uses `rm` under a
  `WorkspaceWrite` sandbox. The previous `/usr/bin/true` scenario is
  auto-allowed by the new `shell-escalation` policy path, which no longer
  produces subcommand approval prompts.

  Michael Bolin · 2026-02-24 10:31:08 -08:00
  3ca0e7673b
• feat: land sqlite (#12141)
  jif-oai · 2026-02-23 16:12:23 +00:00
  eace7c6610
• Allow exec resume to parse output-last-message flag after command (#12541)

  Summary
  - mark `output-last-message` as a global exec flag so it can follow
  subcommands like `resume`
  - add regression tests in both `cli` and `exec` crates verifying the
  flag order works when invoking `resume`
  
  Fixes #12538

  Eric Traut · 2026-02-23 07:55:37 -08:00
  862a5b3eb3
• test: vendor zsh fork via DotSlash and stabilize zsh-fork tests (#12518)

  ## Why
  
  The zsh integration tests were still brittle in two ways:
  
  - they relied on `CODEX_TEST_ZSH_PATH` / environment-specific setup, so
  they often did not exercise the patched zsh fork that `shell-tool-mcp`
  ships
  - once the tests consistently used the vendored zsh fork, they exposed
  real Linux-specific zsh-fork issues in CI
  
  In particular, the Linux failures were not just test noise:
  
  - the zsh-fork launch path was dropping `ExecRequest.arg0`, so Linux
  `codex-linux-sandbox` arg0 dispatch did not run and zsh wrapper-mode
  could receive malformed arguments
  - the
  `turn_start_shell_zsh_fork_subcommand_decline_marks_parent_declined_v2`
  test uses the zsh exec bridge (which talks to the parent over a Unix
  socket), but Linux restricted sandbox seccomp denies `connect(2)`,
  causing timeouts on `ubuntu-24.04` x86/arm
  
  This PR makes the zsh tests consistently run against the intended
  vendored zsh fork and fixes/hardens the zsh-fork path so the Linux CI
  signal is meaningful.
  
  ## What Changed
  
  - Added a single shared test-only DotSlash file for the patched zsh fork
  at `codex-rs/exec-server/tests/suite/zsh` (analogous to the existing
  `bash` test resource).
  - Updated both app-server and exec-server zsh tests to use that shared
  DotSlash zsh (no duplicate zsh DotSlash file, no `CODEX_TEST_ZSH_PATH`
  dependency).
  - Updated the app-server zsh-fork test helper to resolve the shared
  DotSlash zsh and avoid silently falling back to host zsh.
  - Kept the app-server zsh-fork tests configured via `config.toml`, using
  a test wrapper path where needed to force `zsh -df` (and rewrite `-lc`
  to `-c`) for the subcommand-decline test.
  - Hardened the app-server subcommand-decline zsh-fork test for CI
  variability:
    - tolerate an extra `/responses` POST with a no-op mock response
  - tolerate non-target approval ordering while remaining strict on the
  two `/usr/bin/true` approvals and decline behavior
  - use `DangerFullAccess` on Linux for this one test because it validates
  zsh approval flow, not Linux sandbox socket restrictions
  - Fixed zsh-fork process launching on Linux by preserving `req.arg0` in
  `ZshExecBridge::execute_shell_request(...)` so `codex-linux-sandbox`
  arg0 dispatch continues to work.
  - Moved `maybe_run_zsh_exec_wrapper_mode()` under
  `arg0_dispatch_or_else(...)` in `app-server` and `cli` so wrapper-mode
  handling coexists correctly with arg0-dispatched helper modes.
  - Consolidated duplicated `dotslash -- fetch` resolution logic into
  shared test support (`core/tests/common/lib.rs`).
  - Updated `codex-rs/exec-server/tests/suite/accept_elicitation.rs` to
  use DotSlash zsh and hardened the zsh elicitation test for Bazel/zsh
  differences by:
    - resolving an absolute `git` path
    - running `git init --quiet .`
  - asserting success / `.git` creation instead of relying on banner text
  
  ## Verification
  
  - `cargo test -p codex-app-server turn_start_zsh_fork -- --nocapture`
  - `cargo test -p codex-exec-server accept_elicitation -- --nocapture`
  - `bazel test //codex-rs/exec-server:exec-server-all-test
  --test_output=streamed --test_arg=--nocapture
  --test_arg=accept_elicitation_for_prompt_rule_with_zsh`
  - CI (`rust-ci`) on the final cleaned commit: `Tests — ubuntu-24.04 -
  x86_64-unknown-linux-gnu` and `Tests — ubuntu-24.04-arm -
  aarch64-unknown-linux-gnu` passed in [run
  22291424358](https://github.com/openai/codex/actions/runs/22291424358)

  Michael Bolin · 2026-02-22 19:39:56 -08:00
  e8949f4507
• chore: remove codex-core public protocol/shell re-exports (#12432)

  ## Why
  
  `codex-rs/core/src/lib.rs` re-exported a broad set of types and modules
  from `codex-protocol` and `codex-shell-command`. That made it easy for
  workspace crates to import those APIs through `codex-core`, which in
  turn hides dependency edges and makes it harder to reduce compile-time
  coupling over time.
  
  This change removes those public re-exports so call sites must import
  from the source crates directly. Even when a crate still depends on
  `codex-core` today, this makes dependency boundaries explicit and
  unblocks future work to drop `codex-core` dependencies where possible.
  
  ## What Changed
  
  - Removed public re-exports from `codex-rs/core/src/lib.rs` for:
  - `codex_protocol::protocol` and related protocol/model types (including
  `InitialHistory`)
    - `codex_protocol::config_types` (`protocol_config_types`)
  - `codex_shell_command::{bash, is_dangerous_command, is_safe_command,
  parse_command, powershell}`
  - Migrated workspace Rust call sites to import directly from:
    - `codex_protocol::protocol`
    - `codex_protocol::config_types`
    - `codex_protocol::models`
    - `codex_shell_command`
  - Added explicit `Cargo.toml` dependencies (`codex-protocol` /
  `codex-shell-command`) in crates that now import those crates directly.
  - Kept `codex-core` internal modules compiling by using `pub(crate)`
  aliases in `core/src/lib.rs` (internal-only, not part of the public
  API).
  - Updated the two utility crates that can already drop a `codex-core`
  dependency edge entirely:
    - `codex-utils-approval-presets`
    - `codex-utils-cli`
  
  ## Verification
  
  - `cargo test -p codex-utils-approval-presets`
  - `cargo test -p codex-utils-cli`
  - `cargo check --workspace --all-targets`
  - `just clippy`

  Michael Bolin · 2026-02-20 23:45:35 -08:00
  1af2a37ada
• chore: move config diagnostics out of codex-core (#12427)

  ## Why
  
  Compiling `codex-rs/core` is a bottleneck for local iteration, so this
  change continues the ongoing extraction of config-related functionality
  out of `codex-core` and into `codex-config`.
  
  The goal is not just to move code, but to reduce `codex-core` ownership
  and indirection so more code depends on `codex-config` directly.
  
  ## What Changed
  
  - Moved config diagnostics logic from
  `core/src/config_loader/diagnostics.rs` into
  `config/src/diagnostics.rs`.
  - Updated `codex-core` to use `codex-config` diagnostics types/functions
  directly where possible.
  - Removed the `core/src/config_loader/diagnostics.rs` shim module
  entirely; the remaining `ConfigToml`-specific calls are in
  `core/src/config_loader/mod.rs`.
  - Moved `CONFIG_TOML_FILE` into `codex-config` and updated existing
  references to use `codex_config::CONFIG_TOML_FILE` directly.
  - Added a direct `codex-config` dependency to `codex-cli` for its
  `CONFIG_TOML_FILE` use.

  Michael Bolin · 2026-02-20 23:19:29 -08:00
  1a220ad77d
• Add configurable MCP OAuth callback URL for MCP login (#11382)

  ## Summary
  
  Implements a configurable MCP OAuth callback URL override for `codex mcp
  login` and app-server OAuth login flows, including support for non-local
  callback endpoints (for example, devbox ingress URLs).
  
  ## What changed
  
  - Added new config key: `mcp_oauth_callback_url` in
  `~/.codex/config.toml`.
  - OAuth authorization now uses `mcp_oauth_callback_url` as
  `redirect_uri` when set.
  - Callback handling validates the callback path against the configured
  redirect URI path.
  - Listener bind behavior is now host-aware:
  - local callback URL hosts (`localhost`, `127.0.0.1`, `::1`) bind to
  `127.0.0.1`
    - non-local callback URL hosts bind to `0.0.0.0`
  - `mcp_oauth_callback_port` remains supported and is used for the
  listener port.
  - Wired through:
    - CLI MCP login flow
    - App-server MCP OAuth login flow
    - Skill dependency OAuth login flow
  - Updated config schema and config tests.
  
  ## Why
  
  Some environments need OAuth callbacks to land on a specific reachable
  URL (for example ingress in remote devboxes), not loopback. This change
  allows that while preserving local defaults for existing users.
  
  ## Backward compatibility
  
  - No behavior change when `mcp_oauth_callback_url` is unset.
  - Existing `mcp_oauth_callback_port` behavior remains intact.
  - Local callback flows continue binding to loopback by default.
  
  ## Testing
  
  - `cargo test -p codex-rmcp-client callback -- --nocapture`
  - `cargo test -p codex-core --lib mcp_oauth_callback -- --nocapture`
  - `cargo check -p codex-cli -p codex-app-server -p codex-rmcp-client`
  
  ## Example config
  
  ```toml
  mcp_oauth_callback_port = 5555
  mcp_oauth_callback_url = "https://<devbox>-<namespace>.gateway.<cluster>.internal.api.openai.org/callback"

  dkumar-oai · 2026-02-19 13:32:10 -08:00
  1070a0a712
• feat(core): zsh exec bridge (#12052)

  zsh fork PR stack:
  - https://github.com/openai/codex/pull/12051 
  - https://github.com/openai/codex/pull/12052 👈 
  
  ### Summary
  This PR introduces a feature-gated native shell runtime path that routes
  shell execution through a patched zsh exec bridge, removing MCP-specific
  behavior from the shell hot path while preserving existing
  CommandExecution lifecycle semantics.
  
  When shell_zsh_fork is enabled, shell commands run via patched zsh with
  per-`execve` interception through EXEC_WRAPPER. Core receives wrapper
  IPC requests over a Unix socket, applies existing approval policy, and
  returns allow/deny before the subcommand executes.
  
  ### What’s included
  **1) New zsh exec bridge runtime in core**
  - Wrapper-mode entrypoint (maybe_run_zsh_exec_wrapper_mode) for
  EXEC_WRAPPER invocations.
  - Per-execution Unix-socket IPC handling for wrapper requests/responses.
  - Approval callback integration using existing core approval
  orchestration.
  - Streaming stdout/stderr deltas to existing command output event
  pipeline.
  - Error handling for malformed IPC, denial/abort, and execution
  failures.
  
  **2) Session lifecycle integration**
  SessionServices now owns a `ZshExecBridge`.
  Session startup initializes bridge state; shutdown tears it down
  cleanly.
  
  **3) Shell runtime routing (feature-gated)**
  When `shell_zsh_fork` is enabled:
  - Build execution env/spec as usual.
  - Add wrapper socket env wiring.
  - Execute via `zsh_exec_bridge.execute_shell_request(...)` instead of
  the regular shell path.
  - Non-zsh-fork behavior remains unchanged.
  
  **4) Config + feature wiring**
  - Added `Feature::ShellZshFork` (under development).
  - Added config support for `zsh_path` (optional absolute path to patched
  zsh):
  - `Config`, `ConfigToml`, `ConfigProfile`, overrides, and schema.
  - Session startup validates that `zsh_path` exists/usable when zsh-fork
  is enabled.
  - Added startup test for missing `zsh_path` failure mode.
  
  **5) Seatbelt/sandbox updates for wrapper IPC**
  - Extended seatbelt policy generation to optionally allow outbound
  connection to explicitly permitted Unix sockets.
  - Wired sandboxing path to pass wrapper socket path through to seatbelt
  policy generation.
  - Added/updated seatbelt tests for explicit socket allow rule and
  argument emission.
  
  **6) Runtime entrypoint hooks**
  - This allows the same binary to act as the zsh wrapper subprocess when
  invoked via `EXEC_WRAPPER`.
  
  **7) Tool selection behavior**
  - ToolsConfig now prefers ShellCommand type when shell_zsh_fork is
  enabled.
  - Added test coverage for precedence with unified-exec enabled.

  Owen Lin · 2026-02-17 20:19:53 -08:00
  edacbf7b6e
• feat(core): add structured network approval plumbing and policy decision model (#11672)

  ### Description
  #### Summary
  Introduces the core plumbing required for structured network approvals
  
  #### What changed
  - Added structured network policy decision modeling in core.
  - Added approval payload/context types needed for network approval
  semantics.
  - Wired shell/unified-exec runtime plumbing to consume structured
  decisions.
  - Updated related core error/event surfaces for structured handling.
  - Updated protocol plumbing used by core approval flow.
  - Included small CLI debug sandbox compatibility updates needed by this
  layer.
  
  #### Why
  establishes the minimal backend foundation for network approvals without
  yet changing high-level orchestration or TUI behavior.
  
  #### Notes
  - Behavior remains constrained by existing requirements/config gating.
  - Follow-up PRs in the stack handle orchestration, UX, and app-server
  integration.
  
  ---------
  
  Co-authored-by: Codex <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com>

  viyatb-oai · 2026-02-14 04:18:12 +00:00
  b527ee2890
• Fixed help text for mcp and mcp-server CLI commands (#11813)

  Also removed the "[experimental]" tag since these have been stable for
  many months
  
  This addresses #11812

  Eric Traut · 2026-02-13 20:16:22 -08:00
  854e91e422
• feat: introduce Permissions (#11633)

  ## Why
  We currently carry multiple permission-related concepts directly on
  `Config` for shell/unified-exec behavior (`approval_policy`,
  `sandbox_policy`, `network`, `shell_environment_policy`,
  `windows_sandbox_mode`).
  
  Consolidating these into one in-memory struct makes permission handling
  easier to reason about and sets up the next step: supporting named
  permission profiles (`[permissions.PROFILE_NAME]`) without changing
  behavior now.
  
  This change is mostly mechanical: it updates existing callsites to go
  through `config.permissions`, but it does not yet refactor those
  callsites to take a single `Permissions` value in places where multiple
  permission fields are still threaded separately.
  
  This PR intentionally **does not** change the on-disk `config.toml`
  format yet and keeps compatibility with legacy config keys.
  
  ## What Changed
  - Introduced `Permissions` in `core/src/config/mod.rs`.
  - Added `Config::permissions` and moved effective runtime permission
  fields under it:
    - `approval_policy`
    - `sandbox_policy`
    - `network`
    - `shell_environment_policy`
    - `windows_sandbox_mode`
  - Updated config loading/building so these effective values are still
  derived from the same existing config inputs and constraints.
  - Updated Windows sandbox helpers/resolution to read/write via
  `permissions`.
  - Threaded the new field through all permission consumers across core
  runtime, app-server, CLI/exec, TUI, and sandbox summary code.
  - Updated affected tests to reference `config.permissions.*`.
  - Renamed the struct/field from
  `EffectivePermissions`/`effective_permissions` to
  `Permissions`/`permissions` and aligned variable naming accordingly.
  
  ## Verification
  - `just fix -p codex-core -p codex-tui -p codex-cli -p codex-app-server
  -p codex-exec -p codex-utils-sandbox-summary`
  - `cargo build -p codex-core -p codex-tui -p codex-cli -p
  codex-app-server -p codex-exec -p codex-utils-sandbox-summary`

  Michael Bolin · 2026-02-12 14:42:54 -08:00
  a4cc1a4a85
• Reapply "Add app-server transport layer with websocket support" (#11370)

  Reapply "Add app-server transport layer with websocket support" with
  additional fixes from https://github.com/openai/codex/pull/11313/changes
  to avoid deadlocking.
  
  This reverts commit 47356ff83c.
  
  ## Summary
  
  To avoid deadlocking when queues are full, we maintain separate tokio
  tasks dedicated to incoming vs outgoing event handling
  - split the app-server main loop into two tasks in
  `run_main_with_transport`
     - inbound handling (`transport_event_rx`)
     - outbound handling (`outgoing_rx` + `thread_created_rx`)
  - separate incoming and outgoing websocket tasks
  
  ## Validation
  
  Integration tests, testing thoroughly e2e in codex app w/ >10 concurrent
  requests
  
  <img width="1365" height="979" alt="Screenshot 2026-02-10 at 2 54 22 PM"
  src="https://github.com/user-attachments/assets/47ca2c13-f322-4e5c-bedd-25859cbdc45f"
  />
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  Max Johnson · 2026-02-11 18:13:39 +00:00
  7053aa5457
• feat: split codex-common into smaller utils crates (#11422)

  We are removing feature-gated shared crates from the `codex-rs`
  workspace. `codex-common` grouped several unrelated utilities behind
  `[features]`, which made dependency boundaries harder to reason about
  and worked against the ongoing effort to eliminate feature flags from
  workspace crates.
  
  Splitting these utilities into dedicated crates under `utils/` aligns
  this area with existing workspace structure and keeps each dependency
  explicit at the crate boundary.
  
  ## What changed
  
  - Removed `codex-rs/common` (`codex-common`) from workspace members and
  workspace dependencies.
  - Added six new utility crates under `codex-rs/utils/`:
    - `codex-utils-cli`
    - `codex-utils-elapsed`
    - `codex-utils-sandbox-summary`
    - `codex-utils-approval-presets`
    - `codex-utils-oss`
    - `codex-utils-fuzzy-match`
  - Migrated the corresponding modules out of `codex-common` into these
  crates (with tests), and added matching `BUILD.bazel` targets.
  - Updated direct consumers to use the new crates instead of
  `codex-common`:
    - `codex-rs/cli`
    - `codex-rs/tui`
    - `codex-rs/exec`
    - `codex-rs/app-server`
    - `codex-rs/mcp-server`
    - `codex-rs/chatgpt`
    - `codex-rs/cloud-tasks`
  - Updated workspace lockfile entries to reflect the new dependency graph
  and removal of `codex-common`.

  Michael Bolin · 2026-02-11 12:59:24 +00:00
  8b7f8af343
• Revert "Add app-server transport layer with websocket support (#10693)" (#11323)

  Suspected cause of deadlocking bug

  Max Johnson · 2026-02-10 17:37:49 +00:00
  47356ff83c
• feat: retain NetworkProxy, when appropriate (#11207)

  As of this PR, `SessionServices` retains a
  `Option<StartedNetworkProxy>`, if appropriate.
  
  Now the `network` field on `Config` is `Option<NetworkProxySpec>`
  instead of `Option<NetworkProxy>`.
  
  Over in `Session::new()`, we invoke `NetworkProxySpec::start_proxy()` to
  create the `StartedNetworkProxy`, which is a new struct that retains the
  `NetworkProxy` as well as the `NetworkProxyHandle`. (Note that `Drop` is
  implemented for `NetworkProxyHandle` to ensure the proxies are shutdown
  when it is dropped.)
  
  The `NetworkProxy` from the `StartedNetworkProxy` is threaded through to
  the appropriate places.
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/11207).
  * #11285
  * __->__ #11207

  Michael Bolin · 2026-02-10 02:09:23 -08:00
  44ebf4588f
• feat(sandbox): enforce proxy-aware network routing in sandbox (#11113)

  ## Summary
  - expand proxy env injection to cover common tool env vars
  (`HTTP_PROXY`/`HTTPS_PROXY`/`ALL_PROXY`/`NO_PROXY` families +
  tool-specific variants)
  - harden macOS Seatbelt network policy generation to route through
  inferred loopback proxy endpoints and fail closed when proxy env is
  malformed
  - thread proxy-aware Linux sandbox flags and add minimal bwrap netns
  isolation hook for restricted non-proxy runs
  - add/refresh tests for proxy env wiring, Seatbelt policy generation,
  and Linux sandbox argument wiring

  viyatb-oai · 2026-02-10 07:44:21 +00:00
  3391e5ea86
• Handle required MCP startup failures across components (#10902)

  Summary
  - add a `required` flag for MCP servers everywhere config/CLI data is
  touched so mandatory helpers can be round-tripped
  - have `codex exec` and `codex app-server` thread start/resume fail fast
  when required MCPs fail to initialize

  jif-oai · 2026-02-06 17:14:37 +01:00
  aab61934af
• Add app-server transport layer with websocket support (#10693)

  - Adds --listen <URL> to codex app-server with two listen modes:
        - stdio:// (default, existing behavior)
        - ws://IP:PORT (new websocket transport)
    - Refactors message routing to be connection-aware:
  - Tracks per-connection session state (initialize/experimental
  capability)
        - Routes responses/errors to the originating connection
  - Broadcasts server notifications/requests to initialized connections
  - Updates initialization semantics to be per connection (not
  process-global), and updates app-server docs accordingly.
  - Adds websocket accept/read/write handling (JSON-RPC per text frame,
  ping/pong handling, connection lifecycle events).
  
  Testing
  
  - Unit tests for transport URL parsing and targeted response/error
  routing.
    - New websocket integration test validating:
        - per-connection initialization requirements
        - no cross-connection response leakage
        - same request IDs on different connections route independently.

  Max Johnson · 2026-02-05 20:56:34 +00:00
  8473096efb
• fix(auth): isolate chatgptAuthTokens concept to auth manager and app-server (#10423)

  So that the rest of the codebase (like TUI) don't need to be concerned
  whether ChatGPT auth was handled by Codex itself or passed in via
  app-server's external auth mode.

  Owen Lin · 2026-02-05 10:46:06 -08:00
  3582b74d01
• feat(linux-sandbox): add bwrap support (#9938)

  ## Summary
  This PR introduces a gated Bubblewrap (bwrap) Linux sandbox path. The
  curent Linux sandbox path relies on in-process restrictions (including
  Landlock). Bubblewrap gives us a more uniform filesystem isolation
  model, especially explicit writable roots with the option to make some
  directories read-only and granular network controls.
  
  This is behind a feature flag so we can validate behavior safely before
  making it the default.
  
  - Added temporary rollout flag:
    - `features.use_linux_sandbox_bwrap`
  - Preserved existing default path when the flag is off.
  - In Bubblewrap mode:
  - Added internal retry without /proc when /proc mount is not permitted
  by the host/container.

  viyatb-oai · 2026-02-04 11:13:17 -08:00
  ae4de43ccc
• chore: add codex debug app-server tooling (#10367)

  codex debug app-server <user message> forwards the message through
  codex-app-server-test-client’s send_message_v2 library entry point,
  using std::env::current_exe() to resolve the codex binary.
  
  for how it looks like, see:
  
  ```
  celia@com-92114 codex-rs % cargo build -p codex-cli && target/debug/codex debug app-server --help                       
      Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.34s
  Tooling: helps debug the app server
  
  Usage: codex debug app-server [OPTIONS] <COMMAND>
  
  Commands:
    send-message-v2  
    help             Print this message or the help of the given subcommand(s)
  ````
  and
  ```
  celia@com-92114 codex-rs % cargo build -p codex-cli && target/debug/codex debug app-server send-message-v2 "hello world"
     Compiling codex-cli v0.0.0 (/Users/celia/code/codex/codex-rs/cli)
      Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.38s
  > {
  >   "method": "initialize",
  >   "id": "f8ba9f60-3a49-4ea9-81d6-4ab6853e3954",
  >   "params": {
  >     "clientInfo": {
  >       "name": "codex-toy-app-server",
  >       "title": "Codex Toy App Server",
  >       "version": "0.0.0"
  >     },
  >     "capabilities": {
  >       "experimentalApi": true
  >     }
  >   }
  > }
  < {
  <   "id": "f8ba9f60-3a49-4ea9-81d6-4ab6853e3954",
  <   "result": {
  <     "userAgent": "codex-toy-app-server/0.0.0 (Mac OS 26.2.0; arm64) vscode/2.4.27 (codex-toy-app-server; 0.0.0)"
  <   }
  < }
  < initialize response: InitializeResponse { user_agent: "codex-toy-app-server/0.0.0 (Mac OS 26.2.0; arm64) vscode/2.4.27 (codex-toy-app-server; 0.0.0)" }
  > {
  >   "method": "thread/start",
  >   "id": "203f1630-beee-4e60-b17b-9eff16b1638b",
  >   "params": {
  >     "model": null,
  >     "modelProvider": null,
  >     "cwd": null,
  >     "approvalPolicy": null,
  >     "sandbox": null,
  >     "config": null,
  >     "baseInstructions": null,
  >     "developerInstructions": null,
  >     "personality": null,
  >     "ephemeral": null,
  >     "dynamicTools": null,
  >     "mockExperimentalField": null,
  >     "experimentalRawEvents": false
  >   }
  > }
  ...
  ```

  Celia Chen · 2026-02-03 23:17:34 +00:00
  16647b188b
• Inject CODEX_THREAD_ID into the terminal environment (#10096)

  Inject CODEX_THREAD_ID (when applicable) into the terminal environment
  so that the agent (and skills) can refer to the current thread / session
  ID.
  
  Discussion:
  https://openai.slack.com/archives/C095U48JNL9/p1769542492067109

  Max Johnson · 2026-02-03 11:31:12 -08:00
  66b196a725
• Add codex app macOS launcher (#10418)

  - Add `codex app <path>` to launch the Codex Desktop app.
  - On macOS, auto-downloads the DMG if missing; non-macOS prints a link
  to chatgpt.com/codex.

  Ahmed Ibrahim · 2026-02-02 17:37:04 -08:00
  d02db8b43d
• feat: experimental flags (#10231)

  ## Problem being solved
  - We need a single, reliable way to mark app-server API surface as
  experimental so that:
    1. the runtime can reject experimental usage unless the client opts in
  2. generated TS/JSON schemas can exclude experimental methods/fields for
  stable clients.
  
  Right now that’s easy to drift or miss when done ad-hoc.
  
  ## How to declare experimental methods and fields
  - **Experimental method**: add `#[experimental("method/name")]` to the
  `ClientRequest` variant in `client_request_definitions!`.
  - **Experimental field**: on the params struct, derive `ExperimentalApi`
  and annotate the field with `#[experimental("method/name.field")]` + set
  `inspect_params: true` for the method variant so
  `ClientRequest::experimental_reason()` inspects params for experimental
  fields.
  
  ## How the macro solves it
  - The new derive macro lives in
  `codex-rs/codex-experimental-api-macros/src/lib.rs` and is used via
  `#[derive(ExperimentalApi)]` plus `#[experimental("reason")]`
  attributes.
  - **Structs**:
  - Generates `ExperimentalApi::experimental_reason(&self)` that checks
  only annotated fields.
    - The “presence” check is type-aware:
      - `Option<T>`: `is_some_and(...)` recursively checks inner.
      - `Vec`/`HashMap`/`BTreeMap`: must be non-empty.
      - `bool`: must be `true`.
      - Other types: considered present (returns `true`).
  - Registers each experimental field in an `inventory` with `(type_name,
  serialized field name, reason)` and exposes `EXPERIMENTAL_FIELDS` for
  that type. Field names are converted from `snake_case` to `camelCase`
  for schema/TS filtering.
  - **Enums**:
  - Generates an exhaustive `match` returning `Some(reason)` for annotated
  variants and `None` otherwise (no wildcard arm).
  - **Wiring**:
  - Runtime gating uses `ExperimentalApi::experimental_reason()` in
  `codex-rs/app-server/src/message_processor.rs` to reject requests unless
  `InitializeParams.capabilities.experimental_api == true`.
  - Schema/TS export filters use the inventory list and
  `EXPERIMENTAL_CLIENT_METHODS` from `client_request_definitions!` to
  strip experimental methods/fields when `experimental_api` is false.

  jif-oai · 2026-02-02 11:06:50 +00:00
  3cc9122ee2
• chore: rename ChatGpt -> Chatgpt in type names (#10244)

  When using ChatGPT in names of types, we should be consistent, so this
  renames some types with `ChatGpt` in the name to `Chatgpt`. From
  https://rust-lang.github.io/api-guidelines/naming.html:
  
  > In `UpperCamelCase`, acronyms and contractions of compound words count
  as one word: use `Uuid` rather than `UUID`, `Usize` rather than `USize`
  or `Stdin` rather than `StdIn`. In `snake_case`, acronyms and
  contractions are lower-cased: `is_xid_start`.
  
  This PR updates existing uses of `ChatGpt` and changes them to
  `Chatgpt`. Though in all cases where it could affect the wire format, I
  visually inspected that we don't change anything there. That said, this
  _will_ change the codegen because it will affect the spelling of type
  names.
  
  For example, this renames `AuthMode::ChatGPT` to `AuthMode::Chatgpt` in
  `app-server-protocol`, but the wire format is still `"chatgpt"`.
  
  This PR also updates a number of types in `codex-rs/core/src/auth.rs`.

  Michael Bolin · 2026-01-30 11:18:39 -08:00
  e6d913af2d