263 Commits

• Stabilize marketplace add local source test (#17424)

  ## Summary
  - Update the marketplace add local-source integration test to pass an
  explicit relative local path.
  - Keep the change test-only; no CLI source parsing behavior changes.
  
  ## Tests
  - cargo fmt -p codex-cli
  - cargo test -p codex-cli --test marketplace_add
  
  ## Impact
  - Production behavior is unchanged.
  - No impact to feedback upload logic, DAGs, exports, or downstream
  pipelines.
  
  Co-authored-by: Codex <noreply@openai.com>

  ningyi-oai · 2026-04-11 05:06:59 +00:00
  a9796e39c4
• Add marketplace command (#17087)

  Added a new top-level `codex marketplace add` command for installing
  plugin marketplaces into Codex’s local marketplace cache.
  
  This change adds source parsing for local directories, GitHub shorthand,
  and git URLs, supports optional `--ref` and git-only `--sparse` checkout
  paths, stages the source in a temp directory, validates the marketplace
  manifest, and installs it under
  `$CODEX_HOME/marketplaces/<marketplace-name>`
  
  Included tests cover local install behavior in the CLI and marketplace
  discovery from installed roots in core. Scoped formatting and fix passes
  were run, and targeted CLI/core tests passed.

  xli-oai · 2026-04-10 19:18:37 -07:00
  f9a8d1870f
• fix: support split carveouts in windows elevated sandbox (#14568)

  ## Summary
  - preserve legacy Windows elevated sandbox behavior for existing
  policies
  - add elevated-only support for split filesystem policies that can be
  represented as readable-root overrides, writable-root overrides, and
  extra deny-write carveouts
  - resolve those elevated filesystem overrides during sandbox transform
  and thread them through setup and policy refresh
  - keep failing closed for explicit unreadable (`none`) carveouts and
  reopened writable descendants under read-only carveouts
  - for explicit read-only-under-writable-root carveouts, materialize
  missing carveout directories during elevated setup before applying the
  deny-write ACL
  - document the elevated vs restricted-token support split in the core
  README
  
  ## Example
  Given a split filesystem policy like:
  
  ```toml
  ":root" = "read"
  ":cwd" = "write"
  "./docs" = "read"
  "C:/scratch" = "write"
  ```
  
  the elevated backend now provisions the readable-root overrides,
  writable-root overrides, and extra deny-write carveouts during setup and
  refresh instead of collapsing back to the legacy workspace-only shape.
  
  If a read-only carveout under a writable root is missing at setup time,
  elevated setup creates that carveout as an empty directory before
  applying its deny-write ACE; otherwise the sandboxed command could
  create it later and bypass the carveout. This is only for explicit
  policy carveouts. Best-effort workspace protections like `.codex/` and
  `.agents/` still skip missing directories.
  
  A policy like:
  
  ```toml
  "/workspace" = "write"
  "/workspace/docs" = "read"
  "/workspace/docs/tmp" = "write"
  ```
  
  still fails closed, because the elevated backend does not reopen
  writable descendants under read-only carveouts yet.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-09 17:34:52 -07:00
  b976e701a8
• Add top-level exec-server subcommand (#17162)

  ## Summary
  - add a top-level `codex exec-server` subcommand, marked experimental in
  CLI help
  - launch an adjacent or PATH-provided `codex-exec-server`, with a
  source-tree `cargo run -p codex-exec-server --` fallback
  - cover the new subcommand parser path
  
  ## Validation
  - `just fmt`
  - `git diff --check`
  - not run: Rust test suite
  
  Co-authored-by: Codex <noreply@openai.com>
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-08 15:38:07 -07:00
  49677ec71f
• Wire realtime WebRTC native media into Bazel (#17145)

  - Builds codex-realtime-webrtc through the normal Bazel Rust macro so
  native macOS WebRTC sources are included.\n- Shares the macOS -ObjC link
  flag with Bazel targets that can link libwebrtc.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-08 15:15:55 -07:00
  19bd018300
• Add WebRTC media transport to realtime TUI (#17058)

  Adds the `[realtime].transport = "webrtc"` TUI media path using a new
  `codex-realtime-webrtc` crate, while leaving app-server as the
  signaling/event source.\n\nLocal checks: fmt, diff-check, dependency
  tree only; test signal should come from CI.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-08 10:26:55 -07:00
  d90a348870
• Fix missing resume hint on zero-token exits (#16987)

  Addresses #16421
  
  Problem: Resumed interactive sessions exited before new token usage
  skipped all footer lines, hiding the `codex resume` continuation
  command.
  
  It's not clear whether this was an intentional design choice, but I
  think it's reasonable to expect this message under these circumstances.
  
  Solution: Compose token usage and resume hints independently so
  resumable sessions still print the continuation command with zero usage.

  Eric Traut · 2026-04-07 09:34:04 -07:00
  2b9bf5d3d4
• [codex] reduce module visibility (#16978)

  ## Summary
  - reduce public module visibility across Rust crates, preferring private
  or crate-private modules with explicit crate-root public exports
  - update external call sites and tests to use the intended public crate
  APIs instead of reaching through module trees
  - add the module visibility guideline to AGENTS.md
  
  ## Validation
  - `cargo check --workspace --all-targets --message-format=short` passed
  before the final fix/format pass
  - `just fix` completed successfully
  - `just fmt` completed successfully
  - `git diff --check` passed

  pakrym-oai · 2026-04-07 08:03:35 -07:00
  413c1e1fdf
• Refactor config types into a separate crate (#16962)

  Move config types into a separate crate because their macros expand into
  a lot of new code.

  pakrym-oai · 2026-04-07 00:32:41 +00:00
  1f2411629f
• app-server: Add transport for remote control (#15951)
  Ruslan Nigmatullin · 2026-04-06 14:55:59 -07:00
  73dab2046f
• [codex] allow disabling prompt instruction blocks (#16735)

  This PR adds root and profile config switches to omit the generated
  `<permissions instructions>` and `<apps_instructions>` prompt blocks
  while keeping both enabled by default, and it gates both the initial
  developer-context injection and later permissions diff injection so
  turning the permissions block off stays effective across turn-context
  overrides.
  
  Also added a prompt debug tool that can be used as `codex debug
  prompt-input "hello"` and dumps the constructed items list.

  Thibault Sottiaux · 2026-04-03 23:47:56 +00:00
  8d19646861
• remove temporary ownership re-exports (#16626)

  Stacked on #16508.
  
  This removes the temporary `codex-core` / `codex-login` re-export shims
  from the ownership split and rewrites callsites to import directly from
  `codex-model-provider-info`, `codex-models-manager`, `codex-api`,
  `codex-protocol`, `codex-feedback`, and `codex-response-debug-context`.
  
  No behavior change intended; this is the mechanical import cleanup layer
  split out from the ownership move.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-03 00:33:34 -07:00
  af8a9d2d2b
• Fix deprecated login --api-key parsing (#16658)

  Addresses #16655
  
  Problem: `codex login --api-key` failed in Clap before Codex could show
  the deprecation guidance.
  
  Solution: Allow the hidden `--api-key` flag to parse with zero or one
  values so both forms reach the `--with-api-key` message.

  Eric Traut · 2026-04-02 22:43:53 -07:00
  8cd7f20b48
• [codex] Remove codex-core config type shim (#16529)

  ## Why
  
  This finishes the config-type move out of `codex-core` by removing the
  temporary compatibility shim in `codex_core::config::types`. Callers now
  depend on `codex-config` directly, which keeps these config model types
  owned by the config crate instead of re-expanding `codex-core` as a
  transitive API surface.
  
  ## What Changed
  
  - Removed the `codex-rs/core/src/config/types.rs` re-export shim and the
  `core::config::ApprovalsReviewer` re-export.
  - Updated `codex-core`, `codex-cli`, `codex-tui`, `codex-app-server`,
  `codex-mcp-server`, and `codex-linux-sandbox` call sites to import
  `codex_config::types` directly.
  - Added explicit `codex-config` dependencies to downstream crates that
  previously relied on the `codex-core` re-export.
  - Regenerated `codex-rs/core/config.schema.json` after updating the
  config docs path reference.

  Michael Bolin · 2026-04-02 01:19:44 -07:00
  c1d18ceb6f
• core: remove cross-crate re-exports from lib.rs (#16512)

  ## Why
  
  `codex-core` was re-exporting APIs owned by sibling `codex-*` crates,
  which made downstream crates depend on `codex-core` as a proxy module
  instead of the actual owner crate.
  
  Removing those forwards makes crate boundaries explicit and lets leaf
  crates drop unnecessary `codex-core` dependencies. In this PR, this
  reduces the dependency on `codex-core` to `codex-login` in the following
  files:
  
  ```
  codex-rs/backend-client/Cargo.toml
  codex-rs/mcp-server/tests/common/Cargo.toml
  ```
  
  ## What
  
  - Remove `codex-rs/core/src/lib.rs` re-exports for symbols owned by
  `codex-login`, `codex-mcp`, `codex-rollout`, `codex-analytics`,
  `codex-protocol`, `codex-shell-command`, `codex-sandboxing`,
  `codex-tools`, and `codex-utils-path`.
  - Delete the `default_client` forwarding shim in `codex-rs/core`.
  - Update in-crate and downstream callsites to import directly from the
  owning `codex-*` crate.
  - Add direct Cargo dependencies where callsites now target the owner
  crate, and remove `codex-core` from `codex-rs/backend-client`.

  Michael Bolin · 2026-04-01 23:06:24 -07:00
  aa2403e2eb
• core: use codex-mcp APIs directly (#16510)

  ## Why
  
  `codex-mcp` already owns the shared MCP API surface, including `auth`,
  `McpConfig`, `CODEX_APPS_MCP_SERVER_NAME`, and tool-name helpers in
  [`codex-rs/codex-mcp/src/mcp/mod.rs`](https://github.com/openai/codex/blob/f61e85dbfb5373cde6827d232ac8ea447c237e81/codex-rs/codex-mcp/src/mcp/mod.rs#L1-L35).
  Re-exporting that surface from `codex_core::mcp` gives downstream crates
  two import paths for the same API and hides the real crate dependency.
  
  This PR keeps `codex_core::mcp` focused on the local `McpManager`
  wrapper in
  [`codex-rs/core/src/mcp.rs`](https://github.com/openai/codex/blob/f61e85dbfb5373cde6827d232ac8ea447c237e81/codex-rs/core/src/mcp.rs#L13-L40)
  and makes consumers import shared MCP APIs from `codex_mcp` directly.
  
  ## What
  
  - Remove the `codex_mcp::mcp` re-export surface from `core/src/mcp.rs`.
  - Update `codex-core` internals plus `codex-app-server`, `codex-cli`,
  and `codex-tui` test code to import MCP APIs from `codex_mcp::mcp`
  directly.
  - Add explicit `codex-mcp` dependencies where those crates now use that
  API surface, and refresh `Cargo.lock`.
  
  ## Verification
  
  - `just bazel-lock-check`
  - `cargo test -p codex-core -p codex-cli -p codex-tui`
    - `codex-cli` passed.
  - `codex-core` still fails five unrelated config tests in
  `core/src/config/config_tests.rs` (`approvals_reviewer_*` and
  `smart_approvals_alias_*`).
  - A broader `cargo test -p codex-core -p codex-app-server -p codex-cli
  -p codex-tui` run previously hung in `codex-app-server` test
  `in_process_start_uses_requested_session_source_for_thread_start`.

  Michael Bolin · 2026-04-01 21:55:22 -07:00
  cc97982bbb
• 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