93 Commits

• Remove exec-server fs sandbox request preflight (#17883)

  ## Summary
  - Remove the exec-server-side manual filesystem request path preflight
  before invoking the sandbox helper.
  - Keep sandbox helper policy construction and platform sandbox
  enforcement as the access boundary.
  - Add a portable local+remote regression for writing through an
  explicitly configured alias root.
  - Remove the metadata symlink-escape assertion that depended on the
  deleted manual preflight; no replacement metadata-specific access probe
  is added.
  
  ## Tests
  - `cargo test -p codex-exec-server --lib`
  - `cargo test -p codex-exec-server --test file_system`
  - `git diff --check`

  pakrym-oai · 2026-04-15 09:28:30 -07:00
  1dead46c90
• Route apply_patch through the environment filesystem (#17674)

  ## Summary
  - route apply_patch runtime execution through the selected Environment
  filesystem instead of the local self-exec path
  - keep the standalone apply_patch command surface intact while restoring
  its launcher/test/docs contract
  - add focused apply_patch filesystem sandbox regression coverage
  
  ## Validation
  - remote devbox Bazel run in progress
  - passed: //codex-rs/apply-patch:apply-patch-unit-tests
  --test_filter=test_read_file_utf8_with_context_reports_invalid_utf8
  - in progress / follow-up: focused core and exec Bazel test slices on
  dev
  
  ## Follow-up under review
  - remote pre-verification and approval/retry behavior still need
  explicit scrutiny for delete/update flows
  - runtime sandbox-denial classification may need a tighter assertion
  path than rendered stderr matching
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-14 12:49:02 -07:00
  c24124b37d
• [codex] Add symlink flag to fs metadata (#17719)

  Add `is_symlink` to FsMetadata struct.

  pakrym-oai · 2026-04-13 17:46:56 -07:00
  f3cbe3d385
• Stabilize exec-server filesystem tests in CI (#17671)

  ## Summary\n- add an exec-server package-local test helper binary that
  can run exec-server and fs-helper flows\n- route exec-server filesystem
  tests through that helper instead of cross-crate codex helper
  binaries\n- stop relying on Bazel-only extra binary wiring for these
  tests\n\n## Testing\n- not run (per repo guidance for codex changes)
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-13 16:53:42 -07:00
  280a4a6d42
• fix: stability exec server (#17640)
  jif-oai · 2026-04-13 14:52:12 +01:00
  49ca7c9f24
• Build remote exec env from exec-server policy (#17216)

  ## Summary
  - add an exec-server `envPolicy` field; when present, the server starts
  from its own process env and applies the shell environment policy there
  - keep `env` as the exact environment for local/embedded starts, but
  make it an overlay for remote unified-exec starts
  - move the shell-environment-policy builder into `codex-config` so Core
  and exec-server share the inherit/filter/set/include behavior
  - overlay only runtime/sandbox/network deltas from Core onto the
  exec-server-derived env
  
  ## Why
  Remote unified exec was materializing the shell env inside Core and
  forwarding the whole map to exec-server, so remote processes could
  inherit the orchestrator machine's `HOME`, `PATH`, etc. This keeps the
  base env on the executor while preserving Core-owned runtime additions
  like `CODEX_THREAD_ID`, unified-exec defaults, network proxy env, and
  sandbox marker env.
  
  ## Validation
  - `just fmt`
  - `git diff --check`
  - `cargo test -p codex-exec-server --lib`
  - `cargo test -p codex-core --lib unified_exec::process_manager::tests`
  - `cargo test -p codex-core --lib exec_env::tests`
  - `cargo test -p codex-core --lib exec_env_tests` (compile-only; filter
  matched 0 tests)
  - `cargo test -p codex-config --lib shell_environment` (compile-only;
  filter matched 0 tests)
  - `just bazel-lock-update`
  
  ## Known local validation issue
  - `just bazel-lock-check` is not runnable in this checkout: it invokes
  `./scripts/check-module-bazel-lock.sh`, which is missing.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>
  Co-authored-by: pakrym-oai <pakrym@openai.com>

  jif-oai · 2026-04-13 09:59:08 +01:00
  bacb92b1d7
• Stabilize exec-server process tests (#17605)

  Problem: After #17294 switched exec-server tests to launch the top-level
  `codex exec-server` command, parallel remote exec-process cases can
  flake while waiting for the child server's listen URL or transport
  shutdown.
  
  Solution: Serialize remote exec-server-backed process tests and harden
  the harness so spawned servers are killed on drop and shutdown waits for
  the child process to exit.

  Eric Traut · 2026-04-13 00:31:13 -07:00
  6550007cca
• 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
• feat: move exec-server ownership (#16344)

  This introduces session-scoped ownership for exec-server so ws
  disconnects no longer immediately kill running remote exec processes,
  and it prepares the protocol for reconnect-based resume.
  - add session_id / resume_session_id to the exec-server initialize
  handshake
    - move process ownership under a shared session registry
  - detach sessions on websocket disconnect and expire them after a TTL
  instead of killing processes immediately (we will resume based on this)
  - allow a new connection to resume an existing session and take over
  notifications/ownership
  - I use UUID to make them not predictable as we don't have auth for now
  - make detached-session expiry authoritative at resume time so teardown
  wins at the TTL boundary
  - reject long-poll process/read calls that get resumed out from under an
  older attachment
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-04-10 14:11:47 +01:00
  085ffb4456
• Add sandbox support to filesystem APIs (#16751)

  ## Summary
  - add optional `sandboxPolicy` support to the app-server filesystem
  request surface
  - thread sandbox-aware filesystem options through app-server and
  exec-server adapters
  - enforce sandboxed read/write access in the filesystem abstraction with
  focused local and remote coverage
  
  ## Validation
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-exec-server file_system`
  - `cargo test -p codex-app-server suite::v2::fs`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-08 12:10:48 -07:00
  f383cc980d
• [codex] Migrate apply_patch to executor filesystem (#17027)

  - Migrate apply-patch verification and application internals to use the
  async `ExecutorFileSystem` abstraction from `exec-server`.
  - Convert apply-patch `cwd` handling to `AbsolutePathBuf` through the
  verifier/parser/handler boundary.
  
  Doesn't change how the tool itself works.

  pakrym-oai · 2026-04-07 21:20:22 +00:00
  e9702411ab
• 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
• feat: use ProcessId in exec-server (#15866)

  Use a full struct for the ProcessId to increase readability and make it
  easier in the future to make it evolve if needed

  jif-oai · 2026-03-26 16:45:36 +01:00
  6d2f4aaafc
• feat: exec-server prep for unified exec (#15691)

  This PR partially rebase `unified_exec` on the `exec-server` and adapt
  the `exec-server` accordingly.
  
  ## What changed in `exec-server`
  
  1. Replaced the old "broadcast-driven; process-global" event model with
  process-scoped session events. The goal is to be able to have dedicated
  handler for each process.
  2. Add to protocol contract to support explicit lifecycle status and
  stream ordering:
  - `WriteResponse` now returns `WriteStatus` (Accepted, UnknownProcess,
  StdinClosed, Starting) instead of a bool.
    - Added seq fields to output/exited notifications.
    - Added terminal process/closed notification.
  3. Demultiplexed remote notifications into per-process channels. Same as
  for the event sys
  4. Local and remote backends now both implement ExecBackend.
  5. Local backend wraps internal process ID/operations into per-process
  ExecProcess objects.
  6. Remote backend registers a session channel before launch and
  unregisters on failed launch.
  
  ## What changed in `unified_exec`
  
  1. Added unified process-state model and backend-neutral process
  wrapper. This will probably disappear in the future, but it makes it
  easier to keep the work flowing on both side.
  - `UnifiedExecProcess` now handles both local PTY sessions and remote
  exec-server processes through a shared `ProcessHandle`.
  - Added `ProcessState` to track has_exited, exit_code, and terminal
  failure message consistently across backends.
  2. Routed write and lifecycle handling through process-level methods.
  
  ## Some rationals
  
  1. The change centralizes execution transport in exec-server while
  preserving policy and orchestration ownership in core, avoiding
  duplicated launch approval logic. This comes from internal discussion.
  2. Session-scoped events remove coupling/cross-talk between processes
  and make stream ordering and terminal state explicit (seq, closed,
  failed).
  3. The failure-path surfacing (remote launch failures, write failures,
  transport disconnects) makes command tool output and cleanup behavior
  deterministic
  
  ## Follow-ups:
  * Unify the concept of thread ID behind an obfuscated struct
  * FD handling
  * Full zsh-fork compatibility
  * Full network sandboxing compatibility
  * Handle ws disconnection

  jif-oai · 2026-03-26 15:22:34 +01:00
  7dac332c93
• 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
• Split exec process into local and remote implementations (#15233)

  ## Summary
  - match the exec-process structure to filesystem PR #15232
  - expose `ExecProcess` on `Environment`
  - make `LocalProcess` the real implementation and `RemoteProcess` a thin
  network proxy over `ExecServerClient`
  - make `ProcessHandler` a thin RPC adapter delegating to `LocalProcess`
  - add a shared local/remote process test
  
  ## Validation
  - `just fmt`
  - `CARGO_TARGET_DIR=~/.cache/cargo-target/codex cargo test -p
  codex-exec-server`
  - `just fix -p codex-exec-server`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-03-20 03:13:08 +00:00
  96a86710c3
• Refactor ExecServer filesystem split between local and remote (#15232)

  For each feature we have:
  1. Trait exposed on environment
  2. **Local Implementation** of the trait
  3. Remote implementation that uses the client to proxy via network
  4. Handler implementation that handles PRC requests and calls into
  **Local Implementation**

  pakrym-oai · 2026-03-19 17:08:04 -07:00
  403b397e4e
• Add exec-server exec RPC implementation (#15090)

  Stacked PR 2/3, based on the stub PR.
  
  Adds the exec RPC implementation and process/event flow in exec-server
  only.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-03-19 19:00:36 +00:00
  1d210f639e
• Remove stdio transport from exec server (#15119)

  Summary
  - delete the deprecated stdio transport plumbing from the exec server
  stack
  - add a basic `exec_server()` harness plus test utilities to start a
  server, send requests, and await events
  - refresh exec-server dependencies, configs, and documentation to
  reflect the new flow
  
  Testing
  - Not run (not requested)
  
  ---------
  
  Co-authored-by: starr-openai <starr@openai.com>
  Co-authored-by: Codex <noreply@openai.com>

  pakrym-oai · 2026-03-19 01:00:35 +00:00
  903660edba
• Add exec-server stub server and protocol docs (#15089)

  Stacked PR 1/3.
  
  This is the initialize-only exec-server stub slice: binary/client
  scaffolding and protocol docs, without exec/filesystem implementation.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-03-19 00:30:05 +00:00
  81996fcde6
• refactor: delete exec-server and move execve wrapper into shell-escalation (#12632)

  ## Why
  
  We already plan to remove the shell-tool MCP path, and doing that
  cleanup first makes the follow-on `shell-escalation` work much simpler.
  
  This change removes the last remaining reason to keep
  `codex-rs/exec-server` around by moving the `codex-execve-wrapper`
  binary and shared shell test fixtures to the crates/tests that now own
  that functionality.
  
  ## What Changed
  
  ### Delete `codex-rs/exec-server`
  
  - Remove the `exec-server` crate, including the MCP server binary,
  MCP-specific modules, and its test support/test suite
  - Remove `exec-server` from the `codex-rs` workspace and update
  `Cargo.lock`
  
  ### Move `codex-execve-wrapper` into `codex-rs/shell-escalation`
  
  - Move the wrapper implementation into `shell-escalation`
  (`src/unix/execve_wrapper.rs`)
  - Add the `codex-execve-wrapper` binary entrypoint under
  `shell-escalation/src/bin/`
  - Update `shell-escalation` exports/module layout so the wrapper
  entrypoint is hosted there
  - Move the wrapper README content from `exec-server` to
  `shell-escalation/README.md`
  
  ### Move shared shell test fixtures to `app-server`
  
  - Move the DotSlash `bash`/`zsh` test fixtures from
  `exec-server/tests/suite/` to `app-server/tests/suite/`
  - Update `app-server` zsh-fork tests to reference the new fixture paths
  
  ### Keep `shell-tool-mcp` as a shell-assets package
  
  - Update `.github/workflows/shell-tool-mcp.yml` packaging so the npm
  artifact contains only patched Bash/Zsh payloads (no Rust binaries)
  - Update `shell-tool-mcp/package.json`, `shell-tool-mcp/src/index.ts`,
  and docs to reflect the shell-assets-only package shape
  - `shell-tool-mcp-ci.yml` does not need changes because it is already
  JS-only
  
  ## Verification
  
  - `cargo shear`
  - `cargo clippy -p codex-shell-escalation --tests`
  - `just clippy`

  Michael Bolin · 2026-02-23 20:10:22 -08:00
  38f84b6b29
• test: vendor zsh fork via DotSlash and stabilize zsh-fork tests (#12518)

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

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

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

  Michael Bolin · 2026-02-20 23:45:35 -08:00
  1af2a37ada
• feat(shell-tool-mcp): add patched zsh build pipeline (#11668)

  ## Summary
  - add `shell-tool-mcp/patches/zsh-exec-wrapper.patch` against upstream
  zsh `77045ef899e53b9598bebc5a41db93a548a40ca6`
  - add `zsh-linux` and `zsh-darwin` jobs to
  `.github/workflows/shell-tool-mcp.yml`
  - stage zsh binaries under `artifacts/vendor/<target>/zsh/<variant>/zsh`
  - include zsh artifact jobs in `package.needs`
  - mark staged zsh binaries executable during packaging
  
  ## Notes
  - zsh source is cloned from `https://git.code.sf.net/p/zsh/code`
  - workflow pins zsh commit `77045ef899e53b9598bebc5a41db93a548a40ca6`
  - zsh build runs `./Util/preconfig` before `./configure`
  
  ## Validation
  - parsed workflow YAML locally (`yaml-ok`)
  - validated zsh patch applies cleanly with `git apply --check` on a
  fresh zsh clone

  Jeremy Rose · 2026-02-13 01:34:48 +00:00
  9cf7a07281
• Bump rmcp to 0.15 (#11539)

  https://github.com/modelcontextprotocol/rust-sdk/pull/598 in 0.14 broke
  some MCP oauth (like Linear) and
  https://github.com/modelcontextprotocol/rust-sdk/pull/641 fixed it in
  0.15

  Gabriel Peal · 2026-02-11 22:04:17 -08:00
  bd3ce98190
• feat: make sandbox read access configurable with ReadOnlyAccess (#11387)

  `SandboxPolicy::ReadOnly` previously implied broad read access and could
  not express a narrower read surface.
  This change introduces an explicit read-access model so we can support
  user-configurable read restrictions in follow-up work, while preserving
  current behavior today.
  
  It also ensures unsupported backends fail closed for restricted-read
  policies instead of silently granting broader access than intended.
  
  ## What
  
  - Added `ReadOnlyAccess` in protocol with:
    - `Restricted { include_platform_defaults, readable_roots }`
    - `FullAccess`
  - Updated `SandboxPolicy` to carry read-access configuration:
    - `ReadOnly { access: ReadOnlyAccess }`
    - `WorkspaceWrite { ..., read_only_access: ReadOnlyAccess }`
  - Preserved existing behavior by defaulting current construction paths
  to `ReadOnlyAccess::FullAccess`.
  - Threaded the new fields through sandbox policy consumers and call
  sites across `core`, `tui`, `linux-sandbox`, `windows-sandbox`, and
  related tests.
  - Updated Seatbelt policy generation to honor restricted read roots by
  emitting scoped read rules when full read access is not granted.
  - Added fail-closed behavior on Linux and Windows backends when
  restricted read access is requested but not yet implemented there
  (`UnsupportedOperation`).
  - Regenerated app-server protocol schema and TypeScript artifacts,
  including `ReadOnlyAccess`.
  
  ## Compatibility / rollout
  
  - Runtime behavior remains unchanged by default (`FullAccess`).
  - API/schema changes are in place so future config wiring can enable
  restricted read access without another policy-shape migration.

  Michael Bolin · 2026-02-11 18:31:14 -08:00
  abbd74e2be
• Upgrade rmcp to 0.14 (#10718)

  - [x] Upgrade rmcp to 0.14

  Matthew Zeng · 2026-02-08 15:07:53 -08:00
  9f1009540b
• feat(linux-sandbox): add bwrap support (#9938)

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

  viyatb-oai · 2026-02-04 11:13:17 -08:00
  ae4de43ccc
• feat: add support for building with Bazel (#8875)

  This PR configures Codex CLI so it can be built with
  [Bazel](https://bazel.build) in addition to Cargo. The `.bazelrc`
  includes configuration so that remote builds can be done using
  [BuildBuddy](https://www.buildbuddy.io).
  
  If you are familiar with Bazel, things should work as you expect, e.g.,
  run `bazel test //... --keep-going` to run all the tests in the repo,
  but we have also added some new aliases in the `justfile` for
  convenience:
  
  - `just bazel-test` to run tests locally
  - `just bazel-remote-test` to run tests remotely (currently, the remote
  build is for x86_64 Linux regardless of your host platform). Note we are
  currently seeing the following test failures in the remote build, so we
  still need to figure out what is happening here:
  
  ```
  failures:
      suite::compact::manual_compact_twice_preserves_latest_user_messages
      suite::compact_resume_fork::compact_resume_after_second_compaction_preserves_history
      suite::compact_resume_fork::compact_resume_and_fork_preserve_model_history_view
  ```
  
  - `just build-for-release` to build release binaries for all
  platforms/architectures remotely
  
  To setup remote execution:
  - [Create a buildbuddy account](https://app.buildbuddy.io/) (OpenAI
  employees should also request org access at
  https://openai.buildbuddy.io/join/ with their `@openai.com` email
  address.)
  - [Copy your API key](https://app.buildbuddy.io/docs/setup/) to
  `~/.bazelrc` (add the line `build
  --remote_header=x-buildbuddy-api-key=YOUR_KEY`)
  - Use `--config=remote` in your `bazel` invocations (or add `common
  --config=remote` to your `~/.bazelrc`, or use the `just` commands)
  
  ## CI
  
  In terms of CI, this PR introduces `.github/workflows/bazel.yml`, which
  uses Bazel to run the tests _locally_ on Mac and Linux GitHub runners
  (we are working on supporting Windows, but that is not ready yet). Note
  that the failures we are seeing in `just bazel-remote-test` do not occur
  on these GitHub CI jobs, so everything in `.github/workflows/bazel.yml`
  is green right now.
  
  The `bazel.yml` uses extra config in `.github/workflows/ci.bazelrc` so
  that macOS CI jobs build _remotely_ on Linux hosts (using the
  `docker://docker.io/mbolin491/codex-bazel` Docker image declared in the
  root `BUILD.bazel`) using cross-compilation to build the macOS
  artifacts. Then these artifacts are downloaded locally to GitHub's macOS
  runner so the tests can be executed natively. This is the relevant
  config that enables this:
  
  ```
  common:macos --config=remote
  common:macos --strategy=remote
  common:macos --strategy=TestRunner=darwin-sandbox,local
  ```
  
  Because of the remote caching benefits we get from BuildBuddy, these new
  CI jobs can be extremely fast! For example, consider these two jobs that
  ran all the tests on Linux x86_64:
  
  - Bazel 1m37s
  https://github.com/openai/codex/actions/runs/20861063212/job/59940545209?pr=8875
  - Cargo 9m20s
  https://github.com/openai/codex/actions/runs/20861063192/job/59940559592?pr=8875
  
  For now, we will continue to run both the Bazel and Cargo jobs for PRs,
  but once we add support for Windows and running Clippy, we should be
  able to cutover to using Bazel exclusively for PRs, which should still
  speed things up considerably. We will probably continue to run the Cargo
  jobs post-merge for commits that land on `main` as a sanity check.
  
  Release builds will also continue to be done by Cargo for now.
  
  Earlier attempt at this PR: https://github.com/openai/codex/pull/8832
  Earlier attempt to add support for Buck2, now abandoned:
  https://github.com/openai/codex/pull/8504
  
  ---------
  
  Co-authored-by: David Zbarsky <dzbarsky@gmail.com>
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  zbarsky-openai · 2026-01-09 11:09:43 -08:00
  2a06d64bc9
• fix: correct login shell mismatch in the accept_elicitation_for_prompt_rule() test (#8931)

  Because the path to `git` is used to construct `elicitations_to_accept`,
  we need to ensure that we resolve which `git` to use the same way our
  Bash process will:
  
  
  https://github.com/openai/codex/blob/c9c65606852c0cda9d983b4917359a0826a4b7f0/codex-rs/exec-server/tests/suite/accept_elicitation.rs#L59-L69
  
  This fixes an issue when running the test on macOS using Bazel
  (https://github.com/openai/codex/pull/8875) where the login shell chose
  `/opt/homebrew/bin/git` whereas the non-login shell chose
  `/usr/bin/git`.

  Michael Bolin · 2026-01-08 12:37:38 -08:00
  a70f5b0b3c
• fix: make the find_resource! macro responsible for the absolutize() call (#8884)

  https://github.com/openai/codex/pull/8879 introduced the
  `find_resource!` macro, but now that I am about to use it in more
  places, I realize that it should take care of this normalization case
  for callers.
  
  Note the `use $crate::path_absolutize::Absolutize;` line is there so
  that users of `find_resource!` do not have to explicitly include
  `path-absolutize` to their own `Cargo.toml`.

  Michael Bolin · 2026-01-07 23:03:43 -08:00
  35fd69a9f0
• feat: introduce find_resource! macro that works with Cargo or Bazel (#8879)

  To support Bazelification in https://github.com/openai/codex/pull/8875,
  this PR introduces a new `find_resource!` macro that we use in place of
  our existing logic in tests that looks for resources relative to the
  compile-time `CARGO_MANIFEST_DIR` env var.
  
  To make this work, we plan to add the following to all `rust_library()`
  and `rust_test()` Bazel rules in the project:
  
  ```
  rustc_env = {
      "BAZEL_PACKAGE": native.package_name(),
  },
  ```
  
  Our new `find_resource!` macro reads this value via
  `option_env!("BAZEL_PACKAGE")` so that the Bazel package _of the code
  using `find_resource!`_ is injected into the code expanded from the
  macro. (If `find_resource()` were a function, then
  `option_env!("BAZEL_PACKAGE")` would always be
  `codex-rs/utils/cargo-bin`, which is not what we want.)
  
  Note we only consider the `BAZEL_PACKAGE` value when the `RUNFILES_DIR`
  environment variable is set at runtime, indicating that the test is
  being run by Bazel. In this case, we have to concatenate the runtime
  `RUNFILES_DIR` with the compile-time `BAZEL_PACKAGE` value to build the
  path to the resource.
  
  In testing this change, I discovered one funky edge case in
  `codex-rs/exec-server/tests/common/lib.rs` where we have to _normalize_
  (but not canonicalize!) the result from `find_resource!` because the
  path contains a `common/..` component that does not exist on disk when
  the test is run under Bazel, so it must be semantically normalized using
  the [`path-absolutize`](https://crates.io/crates/path-absolutize) crate
  before it is passed to `dotslash fetch`.
  
  Because this new behavior may be non-obvious, this PR also updates
  `AGENTS.md` to make humans/Codex aware that this API is preferred.

  Michael Bolin · 2026-01-07 18:06:08 -08:00
  f6b563ec64
• fix: update resource path resolution logic so it works with Bazel (#8861)

  The Bazelification work in-flight over at
  https://github.com/openai/codex/pull/8832 needs this fix so that Bazel
  can find the path to the DotSlash file for `bash`.
  
  With this change, the following almost works:
  
  ```
  bazel test --test_output=errors //codex-rs/exec-server:exec-server-all-test
  ```
  
  That is, now the `list_tools` test passes, but
  `accept_elicitation_for_prompt_rule` still fails because it runs
  Seatbelt itself, so it needs to be run outside Bazel's local sandboxing.

  Michael Bolin · 2026-01-07 22:33:05 +00:00
  54b290ec1d
• feat: introduce codex-utils-cargo-bin as an alternative to assert_cmd::Command (#8496)

  This PR introduces a `codex-utils-cargo-bin` utility crate that
  wraps/replaces our use of `assert_cmd::Command` and
  `escargot::CargoBuild`.
  
  As you can infer from the introduction of `buck_project_root()` in this
  PR, I am attempting to make it possible to build Codex under
  [Buck2](https://buck2.build) as well as `cargo`. With Buck2, I hope to
  achieve faster incremental local builds (largely due to Buck2's
  [dice](https://buck2.build/docs/insights_and_knowledge/modern_dice/)
  build strategy, as well as benefits from its local build daemon) as well
  as faster CI builds if we invest in remote execution and caching.
  
  See
  https://buck2.build/docs/getting_started/what_is_buck2/#why-use-buck2-key-advantages
  for more details about the performance advantages of Buck2.
  
  Buck2 enforces stronger requirements in terms of build and test
  isolation. It discourages assumptions about absolute paths (which is key
  to enabling remote execution). Because the `CARGO_BIN_EXE_*` environment
  variables that Cargo provides are absolute paths (which
  `assert_cmd::Command` reads), this is a problem for Buck2, which is why
  we need this `codex-utils-cargo-bin` utility.
  
  My WIP-Buck2 setup sets the `CARGO_BIN_EXE_*` environment variables
  passed to a `rust_test()` build rule as relative paths.
  `codex-utils-cargo-bin` will resolve these values to absolute paths,
  when necessary.
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/8496).
  * #8498
  * __->__ #8496

  Michael Bolin · 2025-12-23 19:29:32 -08:00
  e61bae12e3
• fix: change codex/sandbox-state/update from a notification to a request (#8142)

  Historically, `accept_elicitation_for_prompt_rule()` was flaky because
  we were using a notification to update the sandbox followed by a `shell`
  tool request that we expected to be subject to the new sandbox config,
  but because [rmcp](https://crates.io/crates/rmcp) MCP servers delegate
  each incoming message to a new Tokio task, messages are not guaranteed
  to be processed in order, so sometimes the `shell` tool call would run
  before the notification was processed.
  
  Prior to this PR, we relied on a generous `sleep()` between the
  notification and the request to reduce the change of the test flaking
  out.
  
  This PR implements a proper fix, which is to use a _request_ instead of
  a notification for the sandbox update so that we can wait for the
  response to the sandbox request before sending the request to the
  `shell` tool call. Previously, `rmcp` did not support custom requests,
  but I fixed that in
  https://github.com/modelcontextprotocol/rust-sdk/pull/590, which made it
  into the `0.12.0` release (see #8288).
  
  This PR updates `shell-tool-mcp` to expect
  `"codex/sandbox-state/update"` as a _request_ instead of a notification
  and sends the appropriate ack. Note this behavior is tied to our custom
  `codex/sandbox-state` capability, which Codex honors as an MCP client,
  which is why `core/src/mcp_connection_manager.rs` had to be updated as
  part of this PR, as well.
  
  This PR also updates the docs at `shell-tool-mcp/README.md`.

  Michael Bolin · 2025-12-18 15:32:01 -08:00
  46baedd7cb
• chore: upgrade rmcp crate from 0.10.0 to 0.12.0 (#8288)

  Version `0.12.0` includes
  https://github.com/modelcontextprotocol/rust-sdk/pull/590, which I will
  use in https://github.com/openai/codex/pull/8142.
  
  Changes:
  
  - `rmcp::model::CustomClientNotification` was renamed to
  `rmcp::model::CustomNotification`
  - a bunch of types have a `meta` field now, but it is `Option`, so I
  added `meta: None` to a bunch of things

  Michael Bolin · 2025-12-18 14:28:46 -08:00
  53f53173a8
• Fixes mcp elicitation test that fails for me when run locally (#8020)
  Eric Traut · 2025-12-15 16:23:04 -08:00
  d9554c8191
• exec-server: additional context for errors (#7935)

  Add a .context() on some exec-server errors for debugging CI flakes.
  
  Also, "login": false in the test to make the test not affected by user
  profile.

  Jeremy Rose · 2025-12-15 11:40:40 -08:00
  2c6995ca4d
• fix: policy/*.codexpolicy -> rules/*.rules (#7888)

  We decided that `*.rules` is a more fitting (and concise) file extension
  than `*.codexpolicy`, so we are changing the file extension for the
  "execpolicy" effort. We are also changing the subfolder of `$CODEX_HOME`
  from `policy` to `rules` to match.
  
  This PR updates the in-repo docs and we will update the public docs once
  the next CLI release goes out.
  
  Locally, I created `~/.codex/rules/default.rules` with the following
  contents:
  
  ```
  prefix_rule(pattern=["gh", "pr", "view"])
  ```
  
  And then I asked Codex to run:
  
  ```
  gh pr view 7888 --json title,body,comments
  ```
  
  and it was able to!

  Michael Bolin · 2025-12-11 14:46:00 -08:00
  e0d7ac51d3
• fix: add a hopefully-temporary sleep to reduce test flakiness (#7848)

  Let's see if this `sleep()` call is good enough to fix the test
  flakiness we currently see in CI. It will take me some time to upstream
  a proper fix, and I would prefer not to disable this test in the
  interim.

  Michael Bolin · 2025-12-11 00:51:33 +00:00
  038767af69
• fix: ensure accept_elicitation_for_prompt_rule() test passes locally (#7832)

  When I originally introduced `accept_elicitation_for_prompt_rule()` in
  https://github.com/openai/codex/pull/7617, it worked for me locally
  because I had run `codex-rs/exec-server/tests/suite/bash` once myself,
  which had the side-effect of installing the corresponding DotSlash
  artifact.
  
  In CI, I added explicit logic to do this as part of
  `.github/workflows/rust-ci.yml`, which meant the test also passed in CI,
  but this logic should have been done as part of the test so that it
  would work locally for devs who had not installed the DotSlash artifact
  for `codex-rs/exec-server/tests/suite/bash` before. This PR updates the
  test to do this (and deletes the setup logic from `rust-ci.yml`),
  creating a new `DOTSLASH_CACHE` in a temp directory so that this is
  handled independently for each test.
  
  While here, also added a check to ensure that the `codex` binary has
  been built prior to running the test, as we have to ensure it is
  symlinked as `codex-linux-sandbox` on Linux in order for the integration
  test to work on that platform.

  Michael Bolin · 2025-12-10 15:17:13 -08:00
  87f5b69b24
• fix: allow sendmsg(2) and recvmsg(2) syscalls in our Linux sandbox (#7779)

  This changes our default Landlock policy to allow `sendmsg(2)` and
  `recvmsg(2)` syscalls. We believe these were originally denied out of an
  abundance of caution, but given that `send(2)` nor `recv(2)` are allowed
  today [which provide comparable capability to the `*msg` equivalents],
  we do not believe allowing them grants any privileges beyond what we
  already allow.
  
  Rather than using the syscall as the security boundary, preventing
  access to the potentially hazardous file descriptor in the first place
  seems like the right layer of defense.
  
  In particular, this makes it possible for `shell-tool-mcp` to run on
  Linux when using a read-only sandbox for the Bash process, as
  demonstrated by `accept_elicitation_for_prompt_rule()` now succeeding in
  CI.

  Michael Bolin · 2025-12-09 09:24:01 -08:00
  a7e3e37da8
• fix: add integration tests for codex-exec-mcp-server with execpolicy (#7617)

  This PR introduces integration tests that run
  [codex-shell-tool-mcp](https://www.npmjs.com/package/@openai/codex-shell-tool-mcp)
  as a user would. Note that this requires running our fork of Bash, so we
  introduce a [DotSlash](https://dotslash-cli.com/) file for `bash` so
  that we can run the integration tests on multiple platforms without
  having to check the binaries into the repository. (As noted in the
  DotSlash file, it is slightly more heavyweight than necessary, which may
  be worth addressing as disk space in CI is limited:
  https://github.com/openai/codex/pull/7678.)
  
  To start, this PR adds two tests:
  
  - `list_tools()` makes the `list_tools` request to the MCP server and
  verifies we get the expected response
  - `accept_elicitation_for_prompt_rule()` defines a `prefix_rule()` with
  `decision="prompt"` and verifies the elicitation flow works as expected
  
  Though the `accept_elicitation_for_prompt_rule()` test **only works on
  Linux**, as this PR reveals that there are currently issues when running
  the Bash fork in a read-only sandbox on Linux. This will have to be
  fixed in a follow-up PR.
  
  Incidentally, getting this test run to correctly on macOS also requires
  a recent fix we made to `brew` that hasn't hit a mainline release yet,
  so getting CI green in this PR required
  https://github.com/openai/codex/pull/7680.

  Michael Bolin · 2025-12-07 06:39:38 +00:00
  3c3d3d1adc