655 Commits

• Remove the codex-tui app-server originator workaround (#16116)

  ## Summary
  - remove the temporary `codex-tui` special-case when setting the default
  originator during app-server initialization

  Eric Traut · 2026-03-28 13:53:33 -06:00
  178d2b00b1
• 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
• Add ChatGPT device-code login to app server (#15525)

  ## Problem
  
  App-server clients could only initiate ChatGPT login through the browser
  callback flow, even though the shared login crate already supports
  device-code auth. That left VS Code, Codex App, and other app-server
  clients without a first-class way to use the existing device-code
  backend when browser redirects are brittle or when the client UX wants
  to own the login ceremony.
  
  ## Mental model
  
  This change adds a second ChatGPT login start path to app-server:
  clients can now call `account/login/start` with `type:
  "chatgptDeviceCode"`. App-server immediately returns a `loginId` plus
  the device-code UX payload (`verificationUrl` and `userCode`), then
  completes the login asynchronously in the background using the existing
  `codex_login` polling flow. Successful device-code login still resolves
  to ordinary `chatgpt` auth, and completion continues to flow through the
  existing `account/login/completed` and `account/updated` notifications.
  
  ## Non-goals
  
  This does not introduce a new auth mode, a new account shape, or a
  device-code eligibility discovery API. It also does not add automatic
  fallback to browser login in core; clients remain responsible for
  choosing when to request device code and whether to retry with a
  different UX if the backend/admin policy rejects it.
  
  ## Tradeoffs
  
  We intentionally keep `login_chatgpt_common` as a local validation
  helper instead of turning it into a capability probe. Device-code
  eligibility is checked by actually calling `request_device_code`, which
  means policy-disabled cases surface as an immediate request error rather
  than an async completion event. We also keep the active-login state
  machine minimal: browser and device-code logins share the same public
  cancel contract, but device-code cancellation is implemented with a
  local cancel token rather than a larger cross-crate refactor.
  
  ## Architecture
  
  The protocol grows a new `chatgptDeviceCode` request/response variant in
  app-server v2. On the server side, the new handler reuses the existing
  ChatGPT login precondition checks, calls `request_device_code`, returns
  the device-code payload, and then spawns a background task that waits on
  either cancellation or `complete_device_code_login`. On success, it
  reuses the existing auth reload and cloud-requirements refresh path
  before emitting `account/login/completed` success and `account/updated`.
  On failure or cancellation, it emits only `account/login/completed`
  failure. The existing `account/login/cancel { loginId }` contract
  remains unchanged and now works for both browser and device-code
  attempts.
  
  
  ## Tests
  
  Added protocol serialization coverage for the new request/response
  variant, plus app-server tests for device-code success, failure, cancel,
  and start-time rejection behavior. Existing browser ChatGPT login
  coverage remains in place to show that the callback-based flow is
  unchanged.

  daniel-oai · 2026-03-27 00:27:15 -07:00
  47a9e2e084
• chore: refactor network permissions to use explicit domain and unix socket rule maps (#15120)

  ## Summary
  
  This PR replaces the legacy network allow/deny list model with explicit
  rule maps for domains and unix sockets across managed requirements,
  permissions profiles, the network proxy config, and the app server
  protocol.
  
  Concretely, it:
  
  - introduces typed domain (`allow` / `deny`) and unix socket permission
  (`allow` / `none`) entries instead of separate `allowed_domains`,
  `denied_domains`, and `allow_unix_sockets` lists
  - updates config loading, managed requirements merging, and exec-policy
  overlays to read and upsert rule entries consistently
  - exposes the new shape through protocol/schema outputs, debug surfaces,
  and app-server config APIs
  - rejects the legacy list-based keys and updates docs/tests to reflect
  the new config format
  
  ## Why
  
  The previous representation split related network policy across multiple
  parallel lists, which made merging and overriding rules harder to reason
  about. Moving to explicit keyed permission maps gives us a single source
  of truth per host/socket entry, makes allow/deny precedence clearer, and
  gives protocol consumers access to the full rule state instead of
  derived projections only.
  
  ## Backward Compatibility
  
  ### Backward compatible
  
  - Managed requirements still accept the legacy
  `experimental_network.allowed_domains`,
  `experimental_network.denied_domains`, and
  `experimental_network.allow_unix_sockets` fields. They are normalized
  into the new canonical `domains` and `unix_sockets` maps internally.
  - App-server v2 still deserializes legacy `allowedDomains`,
  `deniedDomains`, and `allowUnixSockets` payloads, so older clients can
  continue reading managed network requirements.
  - App-server v2 responses still populate `allowedDomains`,
  `deniedDomains`, and `allowUnixSockets` as legacy compatibility views
  derived from the canonical maps.
  - `managed_allowed_domains_only` keeps the same behavior after
  normalization. Legacy managed allowlists still participate in the same
  enforcement path as canonical `domains` entries.
  
  ### Not backward compatible
  
  - Permissions profiles under `[permissions.<profile>.network]` no longer
  accept the legacy list-based keys. Those configs must use the canonical
  `[domains]` and `[unix_sockets]` tables instead of `allowed_domains`,
  `denied_domains`, or `allow_unix_sockets`.
  - Managed `experimental_network` config cannot mix canonical and legacy
  forms in the same block. For example, `domains` cannot be combined with
  `allowed_domains` or `denied_domains`, and `unix_sockets` cannot be
  combined with `allow_unix_sockets`.
  - The canonical format can express explicit `"none"` entries for unix
  sockets, but those entries do not round-trip through the legacy
  compatibility fields because the legacy fields only represent allow/deny
  lists.
  ## Testing
  `/target/debug/codex sandbox macos --log-denials /bin/zsh -c 'curl
  https://www.example.com' ` gives 200 with config
  ```
  [permissions.workspace.network.domains]
  "www.example.com" = "allow"
  ```
  and fails when set to deny: `curl: (56) CONNECT tunnel failed, response
  403`.
  
  Also tested backward compatibility path by verifying that adding the
  following to `/etc/codex/requirements.toml` works:
  ```
  [experimental_network]
  allowed_domains = ["www.example.com"]
  ```

  Celia Chen · 2026-03-27 06:17:59 +00:00
  dd30c8eedd
• 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
• codex-tools: extract shared tool schema parsing (#15923)

  ## Why
  
  `parse_tool_input_schema` and the supporting `JsonSchema` model were
  living in `core/src/tools/spec.rs`, but they already serve callers
  outside `codex-core`.
  
  Keeping that shared schema parsing logic inside `codex-core` makes the
  crate boundary harder to reason about and works against the guidance in
  `AGENTS.md` to avoid growing `codex-core` when reusable code can live
  elsewhere.
  
  This change takes the first extraction step by moving the schema parsing
  primitive into its own crate while keeping the rest of the tool-spec
  assembly in `codex-core`.
  
  ## What changed
  
  - added a new `codex-tools` crate under `codex-rs/tools`
  - moved the shared tool input schema model and sanitizer/parser into
  `tools/src/json_schema.rs`
  - kept `tools/src/lib.rs` exports-only, with the module-level unit tests
  split into `json_schema_tests.rs`
  - updated `codex-core` to use `codex-tools::JsonSchema` and re-export
  `parse_tool_input_schema`
  - updated `codex-app-server` dynamic tool validation to depend on
  `codex-tools` directly instead of reaching through `codex-core`
  - wired the new crate into the Cargo workspace and Bazel build graph

  Michael Bolin · 2026-03-27 00:03:35 +00:00
  44d28f500f
• chore: remove skill metadata from command approval payloads (#15906)

  ## Why
  
  This is effectively a follow-up to
  [#15812](https://github.com/openai/codex/pull/15812). That change
  removed the special skill-script exec path, but `skill_metadata` was
  still being threaded through command-approval payloads even though the
  approval flow no longer uses it to render prompts or resolve decisions.
  
  Keeping it around added extra protocol, schema, and client surface area
  without changing behavior.
  
  Removing it keeps the command-approval contract smaller and avoids
  carrying a dead field through app-server, TUI, and MCP boundaries.
  
  ## What changed
  
  - removed `ExecApprovalRequestSkillMetadata` and the corresponding
  `skillMetadata` field from core approval events and the v2 app-server
  protocol
  - removed the generated JSON and TypeScript schema output for that field
  - updated app-server, MCP server, TUI, and TUI app-server approval
  plumbing to stop forwarding the field
  - cleaned up tests that previously constructed or asserted
  `skillMetadata`
  
  ## Testing
  
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-protocol`
  - `cargo test -p codex-app-server-test-client`
  - `cargo test -p codex-mcp-server`
  - `just argument-comment-lint`

  Michael Bolin · 2026-03-26 15:32:03 -07:00
  5906c6a658
• [codex] import token_data from codex-login directly (#15903)

  ## Why
  `token_data` is owned by `codex-login`, but `codex-core` was still
  re-exporting it. That let callers pull auth token types through
  `codex-core`, which keeps otherwise unrelated crates coupled to
  `codex-core` and makes `codex-core` more of a build-graph bottleneck.
  
  ## What changed
  - remove the `codex-core` re-export of `codex_login::token_data`
  - update the remaining `codex-core` internals that used
  `crate::token_data` to import `codex_login::token_data` directly
  - update downstream callers in `codex-rs/chatgpt`,
  `codex-rs/tui_app_server`, `codex-rs/app-server/tests/common`, and
  `codex-rs/core/tests` to import `codex_login::token_data` directly
  - add explicit `codex-login` workspace dependencies and refresh lock
  metadata for crates that now depend on it directly
  
  ## Validation
  - `cargo test -p codex-chatgpt --locked`
  - `just argument-comment-lint`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  
  ## Notes
  - attempted `cargo test -p codex-core --locked` and `cargo test -p
  codex-core auth_refresh --locked`, but both ran out of disk while
  linking `codex-core` test binaries in the local environment

  Michael Bolin · 2026-03-26 13:34:02 -07:00
  b23789b770
• app-server: Split transport module (#15811)

  `transport.rs` is getting pretty big, split individual transport
  implementations into separate files.

  Ruslan Nigmatullin · 2026-03-26 13:01:35 -07:00
  9736fa5e3d
• fix: fix old system bubblewrap compatibility without falling back to vendored bwrap (#15693)

  Fixes #15283.
  
  ## Summary
  Older system bubblewrap builds reject `--argv0`, which makes our Linux
  sandbox fail before the helper can re-exec. This PR keeps using system
  `/usr/bin/bwrap` whenever it exists and only falls back to vendored
  bwrap when the system binary is missing. That matters on stricter
  AppArmor hosts, where the distro bwrap package also provides the policy
  setup needed for user namespaces.
  
  For old system bwrap, we avoid `--argv0` instead of switching binaries:
  - pass the sandbox helper a full-path `argv0`,
  - keep the existing `current_exe() + --argv0` path when the selected
  launcher supports it,
  - otherwise omit `--argv0` and re-exec through the helper's own
  `argv[0]` path, whose basename still dispatches as
  `codex-linux-sandbox`.
  
  Also updates the launcher/warning tests and docs so they match the new
  behavior: present-but-old system bwrap uses the compatibility path, and
  only absent system bwrap falls back to vendored.
  
  ### Validation
  
  1. Install Ubuntu 20.04 in a VM
  2. Compile codex and run without bubblewrap installed - see a warning
  about falling back to the vendored bwrap
  3. Install bwrap and verify version is 0.4.0 without `argv0` support
  4. run codex and use apply_patch tool without errors
  
  <img width="802" height="631" alt="Screenshot 2026-03-25 at 11 48 36 PM"
  src="https://github.com/user-attachments/assets/77248a29-aa38-4d7c-9833-496ec6a458b8"
  />
  <img width="807" height="634" alt="Screenshot 2026-03-25 at 11 47 32 PM"
  src="https://github.com/user-attachments/assets/5af8b850-a466-489b-95a6-455b76b5050f"
  />
  <img width="812" height="635" alt="Screenshot 2026-03-25 at 11 45 45 PM"
  src="https://github.com/user-attachments/assets/438074f0-8435-4274-a667-332efdd5cb57"
  />
  <img width="801" height="623" alt="Screenshot 2026-03-25 at 11 43 56 PM"
  src="https://github.com/user-attachments/assets/0dc8d3f5-e8cf-4218-b4b4-a4f7d9bf02e3"
  />
  
  ---------
  
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  viyatb-oai · 2026-03-25 23:51:39 -07:00
  937cb5081d
• [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
• app-server: Organize app-server to allow more transports (#15810)

  Make `run_main_with_transport` slightly more flexible by consolidating
  logic spread across stdio and websocket transports.

  Ruslan Nigmatullin · 2026-03-25 17:11:22 -07:00
  d7e35e56cf
• Add cached environment manager for exec server URL (#15785)

  Add environment manager that is a singleton and is created early in
  app-server (before skill manager, before config loading).
  
  Use an environment variable to point to a running exec server.

  pakrym-oai · 2026-03-25 16:14:36 -07:00
  8fa88fa8ca
• Avoid duplicate auth refreshes in getAuthStatus (#15798)

  I've seen several intermittent failures of
  `get_auth_status_returns_token_after_proactive_refresh_recovery` today.
  I investigated, and I found a couple of issues.
  
  First, `getAuthStatus(refreshToken=true)` could refresh twice in one
  request: once via `refresh_token_if_requested()` and again via the
  proactive refresh path inside `auth_manager.auth()`. In the
  permanent-failure case this produced an extra `/oauth/token` call and
  made the app-server auth tests flaky. Use `auth_cached()` after an
  explicit refresh request so the handler reuses the post-refresh auth
  state instead of immediately re-entering proactive refresh logic. Keep
  the existing proactive path for `refreshToken=false`.
  
  Second, serialize auth refresh attempts in `AuthManager` have a
  startup/request race. One proactive refresh could already be in flight
  while a `getAuthStatus(refreshToken=false)` request entered
  `auth().await`, causing a second `/oauth/token` call before the first
  failure or refresh result had been recorded. Guarding the refresh flow
  with a single async lock makes concurrent callers share one refresh
  result, which prevents duplicate refreshes and stabilizes the
  proactive-refresh auth tests.

  Eric Traut · 2026-03-25 16:03:53 -06:00
  2c67a27a71
• Extract codex-core-skills crate (#15749)

  ## Summary
  - move skill loading and management into codex-core-skills
  - leave codex-core with the thin integration layer and shared wiring
  
  ## Testing
  - CI
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-25 12:57:42 -07:00
  9dbe098349
• 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
• Extract codex-analytics crate (#15748)

  ## Summary
  - move the analytics events client into codex-analytics
  - update codex-core and app-server callsites to use the new crate
  
  ## Testing
  - CI
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-25 11:08:05 -07:00
  d273efc0f3
• 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
• [plugins] Add a flag for tool search. (#15722)

  - [x] Add a flag for tool search.

  Matthew Zeng · 2026-03-25 07:00:25 +00:00
  e590fad50b
• fix: support split carveouts in windows restricted-token sandbox (#14172)

  ## Summary
  - keep legacy Windows restricted-token sandboxing as the supported
  baseline
  - support the split-policy subset that restricted-token can enforce
  directly today
  - support full-disk read, the same writable root set as legacy
  `WorkspaceWrite`, and extra read-only carveouts under those writable
  roots via additional deny-write ACLs
  - continue to fail closed for unsupported split-only shapes, including
  explicit unreadable (`none`) carveouts, reopened writable descendants
  under read-only carveouts, and writable root sets that do not match the
  legacy workspace roots
  
  ## Example
  Given a filesystem policy like:
  
  ```toml
  ":root" = "read"
  ":cwd" = "write"
  "./docs" = "read"
  ```
  
  the restricted-token backend can keep the workspace writable while
  denying writes under `docs` by layering an extra deny-write carveout on
  top of the legacy workspace-write roots.
  
  A policy like:
  
  ```toml
  "/workspace" = "write"
  "/workspace/docs" = "read"
  "/workspace/docs/tmp" = "write"
  ```
  
  still fails closed, because the unelevated backend cannot reopen the
  nested writable descendant safely.
  
  ## Stack
  -> fix: support split carveouts in windows restricted-token sandbox
  #14172
  fix: support split carveouts in windows elevated sandbox #14568

  viyatb-oai · 2026-03-24 22:54:18 -07:00
  95ba762620
• [app-server] Add a method to override feature flags. (#15601)

  - [x] Add a method to override feature flags globally and not just
  thread level.

  Matthew Zeng · 2026-03-25 02:27:00 +00:00
  0b08d89304
• app-server: Return codex home in initialize response (#15689)

  This allows clients to get enough information to interact with the codex
  skills/configuration/etc.

  Ruslan Nigmatullin · 2026-03-24 16:13:34 -07:00
  24c4ecaaac
• app-server: add filesystem watch support (#14533)

  ### Summary
  Add the v2 app-server filesystem watch RPCs and notifications, wire them
  through the message processor, and implement connection-scoped watches
  with notify-backed change delivery. This also updates the schema
  fixtures, app-server documentation, and the v2 integration coverage for
  watch and unwatch behavior.
  
  This allows clients to efficiently watch for filesystem updates, e.g. to
  react on branch changes.
  
  ### Testing
  - exercise watch lifecycles for directory changes, atomic file
  replacement, missing-file targets, and unwatch cleanup

  Ruslan Nigmatullin · 2026-03-24 15:52:13 -07:00
  301b17c2a1
• Drop sandbox_permissions from sandbox exec requests (#15665)

  ## Summary
  - drop `sandbox_permissions` from the sandboxing `ExecOptions` and
  `ExecRequest` adapter types
  - remove the now-unused plumbing from shell, unified exec, JS REPL, and
  apply-patch runtime call sites
  - default reconstructed `ExecParams` to `SandboxPermissions::UseDefault`
  where the lower-level API still requires the field
  
  ## Testing
  - `just fmt`
  - `just argument-comment-lint`
  - `cargo test -p codex-core` (still running locally; first failures
  observed in `suite::cli_stream::responses_mode_stream_cli`,
  `suite::cli_stream::responses_mode_stream_cli_supports_openai_base_url_config_override`,
  and
  `suite::cli_stream::responses_mode_stream_cli_supports_openai_base_url_env_fallback`)

  pakrym-oai · 2026-03-24 15:42:45 -07:00
  0b619afc87
• Suppress plugin-install MCP OAuth URL console spam (#15666)

  Switch plugin-install background MCP OAuth to a silent login path so the
  raw authorization URL is no longer printed in normal success cases.
  OAuth behavior is otherwise unchanged, with fallback URL output via
  stderr still shown only if browser launch fails.
  
  Before:
  
  https://github.com/user-attachments/assets/4bf387af-afa8-4b83-bcd6-4ca6b55da8db

  canvrno-oai · 2026-03-24 14:46:21 -07:00
  4b91a7b391
• tui_app_server: cancel active login before Ctrl+C exit (#15673)

  ## Summary
  
  Fixes slow `Ctrl+C` exit from the ChatGPT browser-login screen in
  `tui_app_server`.
  
  ## Root cause
  
  Onboarding-level `Ctrl+C` quit bypassed the auth widget's cancel path.
  That let the active ChatGPT login keep running, and in-process
  app-server shutdown then waited on the stale login attempt before
  finishing.
  
  ## Changes
  
  - Extract a shared `cancel_active_attempt()` path in the auth widget
  - Use that path from onboarding-level `Ctrl+C` before exiting the TUI
  - Add focused tests for canceling browser-login and device-code attempts
  - Add app-server shutdown cleanup that explicitly drops any active login
  before draining background work

  Eric Traut · 2026-03-24 15:11:43 -06:00
  c023e9d959
• Move git utilities into a dedicated crate (#15564)

  - create `codex-git-utils` and move the shared git helpers into it with
  file moves preserved for diff readability
  - move the `GitInfo` helpers out of `core` so stacked rollout work can
  depend on the shared crate without carrying its own git info module
  
  ---------
  
  Co-authored-by: Ahmed Ibrahim <219906144+aibrahim-oai@users.noreply.github.com>
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-24 13:26:23 -07:00
  0f957a93cd
• fix: keep zsh-fork release assets after removing shell-tool-mcp (#15644)

  ## Why
  
  `shell-tool-mcp` and the Bash fork are no longer needed, but the patched
  zsh fork is still relevant for shell escalation and for the
  DotSlash-backed zsh-fork integration tests.
  
  Deleting the old `shell-tool-mcp` workflow also deleted the only
  pipeline that rebuilt those patched zsh binaries. This keeps the package
  removal, while preserving a small release path that can be reused
  whenever `codex-rs/shell-escalation/patches/zsh-exec-wrapper.patch`
  changes.
  
  ## What changed
  
  - removed the `shell-tool-mcp` workspace package, its npm
  packaging/release jobs, the Bash test fixture, and the remaining
  Bash-specific compatibility wiring
  - deleted the old `.github/workflows/shell-tool-mcp.yml` and
  `.github/workflows/shell-tool-mcp-ci.yml` workflows now that their
  responsibilities have been replaced or removed
  - kept the zsh patch under
  `codex-rs/shell-escalation/patches/zsh-exec-wrapper.patch` and updated
  the `codex-rs/shell-escalation` docs/code to describe the zsh-based flow
  directly
  - added `.github/workflows/rust-release-zsh.yml` to build only the three
  zsh binaries that `codex-rs/app-server/tests/suite/zsh` needs today:
    - `aarch64-apple-darwin` on `macos-15`
    - `x86_64-unknown-linux-musl` on `ubuntu-24.04`
    - `aarch64-unknown-linux-musl` on `ubuntu-24.04`
  - extracted the shared zsh build/smoke-test/stage logic into
  `.github/scripts/build-zsh-release-artifact.sh`, made that helper
  directly executable, and now invoke it directly from the workflow so the
  Linux and macOS jobs only keep the OS-specific setup in YAML
  - wired those standalone `codex-zsh-*.tar.gz` assets into
  `rust-release.yml` and added `.github/dotslash-zsh-config.json` so
  releases also publish a `codex-zsh` DotSlash file
  - updated the checked-in `codex-rs/app-server/tests/suite/zsh` fixture
  comments to explain that new releases come from the standalone zsh
  assets, while the checked-in fixture remains pinned to the latest
  historical release until a newer zsh artifact is published
  - tightened a couple of follow-on cleanups in
  `codex-rs/shell-escalation`: the `ExecParams::command` comment now
  describes the shell `-c`/`-lc` string more clearly, and the README now
  points at the same `git.code.sf.net` zsh source URL that the workflow
  uses
  
  ## Testing
  
  - `cargo test -p codex-shell-escalation`
  - `just argument-comment-lint`
  - `bash -n .github/scripts/build-zsh-release-artifact.sh`
  - attempted `cargo test -p codex-core`; unrelated existing failures
  remain, but the touched `tools::runtimes::shell::unix_escalation::*`
  coverage passed during that run

  Michael Bolin · 2026-03-24 12:56:26 -07:00
  e89e5136bd
• chore: stop app-server auth refresh storms after permanent token failure (#15530)

  built from #14256. PR description from @etraut-openai:
  
  This PR addresses a hole in [PR
  11802](https://github.com/openai/codex/pull/11802). The previous PR
  assumed that app server clients would respond to token refresh failures
  by presenting the user with an error ("you must log in again") and then
  not making further attempts to call network endpoints using the expired
  token. While they do present the user with this error, they don't
  prevent further attempts to call network endpoints and can repeatedly
  call `getAuthStatus(refreshToken=true)` resulting in many failed calls
  to the token refresh endpoint.
  
  There are three solutions I considered here:
  1. Change the getAuthStatus app server call to return a null auth if the
  caller specified "refreshToken" on input and the refresh attempt fails.
  This will cause clients to immediately log out the user and return them
  to the log in screen. This is a really bad user experience. It's also a
  breaking change in the app server contract that could break third-party
  clients.
  2. Augment the getAuthStatus app server call to return an additional
  field that indicates the state of "token could not be refreshed". This
  is a non-breaking change to the app server API, but it requires
  non-trivial changes for all clients to properly handle this new field
  properly.
  3. Change the getAuthStatus implementation to handle the case where a
  token refresh fails by marking the AuthManager's in-memory access and
  refresh tokens as "poisoned" so it they are no longer used. This is the
  simplest fix that requires no client changes.
  
  I chose option 3.
  
  Here's Codex's explanation of this change:
  
  When an app-server client asks `getAuthStatus(refreshToken=true)`, we
  may try to refresh a stale ChatGPT access token. If that refresh fails
  permanently (for example `refresh_token_reused`, expired, or revoked),
  the old behavior was bad in two ways:
  
  1. We kept the in-memory auth snapshot alive as if it were still usable.
  2. Later auth checks could retry refresh again and again, creating a
  storm of doomed `/oauth/token` requests and repeatedly surfacing the
  same failure.
  
  This is especially painful for app-server clients because they poll auth
  status and can keep driving the refresh path without any real chance of
  recovery.
  
  This change makes permanent refresh failures terminal for the current
  managed auth snapshot without changing the app-server API contract.
  
  What changed:
  - `AuthManager` now poisons the current managed auth snapshot in memory
  after a permanent refresh failure, keyed to the unchanged `AuthDotJson`.
  - Once poisoned, later refresh attempts for that same snapshot fail fast
  locally without calling the auth service again.
  - The poison is cleared automatically when auth materially changes, such
  as a new login, logout, or reload of different auth state from storage.
  - `getAuthStatus(includeToken=true)` now omits `authToken` after a
  permanent refresh failure instead of handing out the stale cached bearer
  token.
  
  This keeps the current auth method visible to clients, avoids forcing an
  immediate logout flow, and stops repeated refresh attempts for
  credentials that cannot recover.
  
  ---------
  
  Co-authored-by: Eric Traut <etraut@openai.com>

  Celia Chen · 2026-03-24 12:39:58 -07:00
  88694e8417
• feat: include marketplace loading error in plugin/list (#15438)

  Include error.

  xl-openai · 2026-03-24 11:47:23 -07:00
  621862a7d1
• app-server: Add back pressure and batching to command/exec (#15547)

  * Add
  `OutgoingMessageSender::send_server_notification_to_connection_and_wait`
  which returns only once message is written to websocket (or failed to do
  so)
  * Use this mechanism to apply back pressure to stdout/stderr streams of
  processes spawned by `command/exec`, to limit them to at most one
  message in-memory at a time
  * Use back pressure signal to also batch smaller chunks into ≈64KiB ones
  
  This should make commands execution more robust over
  high-latency/low-throughput networks

  Ruslan Nigmatullin · 2026-03-24 11:35:51 -07:00
  d61c03ca08
• Extract sandbox manager and transforms into codex-sandboxing (#15603)

  Extract sandbox manager

  pakrym-oai · 2026-03-24 08:20:57 -07:00
  f49eb8e9d7
• Finish moving codex exec to app-server (#15424)

  This PR completes the conversion of non-interactive `codex exec` to use
  app server rather than directly using core events and methods.
  
  ### Summary
  - move `codex-exec` off exec-owned `AuthManager` and `ThreadManager`
  state
  - route exec bootstrap, resume, and auth refresh through existing
  app-server paths
  - replace legacy `codex/event/*` decoding in exec with typed app-server
  notification handling
  - update human and JSONL exec output adapters to translate existing
  app-server notifications only
  - clean up "app server client" layer by eliminating support for legacy
  notifications; this is no longer needed
  - remove exposure of `authManager` and `threadManager` from "app server
  client" layer
  
  ### Testing
  - `exec` has pretty extensive unit and integration tests already, and
  these all pass
  - In addition, I asked Codex to put together a comprehensive manual set
  of tests to cover all of the `codex exec` functionality (including
  command-line options), and it successfully generated and ran these tests

  Eric Traut · 2026-03-24 08:51:32 -06:00
  45f68843b8
• Stabilize macOS CI test timeouts (#15581)

  ## Summary
  - raise the shell snapshot apply_patch helper timeout to avoid macOS CI
  startup races
  - increase the shared MCP app-server test read timeout so slow
  initialize handshakes do not fail command_exec tests spuriously
  
  ## Testing
  - cargo test -p codex-core
  shell_command_snapshot_still_intercepts_apply_patch
  - cargo test -p codex-app-server
  command_exec_tty_implies_streaming_and_reports_pty_output
  
  Co-authored-by: Codex <noreply@openai.com>

  Dylan Hurd · 2026-03-24 09:33:20 +00:00
  79577355c1
• Move sandbox policy transforms into codex-sandboxing (#15599)

  ## Summary
  - move the pure sandbox policy transform helpers from `codex-core` into
  `codex-sandboxing`
  - move the corresponding unit tests with the extracted implementation
  - update `core` and `app-server` callers to import the moved APIs
  directly, without re-exports or proxy methods
  
  ## Testing
  - cargo test -p codex-sandboxing
  - cargo test -p codex-core sandboxing
  - cargo test -p codex-app-server --lib
  - just fix -p codex-sandboxing
  - just fix -p codex-core
  - just fix -p codex-app-server
  - just fmt
  - just argument-comment-lint

  pakrym-oai · 2026-03-23 22:22:44 -07:00
  9deb8ce3fc
• [codex-cli][app-server] Update self-serve business usage limit copy in error returned (#15478)

  ## Summary
  - update the self-serve business usage-based limit message to direct
  users to their admin for additional credits
  - add a focused unit test for the self_serve_business_usage_based plan
  branch
  
  Added also: 
  
  If you are at a rate limit but you still have credits, codex cli would
  tell you to switch the model. We shouldnt do this if you have credits so
  fixed this.
  
  ## Test
  - launched the source-built CLI and verified the updated message is
  shown for the self-serve business usage-based plan
  
  ![Test
  screenshot](https://raw.githubusercontent.com/openai/codex/5cc3c013ef17ac5c66dfd9395c0d3c4837602231/docs/images/self-serve-business-usage-limit.png)

  dhruvgupta-oai · 2026-03-24 04:41:38 +00:00
  c2410060ea
• Add fork snapshot modes (#15239)

  ## Summary
  - add `ForkSnapshotMode` to `ThreadManager::fork_thread` so callers can
  request either a committed snapshot or an interrupted snapshot
  - share the model-visible `<turn_aborted>` history marker between the
  live interrupt path and interrupted forks
  - update the small set of direct fork callsites to pass
  `ForkSnapshotMode::Committed`
  
  Note: this enables /btw to work similarly as Esc to interrupt (hopefully
  somewhat in distribution)
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Charley Cunningham · 2026-03-23 19:05:42 -07:00
  f547b79bd0
• feat: support disable skills by name. (#15378)

  Support disabling skills by name, primarily for plugin skills. We can’t
  use the path, since plugin skill paths may change across versions.

  xl-openai · 2026-03-23 12:57:40 -07:00
  9a33e5c0a0
• tui: queue follow-ups during manual /compact (#15259)

  ## Summary
  - queue input after the user submits `/compact` until that manual
  compact turn ends
  - mirror the same behavior in the app-server TUI
  - add regressions for input queued before compact starts and while it is
  running
  
  Co-authored-by: Codex <noreply@openai.com>

  Charley Cunningham · 2026-03-23 10:19:44 -07:00
  e838645fa2
• fix: fall back to vendored bubblewrap when system bwrap lacks --argv0 (#15338)

  ## Why
  
  Fixes [#15283](https://github.com/openai/codex/issues/15283), where
  sandboxed tool calls fail on older distro `bubblewrap` builds because
  `/usr/bin/bwrap` does not understand `--argv0`. The upstream [bubblewrap
  v0.9.0 release
  notes](https://github.com/containers/bubblewrap/releases/tag/v0.9.0)
  explicitly call out `Add --argv0`. Flipping `use_legacy_landlock`
  globally works around that compatibility bug, but it also weakens the
  default Linux sandbox and breaks proxy-routed and split-policy cases
  called out in review.
  
  The follow-up Linux CI failure was in the new launcher test rather than
  the launcher logic: the fake `bwrap` helper stayed open for writing, so
  Linux would not exec it. This update also closes the user-visibility gap
  from review by surfacing the same startup warning when `/usr/bin/bwrap`
  is present but too old for `--argv0`, not only when it is missing.
  
  ## What Changed
  
  - keep `use_legacy_landlock` default-disabled
  - teach `codex-rs/linux-sandbox/src/launcher.rs` to fall back to the
  vendored bubblewrap build when `/usr/bin/bwrap` does not advertise
  `--argv0` support
  - add launcher tests for supported, unsupported, and missing system
  `bwrap`
  - write the fake `bwrap` test helper to a closed temp path so the
  supported-path launcher test works on Linux too
  - extend the startup warning path so Codex warns when `/usr/bin/bwrap`
  is missing or too old to support `--argv0`
  - mirror the warning/fallback wording across
  `codex-rs/linux-sandbox/README.md` and `codex-rs/core/README.md`,
  including that the fallback is the vendored bubblewrap compiled into the
  binary
  - cite the upstream `bubblewrap` release that introduced `--argv0`
  
  ## Verification
  
  - `bazel test --config=remote --platforms=//:rbe
  //codex-rs/linux-sandbox:linux-sandbox-unit-tests
  --test_filter=launcher::tests::prefers_system_bwrap_when_help_lists_argv0
  --test_output=errors`
  - `cargo test -p codex-core system_bwrap_warning`
  - `cargo check -p codex-exec -p codex-tui -p codex-tui-app-server -p
  codex-app-server`
  - `just argument-comment-lint`

  Michael Bolin · 2026-03-23 09:46:51 -07:00
  d1088158b8
• Pass platform param to featured plugins (#15348)
  alexsong-oai · 2026-03-21 01:42:40 +00:00
  ec32866c37
• Add realtime transcript notification in v2 (#15344)

  - emit a typed `thread/realtime/transcriptUpdated` notification from
  live realtime transcript deltas
  - expose that notification as flat `threadId`, `role`, and `text` fields
  instead of a nested transcript array
  - continue forwarding raw `handoff_request` items on
  `thread/realtime/itemAdded`, including the accumulated
  `active_transcript`
  - update app-server docs, tests, and generated protocol schema artifacts
  to match the delta-based payloads
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-20 15:30:48 -07:00
  3431f01776
• feat: change multi-agent to use path-like system instead of uuids (#15313)

  This PR add an URI-based system to reference agents within a tree. This
  comes from a sync between research and engineering.
  
  The main agent (the one manually spawned by a user) is always called
  `/root`. Any sub-agent spawned by it will be `/root/agent_1` for example
  where `agent_1` is chosen by the model.
  
  Any agent can contact any agents using the path.
  
  Paths can be used either in absolute or relative to the calling agents
  
  Resume is not supported for now on this new path

  jif-oai · 2026-03-20 18:23:48 +00:00
  79ad7b247b
• Add temporary app-server originator fallback for codex-tui (#15218)

  ## Summary
  - make app-server treat `clientInfo.name == "codex-tui"` as a legacy
  compatibility case
  - fall back to `DEFAULT_ORIGINATOR` instead of sending `codex-tui` as
  the originator header
  - add a TODO noting this is a temporary workaround that should be
  removed later
  
  ## Testing
  - Not run (not requested)

  Eric Traut · 2026-03-20 10:51:21 -06:00
  4f28b64abc
• feat: Add One-Time Startup Remote Plugin Sync (#15264)

  For early users who have already enabled apps, we should enable plugins
  as part of the initial setup.

  xl-openai · 2026-03-20 05:01:39 +00:00
  b1570d6c23
• 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
• core: add a full-buffer exec capture policy (#15254)
  Michael Bolin · 2026-03-20 02:38:12 +00:00
  a3e59e9e85
• [plugins] Install MCPs when calling plugin/install (#15195)

  - [x] Auth MCPs when installing plugins.

  Matthew Zeng · 2026-03-19 19:36:58 -07:00
  0a344e4fab
• 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