247 Commits

• Rename tui_app_server to tui (#16104)

  This is a follow-up to https://github.com/openai/codex/pull/15922. That
  previous PR deleted the old `tui` directory and left the new
  `tui_app_server` directory in place. This PR renames `tui_app_server` to
  `tui` and fixes up all references.

  Eric Traut · 2026-03-28 11:23:07 -06:00
  61429a6c10
• chore: clean up argument-comment lint and roll out all-target CI on macOS (#16054)

  ## Why
  
  `argument-comment-lint` was green in CI even though the repo still had
  many uncommented literal arguments. The main gap was target coverage:
  the repo wrapper did not force Cargo to inspect test-only call sites, so
  examples like the `latest_session_lookup_params(true, ...)` tests in
  `codex-rs/tui_app_server/src/lib.rs` never entered the blocking CI path.
  
  This change cleans up the existing backlog, makes the default repo lint
  path cover all Cargo targets, and starts rolling that stricter CI
  enforcement out on the platform where it is currently validated.
  
  ## What changed
  
  - mechanically fixed existing `argument-comment-lint` violations across
  the `codex-rs` workspace, including tests, examples, and benches
  - updated `tools/argument-comment-lint/run-prebuilt-linter.sh` and
  `tools/argument-comment-lint/run.sh` so non-`--fix` runs default to
  `--all-targets` unless the caller explicitly narrows the target set
  - fixed both wrappers so forwarded cargo arguments after `--` are
  preserved with a single separator
  - documented the new default behavior in
  `tools/argument-comment-lint/README.md`
  - updated `rust-ci` so the macOS lint lane keeps the plain wrapper
  invocation and therefore enforces `--all-targets`, while Linux and
  Windows temporarily pass `-- --lib --bins`
  
  That temporary CI split keeps the stricter all-targets check where it is
  already cleaned up, while leaving room to finish the remaining Linux-
  and Windows-specific target-gated cleanup before enabling
  `--all-targets` on those runners. The Linux and Windows failures on the
  intermediate revision were caused by the wrapper forwarding bug, not by
  additional lint findings in those lanes.
  
  ## Validation
  
  - `bash -n tools/argument-comment-lint/run.sh`
  - `bash -n tools/argument-comment-lint/run-prebuilt-linter.sh`
  - shell-level wrapper forwarding check for `-- --lib --bins`
  - shell-level wrapper forwarding check for `-- --tests`
  - `just argument-comment-lint`
  - `cargo test` in `tools/argument-comment-lint`
  - `cargo test -p codex-terminal-detection`
  
  ## Follow-up
  
  - Clean up remaining Linux-only target-gated callsites, then switch the
  Linux lint lane back to the plain wrapper invocation.
  - Clean up remaining Windows-only target-gated callsites, then switch
  the Windows lint lane back to the plain wrapper invocation.

  Michael Bolin · 2026-03-27 19:00:44 -07:00
  61dfe0b86c
• Remove the legacy TUI split (#15922)

  This is the part 1 of 2 PRs that will delete the `tui` /
  `tui_app_server` split. This part simply deletes the existing `tui`
  directory and marks the `tui_app_server` feature flag as removed. I left
  the `tui_app_server` feature flag in place for now so its presence
  doesn't result in an error. It is simply ignored.
  
  Part 2 will rename the `tui_app_server` directory `tui`. I did this as
  two parts to reduce visible code churn.

  Eric Traut · 2026-03-27 22:56:44 +00:00
  d65deec617
• feat(windows-sandbox): add network proxy support (#12220)

  ## Summary
  
  This PR makes Windows sandbox proxying enforceable by routing proxy-only
  runs through the existing `offline` sandbox user and reserving direct
  network access for the existing `online` sandbox user.
  
  In brief:
  
  - if a Windows sandbox run should be proxy-enforced, we run it as the
  `offline` user
  - the `offline` user gets firewall rules that block direct outbound
  traffic and only permit the configured localhost proxy path
  - if a Windows sandbox run should have true direct network access, we
  run it as the `online` user
  - no new sandbox identity is introduced
  
  This brings Windows in line with the intended model: proxy use is not
  just env-based, it is backed by OS-level egress controls. Windows
  already has two sandbox identities:
  
  - `offline`: intended to have no direct network egress
  - `online`: intended to have full network access
  
  This PR makes proxy-enforced runs use that model directly.
  
  ### Proxy-enforced runs
  
  When proxy enforcement is active:
  
  - the run is assigned to the `offline` identity
  - setup extracts the loopback proxy ports from the sandbox env
  - Windows setup programs firewall rules for the `offline` user that:
    - block all non-loopback outbound traffic
    - block loopback UDP
    - block loopback TCP except for the configured proxy ports
  - optionally allow broader localhost access when `allow_local_binding=1`
  
  So the sandboxed process can only talk to the local proxy. It cannot
  open direct outbound sockets or do local UDP-based DNS on its own.The
  proxy then performs the real outbound network access outside that
  restricted sandbox identity.
  
  ### Direct-network runs
  
  When proxy enforcement is not active and full network access is allowed:
  
  - the run is assigned to the `online` identity
  - no proxy-only firewall restrictions are applied
  - the process gets normal direct network access
  
  ### Unelevated vs elevated
  
  The restricted-token / unelevated path cannot enforce per-identity
  firewall policy by itself.
  
  So for Windows proxy-enforced runs, we transparently use the logon-user
  sandbox path under the hood, even if the caller started from the
  unelevated mode. That keeps enforcement real instead of best-effort.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-03-26 17:27:38 -07:00
  81fa04783a
• permissions: remove macOS seatbelt extension profiles (#15918)

  ## Why
  
  `PermissionProfile` should only describe the per-command permissions we
  still want to grant dynamically. Keeping
  `MacOsSeatbeltProfileExtensions` in that surface forced extra macOS-only
  approval, protocol, schema, and TUI branches for a capability we no
  longer want to expose.
  
  ## What changed
  
  - Removed the macOS-specific permission-profile types from
  `codex-protocol`, the app-server v2 API, and the generated
  schema/TypeScript artifacts.
  - Deleted the core and sandboxing plumbing that threaded
  `MacOsSeatbeltProfileExtensions` through execution requests and seatbelt
  construction.
  - Simplified macOS seatbelt generation so it always includes the fixed
  read-only preferences allowlist instead of carrying a configurable
  profile extension.
  - Removed the macOS additional-permissions UI/docs/test coverage and
  deleted the obsolete macOS permission modules.
  - Tightened `request_permissions` intersection handling so explicitly
  empty requested read lists are preserved only when that field was
  actually granted, avoiding zero-grant responses being stored as active
  permissions.

  Michael Bolin · 2026-03-26 17:12:45 -07:00
  e6e2999209
• Wire remote app-server auth through the client (#14853)

  For app-server websocket auth, support the two server-side mechanisms
  from
  PR #14847:
  
  - `--ws-auth capability-token --ws-token-file /abs/path`
  - `--ws-auth signed-bearer-token --ws-shared-secret-file /abs/path`
    with optional `--ws-issuer`, `--ws-audience`, and
    `--ws-max-clock-skew-seconds`
  
  On the client side, add interactive remote support via:
  
  - `--remote ws://host:port` or `--remote wss://host:port`
  - `--remote-auth-token-env <ENV_VAR>`
  
  Codex reads the bearer token from the named environment variable and
  sends it
  as `Authorization: Bearer <token>` during the websocket handshake.
  Remote auth
  tokens are only allowed for `wss://` URLs or loopback `ws://` URLs.
  
  Testing:
  - tested both auth methods manually to confirm connection success and
  rejection for both auth types

  Eric Traut · 2026-03-25 22:17:03 -06:00
  1ff39b6fa8
• [mcp] Improve custom MCP elicitation (#15800)

  - [x] Support don't ask again for custom MCP tool calls.
  - [x] Don't run arc in yolo mode.
  - [x] Run arc for custom MCP tools in always allow mode.

  Matthew Zeng · 2026-03-26 01:02:37 +00:00
  78799c1bcf
• feat: add websocket auth for app-server (#14847)

  ## Summary
  This change adds websocket authentication at the app-server transport
  boundary and enforces it before JSON-RPC `initialize`, so authenticated
  deployments reject unauthenticated clients during the websocket
  handshake rather than after a connection has already been admitted.
  
  During rollout, websocket auth is opt-in for non-loopback listeners so
  we do not break existing remote clients. If `--ws-auth ...` is
  configured, the server enforces auth during websocket upgrade. If auth
  is not configured, non-loopback listeners still start, but app-server
  logs a warning and the startup banner calls out that auth should be
  configured before real remote use.
  
  The server supports two auth modes: a file-backed capability token, and
  a standard HMAC-signed JWT/JWS bearer token verified with the
  `jsonwebtoken` crate, with optional issuer, audience, and clock-skew
  validation. Capability tokens are normalized, hashed, and compared in
  constant time. Short shared secrets for signed bearer tokens are
  rejected at startup. Requests carrying an `Origin` header are rejected
  with `403` by transport middleware, and authenticated clients present
  credentials as `Authorization: Bearer <token>` during websocket upgrade.
  
  ## Validation
  - `cargo test -p codex-app-server transport::auth`
  - `cargo test -p codex-cli app_server_`
  - `cargo clippy -p codex-app-server --all-targets -- -D warnings`
  - `just bazel-lock-check`
  
  Note: in the broad `cargo test -p codex-app-server
  connection_handling_websocket` run, the touched websocket auth cases
  passed, but unrelated Unix shutdown tests failed with a timeout in this
  environment.
  
  ---------
  
  Co-authored-by: Eric Traut <etraut@openai.com>

  viyatb-oai · 2026-03-25 12:35:57 -07:00
  6124564297
• Add non-interactive resume filter option (#15339)

  ## Summary
  - add `codex resume --include-non-interactive` to include
  non-interactive sessions in the picker and `--last`
  - keep current-provider and cwd filtering behavior unchanged
  - replace the picker API boolean with a `SessionSourceFilter` enum to
  avoid a boolean trap
  
  ## Tests
  - `cargo test -p codex-cli`
  - `cargo test -p codex-tui`
  - `just fmt`
  - `just fix -p codex-cli`
  - `just fix -p codex-tui`

  Jeremy Rose · 2026-03-25 11:05:07 -07:00
  6b10e186c4
• Use AbsolutePathBuf for cwd state (#15710)

  Migrate `cwd` and related session/config state to `AbsolutePathBuf` so
  downstream consumers consistently see absolute working directories.
  
  Add test-only `.abs()` helpers for `Path`, `PathBuf`, and `TempDir`, and
  update branch-local tests to use them instead of
  `AbsolutePathBuf::try_from(...)`.
  
  For the remaining TUI/app-server snapshot coverage that renders absolute
  cwd values, keep the snapshots unchanged and skip the Windows-only cases
  where the platform-specific absolute path layout differs.

  pakrym-oai · 2026-03-25 16:02:22 +00:00
  504aeb0e09
• Move macOS sandbox builders into codex-sandboxing (#15593)

  ## Summary
  - move macOS permission merging/intersection logic and tests from
  `codex-core` into `codex-sandboxing`
  - move seatbelt policy builders, permissions logic, SBPL assets, and
  their tests into `codex-sandboxing`
  - keep `codex-core` owning only the seatbelt spawn wrapper and switch
  call sites to import the moved APIs directly
  
  ## Notes
  - no re-exports added
  - moved the seatbelt tests with the implementation so internal helpers
  could stay private
  - local verification is still finishing while this PR is open

  pakrym-oai · 2026-03-23 21:26:35 -07:00
  431af0807c
• Extract landlock helpers into codex-sandboxing (#15592)

  ## Summary
  - add a new `codex-sandboxing` crate for sandboxing extraction work
  - move the pure Linux sandbox argv builders and their unit tests out of
  `codex-core`
  - keep `core::landlock` as the spawn wrapper and update direct callers
  to use `codex_sandboxing::landlock`
  
  ## Testing
  - `cargo test -p codex-sandboxing`
  - `cargo test -p codex-core landlock`
  - `cargo test -p codex-cli debug_sandbox`
  - `just argument-comment-lint`
  
  ## Notes
  - this is step 1 of the move plan aimed at minimizing per-PR diffs
  - no re-exports or no-op proxy methods were added

  pakrym-oai · 2026-03-23 20:56:15 -07:00
  2227248cd6
• 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`

  Michael Bolin · 2026-03-20 03:19:22 +00:00
  fa2a2f0be9
• 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