273 Commits

• chore: do not disable memories for past rollouts on reset (#17919)
  jif-oai · 2026-04-15 12:05:39 +01:00
  5e544be3c9
• Support Unix socket allowlists in macOS sandbox (#17654)

  ## Changes
  
  Allows sandboxes to restrict overall network access while granting
  access to specific unix sockets on mac.
  
  ## Details
  
  - `codex sandbox macos`: adds a repeatable `--allow-unix-socket` option.
  - `codex-sandboxing`: threads explicit Unix socket roots into the macOS
  Seatbelt profile generation.
  - Preserves restricted network behavior when only Unix socket IPC is
  requested, and preserves full network behavior when full network is
  already enabled.
  
  ## Verification
  
  - `cargo test -p codex-cli -p codex-sandboxing`
  - `cargo build -p codex-cli --bin codex`
  - verified that `codex sandbox macos --allow-unix-socket /tmp/test.sock
  -- test-client` grants access as expected

  aaronl-openai · 2026-04-15 00:53:24 -07:00
  2e1003728c
• [codex] Support local marketplace sources (#17756)

  ## Summary
  
  - Port marketplace source support into the shared core marketplace-add
  flow
  - Support local marketplace directory sources
  - Support direct `marketplace.json` URL sources
  - Persist the new source types in config/schema and cover them in CLI
  and app-server tests
  
  ## Validation
  
  - `cargo test -p codex-core marketplace_add`
  - `cargo test -p codex-cli marketplace_add`
  - `cargo test -p codex-app-server marketplace_add`
  - `just write-config-schema`
  - `just fmt`
  - `just fix -p codex-core`
  - `just fix -p codex-cli`
  
  ## Context
  
  Current `main` moved marketplace-add behavior into shared core code and
  still assumed only git-backed sources. This change keeps that structure
  but restores support for local directories and direct manifest URLs in
  the shared path.

  xli-oai · 2026-04-14 15:58:14 -07:00
  3cc689fb23
• Keep image_detail_original as a removed feature flag (#17803)
  Curtis 'Fjord' Hawthorne · 2026-04-14 18:06:50 +00:00
  769b1c3d7e
• feat: codex sampler (#17784)

  Add a pure sampler using the Codex auth and model config. To be used by
  other binary such as tape recorder

  jif-oai · 2026-04-14 17:00:18 +01:00
  b3ae531b3a
• Refactor plugin loading to async (#17747)

  Simplifies skills migration.

  pakrym-oai · 2026-04-13 21:52:56 -07:00
  3b24a9a532
• [codex] Refactor marketplace add into shared core flow (#17717)

  ## Summary
  
  Move `codex marketplace add` onto a shared core implementation so the
  CLI and app-server path can use one source of truth.
  
  This change:
  - adds shared marketplace-add orchestration in `codex-core`
  - switches the CLI command to call that shared implementation
  - removes duplicated CLI-only marketplace add helpers
  - preserves focused parser and add-path coverage while moving the shared
  behavior into core tests
  
  ## Why
  
  The new `marketplace/add` RPC should reuse the same underlying
  marketplace-add flow as the CLI. This refactor lands that consolidation
  first so the follow-up app-server PR can be mostly protocol and handler
  wiring.
  
  ## Validation
  
  - `cargo test -p codex-core marketplace_add`
  - `cargo test -p codex-cli marketplace_cmd`
  - `just fix -p codex-core`
  - `just fix -p codex-cli`
  - `just fmt`

  xli-oai · 2026-04-13 20:37:11 -07:00
  ff584c5a4b
• Add supports_parallel_tool_calls flag to included mcps (#17667)

  ## Why
  
  For more advanced MCP usage, we want the model to be able to emit
  parallel MCP tool calls and have Codex execute eligible ones
  concurrently, instead of forcing all MCP calls through the serial block.
  
  The main design choice was where to thread the config. I made this
  server-level because parallel safety depends on the MCP server
  implementation. Codex reads the flag from `mcp_servers`, threads the
  opted-in server names into `ToolRouter`, and checks the parsed
  `ToolPayload::Mcp { server, .. }` at execution time. That avoids relying
  on model-visible tool names, which can be incomplete in
  deferred/search-tool paths or ambiguous for similarly named
  servers/tools.
  
  ## What was added
  
  Added `supports_parallel_tool_calls` for MCP servers.
  
  Before:
  
  ```toml
  [mcp_servers.docs]
  command = "docs-server"
  ```
  
  After:
  
  ```toml
  [mcp_servers.docs]
  command = "docs-server"
  supports_parallel_tool_calls = true
  ```
  
  MCP calls remain serial by default. Only tools from opted-in servers are
  eligible to run in parallel. Docs also now warn to enable this only when
  the server’s tools are safe to run concurrently, especially around
  shared state or read/write races.
  
  ## Testing
  
  Tested with a local stdio MCP server exposing real delay tools. The
  model/Responses side was mocked only to deterministically emit two MCP
  calls in the same turn.
  
  Each test called `query_with_delay` and `query_with_delay_2` with `{
  "seconds": 25 }`.
  
  | Build/config | Observed | Wall time |
  | --- | --- | --- |
  | main with flag enabled | serial | `58.79s` |
  | PR with flag enabled | parallel | `31.73s` |
  | PR without flag | serial | `56.70s` |
  
  PR with flag enabled showed both tools start before either completed;
  main and PR-without-flag completed the first delay before starting the
  second.
  
  Also added an integration test.
  
  Additional checks:
  
  - `cargo test -p codex-tools` passed
  - `cargo test -p codex-core
  mcp_parallel_support_uses_exact_payload_server` passed
  - `git diff --check` passed

  josiah-openai · 2026-04-13 15:16:34 -07:00
  937dd3812d
• Use AbsolutePathBuf in skill loading and codex_home (#17407)

  Helps with FS migration later

  pakrym-oai · 2026-04-13 10:26:51 -07:00
  ac82443d07
• Run exec-server fs operations through sandbox helper (#17294)

  ## Summary
  - run exec-server filesystem RPCs requiring sandboxing through a
  `codex-fs` arg0 helper over stdin/stdout
  - keep direct local filesystem execution for `DangerFullAccess` and
  external sandbox policies
  - remove the standalone exec-server binary path in favor of top-level
  arg0 dispatch/runtime paths
  - add sandbox escape regression coverage for local and remote filesystem
  paths
  
  ## Validation
  - `just fmt`
  - `git diff --check`
  - remote devbox: `cd codex-rs && bazel test --bes_backend=
  --bes_results_url= //codex-rs/exec-server:all` (6/6 passed)
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-12 18:36:03 -07:00
  d626dc3895
• 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