96 Commits

• 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
• 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 string truncation helpers into codex-utils-string (#15572)

  - move the shared byte-based middle truncation logic from `core` into
  `codex-utils-string`
  - keep token-specific truncation in `codex-core` so rollout can reuse
  the shared helper in the next stacked PR
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-24 15:45:40 -07:00
  062fa7a2bb
• Extract sandbox manager and transforms into codex-sandboxing (#15603)

  Extract sandbox manager

  pakrym-oai · 2026-03-24 08:20:57 -07:00
  f49eb8e9d7
• 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
• Preserve background terminals on interrupt and rename cleanup command to /stop (#14602)

  ### Motivation
  - Interrupting a running turn (Ctrl+C / Esc) currently also terminates
  long‑running background shells, which is surprising for workflows like
  local dev servers or file watchers.
  - The existing cleanup command name was confusing; callers expect an
  explicit command to stop background terminals rather than a UI clear
  action.
  - Make background‑shell termination explicit and surface a clearer
  command name while preserving backward compatibility.
  
  ### Description
  - Renamed the background‑terminal cleanup slash command from `Clean`
  (`/clean`) to `Stop` (`/stop`) and kept `clean` as an alias in the
  command parsing/visibility layer, updated the user descriptions and
  command popup wiring accordingly.
  - Updated the unified‑exec footer text and snapshots to point to `/stop`
  (and trimmed corresponding snapshot output to match the new label).
  - Changed interrupt behavior so `Op::Interrupt` (Ctrl+C / Esc interrupt)
  no longer closes or clears tracked unified exec / background terminal
  processes in the TUI or core cleanup path; background shells are now
  preserved after an interrupt.
  - Updated protocol/docs to clarify that `turn/interrupt` (or
  `Op::Interrupt`) interrupts the active turn but does not terminate
  background terminals, and that `thread/backgroundTerminals/clean` is the
  explicit API to stop those shells.
  - Updated unit/integration tests and insta snapshots in the TUI and core
  unified‑exec suites to reflect the new semantics and command name.
  
  ### Testing
  - Ran formatting with `just fmt` in `codex-rs` (succeeded). 
  - Ran `cargo test -p codex-protocol` (succeeded). 
  - Attempted `cargo test -p codex-tui` but the build could not complete
  in this environment due to a native build dependency that requires
  `libcap` development headers (the `codex-linux-sandbox` vendored build
  step); install `libcap-dev` / make `libcap.pc` available in
  `PKG_CONFIG_PATH` to run the TUI test suite locally.
  - Updated and accepted the affected `insta` snapshots for the TUI
  changes so visual diffs reflect the new `/stop` wording and preserved
  interrupt behavior.
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_69b39c44b6dc8323bd133ae206310fae)

  friel-openai · 2026-03-15 22:17:25 -07:00
  ba463a9dc7
• refactor: make unified-exec zsh-fork state explicit (#14633)

  ## Why
  
  The unified-exec path was carrying zsh-fork state in a partially
  flattened way.
  
  First, the decision about whether zsh-fork was active came from feature
  selection in `ToolsConfig`, while the real prerequisites lived in
  session state. That left the handler and runtime defending against
  partially configured cases later.
  
  Second, once zsh-fork was active, its two runtime-only paths were
  threaded through the runtime as separate arguments even though they form
  one coherent piece of configuration.
  
  This change keeps unified-exec on a single session-derived source of
  truth and bundles the zsh-fork-specific paths into a named config type
  so the runtime can pass them around as one unit.
  
  In particular, this PR introduces this enum so the `ZshFork` variant can
  carry the appropriate state with it:
  
  ```rust
  #[derive(Debug, Clone, Eq, PartialEq)]
  pub enum UnifiedExecShellMode {
      Direct,
      ZshFork(ZshForkConfig),
  }
  
  #[derive(Debug, Clone, Eq, PartialEq)]
  pub struct ZshForkConfig {
      pub(crate) shell_zsh_path: AbsolutePathBuf,
      pub(crate) main_execve_wrapper_exe: AbsolutePathBuf,
  }
  ```
  
  This cleanup was done in preparation for
  https://github.com/openai/codex/pull/13432.
  
  ## What Changed
  
  - Replaced the feature-only `UnifiedExecBackendConfig` split with
  `UnifiedExecShellMode` in `codex-rs/core/src/tools/spec.rs`.
  - Derived the unified-exec mode from session-backed inputs when building
  turn `ToolsConfig`, and preserved that mode across model switches and
  review turns.
  - Introduced `ZshForkConfig`, which stores the resolved zsh-fork
  `AbsolutePathBuf` values for the configured `zsh` binary and `execve`
  wrapper.
  - Threaded `ZshForkConfig` through unified-exec command construction and
  the zsh-fork preparation path so zsh-fork-specific runtime code consumes
  a single config object instead of separate path arguments.
  - Added focused tests for constructing zsh-fork mode only when session
  prerequisites are available, and updated the zsh-fork expectations to be
  target-platform aware.
  
  ## Testing
  
  - `cargo test -p codex-core zsh_fork --lib`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/14633).
  * #13432
  * __->__ #14633

  Michael Bolin · 2026-03-13 17:20:01 -07:00
  b859a98e0f
• fix: preserve zsh-fork escalation fds across unified-exec spawn paths (#13644)

  ## Why
  
  `zsh-fork` sessions launched through unified-exec need the escalation
  socket to survive the wrapper -> server -> child handoff so later
  intercepted `exec()` calls can still reach the escalation server.
  
  The inherited-fd spawn path also needs to avoid closing Rust's internal
  exec-error pipe, and the shell-escalation handoff needs to tolerate the
  receive-side case where a transferred fd is installed into the same
  stdio slot it will be mapped onto.
  
  ## What Changed
  
  - Added `SpawnLifecycle::inherited_fds()` in
  `codex-rs/core/src/unified_exec/process.rs` and threaded inherited fds
  through `codex-rs/core/src/unified_exec/process_manager.rs` so
  unified-exec can preserve required descriptors across both PTY and
  no-stdin pipe spawn paths.
  - Updated `codex-rs/core/src/tools/runtimes/shell/zsh_fork_backend.rs`
  to expose the escalation socket fd through the spawn lifecycle.
  - Added inherited-fd-aware spawn helpers in
  `codex-rs/utils/pty/src/pty.rs` and `codex-rs/utils/pty/src/pipe.rs`,
  including Unix pre-exec fd pruning that preserves requested inherited
  fds while leaving `FD_CLOEXEC` descriptors alone. The pruning helper is
  now named `close_inherited_fds_except()` to better describe that
  behavior.
  - Updated `codex-rs/shell-escalation/src/unix/escalate_client.rs` to
  duplicate local stdio before transfer and send destination stdio numbers
  in `SuperExecMessage`, so the wrapper keeps using its own
  `stdin`/`stdout`/`stderr` until the escalated child takes over.
  - Updated `codex-rs/shell-escalation/src/unix/escalate_server.rs` so the
  server accepts the overlap case where a received fd reuses the same
  stdio descriptor number that the child setup will target with `dup2`.
  - Added comments around the PTY stdio wiring and the overlap regression
  helper to make the fd handoff and controlling-terminal setup easier to
  follow.
  
  ## Verification
  
  - `cargo test -p codex-utils-pty`
  - covers preserved-fd PTY spawn behavior, PTY resize, Python REPL
  continuity, exec-failure reporting, and the no-stdin pipe path
  - `cargo test -p codex-shell-escalation`
  - covers duplicated-fd transfer on the client side and verifies the
  overlap case by passing a pipe-backed stdin payload through the
  server-side `dup2` path
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/13644).
  * #14624
  * __->__ #13644

  Michael Bolin · 2026-03-13 20:25:31 +00:00
  ef37d313c6
• fix: move inline codex-rs/core unit tests into sibling files (#14444)

  ## Why
  PR #13783 moved the `codex.rs` unit tests into `codex_tests.rs`. This
  applies the same extraction pattern across the rest of `codex-rs/core`
  so the production modules stay focused on runtime code instead of large
  inline test blocks.
  
  Keeping the tests in sibling files also makes follow-up edits easier to
  review because product changes no longer have to share a file with
  hundreds or thousands of lines of test scaffolding.
  
  ## What changed
  - replaced each inline `mod tests { ... }` in `codex-rs/core/src/**`
  with a path-based module declaration
  - moved each extracted unit test module into a sibling `*_tests.rs`
  file, using `mod_tests.rs` for `mod.rs` modules
  - preserved the existing `cfg(...)` guards and module-local structure so
  the refactor remains structural rather than behavioral
  
  ## Testing
  - `cargo test -p codex-core --lib` (`1653 passed; 0 failed; 5 ignored`)
  - `just fix -p codex-core`
  - `cargo fmt --check`
  - `cargo shear`

  Michael Bolin · 2026-03-12 08:16:36 -07:00
  0c8a36676a
• Handle pre-approved permissions in zsh fork (#14431)
  Jack Mousseau · 2026-03-12 00:27:11 -07:00
  19d0949aab
• fix: align core approvals with split sandbox policies (#14171)

  ## Stack
  
     fix: fail closed for unsupported split windows sandboxing #14172
     fix: preserve split filesystem semantics in linux sandbox #14173
  -> fix: align core approvals with split sandbox policies #14171
     refactor: centralize filesystem permissions precedence #14174
  
  ## Why This PR Exists
  
  This PR is intentionally narrower than the title may suggest.
  
  Most of the original split-permissions migration already landed in the
  earlier `#13434 -> #13453` stack. In particular:
  
  - `#13439` already did the broad runtime plumbing for split filesystem
  and network policies.
  - `#13445` already moved `apply_patch` safety onto filesystem-policy
  semantics.
  - `#13448` already switched macOS Seatbelt generation to split policies.
  - `#13449` and `#13453` already handled Linux helper and bubblewrap
  enforcement.
  - `#13440` already introduced the first protocol-side helpers for
  deriving effective filesystem access.
  
  The reason this PR still exists is that after the follow-on
  `[permissions]` work and the new shared precedence helper in `#14174`, a
  few core approval paths were still deciding behavior from the legacy
  `SandboxPolicy` projection instead of the split filesystem policy that
  actually carries the carveouts.
  
  That means this PR is mostly a cleanup and alignment pass over the
  remaining core consumers, not a fresh sandbox backend migration.
  
  ## What Is Actually New Here
  
  - make unmatched-command fallback decisions consult
  `FileSystemSandboxPolicy` instead of only legacy `DangerFullAccess` /
  `ReadOnly` / `WorkspaceWrite` categories
  - thread `file_system_sandbox_policy` into the shell, unified-exec, and
  intercepted-exec approval paths so they all use the same split-policy
  semantics
  - keep `apply_patch` safety on the same effective-access rules as the
  shared protocol helper, rather than letting it drift through
  compatibility projections
  - add loader-level regression coverage proving legacy `sandbox_mode`
  config still builds split policies and round-trips back without semantic
  drift
  
  ## What This PR Does Not Do
  
  This PR does not introduce new platform backend enforcement on its own.
  
  - Linux backend parity remains in `#14173`.
  - Windows fail-closed handling remains in `#14172`.
  - The shared precedence/model changes live in `#14174`.
  
  ## Files To Focus On
  
  - `core/src/exec_policy.rs`: unmatched-command fallback and approval
  rendering now read the split filesystem policy directly
  - `core/src/tools/sandboxing.rs`: default exec-approval requirement keys
  off `FileSystemSandboxPolicy.kind`
  - `core/src/tools/handlers/shell.rs`: shell approval requests now carry
  the split filesystem policy
  - `core/src/unified_exec/process_manager.rs`: unified-exec approval
  requests now carry the split filesystem policy
  - `core/src/tools/runtimes/shell/unix_escalation.rs`: intercepted exec
  fallback now uses the same split-policy approval semantics
  - `core/src/safety.rs`: `apply_patch` safety keeps using effective
  filesystem access rather than legacy sandbox categories
  - `core/src/config/config_tests.rs`: new regression coverage for legacy
  `sandbox_mode` no-drift behavior through the split-policy loader
  
  ## Notes
  
  - `core/src/codex.rs` and `core/src/codex_tests.rs` are just small
  fallout updates for `RequestPermissionsResponse.scope`; they are not the
  point of the PR.
  - If you reviewed the earlier `#13439` / `#13445` stack, the main review
  question here is simply: “are there any remaining approval or
  patch-safety paths that still reconstruct semantics from legacy
  `SandboxPolicy` instead of consuming the split filesystem policy
  directly?”
  
  ## Testing
  - cargo test -p codex-core
  legacy_sandbox_mode_config_builds_split_policies_without_drift
  - cargo test -p codex-core request_permissions
  - cargo test -p codex-core intercepted_exec_policy
  - cargo test -p codex-core
  restricted_sandbox_requires_exec_approval_on_request
  - cargo test -p codex-core
  unmatched_on_request_uses_split_filesystem_policy_for_escalation_prompts
  - cargo test -p codex-core explicit_
  - cargo clippy -p codex-core --tests -- -D warnings

  viyatb-oai · 2026-03-12 02:23:22 +00:00
  c2d5458d67
• Make unified exec session_id numeric (#14279)

  It's a number on the write_stdin input, make it a number on the output
  and also internally.

  pakrym-oai · 2026-03-11 12:33:09 -07:00
  31bf1dbe63
• Fix unified exec test output assertion (#14184)

  ## Summary
  - update the unified exec test to use truncated_output() instead of the
  removed output field
  - fix the compile failure on latest main after ExecCommandToolOutput
  changed shape

  Ahmed Ibrahim · 2026-03-09 23:12:36 -07:00
  6b7253b123
• Implemented thread-level atomic elicitation counter for stopwatch pausing (#12296)

  ### Purpose
  While trying to build out CLI-Tools for the agent to use under skills we
  have found that those tools sometimes need to invoke a user elicitation.
  These elicitations are handled out of band of the codex app-server but
  need to indicate to the exec manager that the command running is not
  going to progress on the usual timeout horizon.
  
  ### Example
  Model calls universal exec:
  `$ download-credit-card-history --start-date 2026-01-19 --end-date
  2026-02-19 > credit_history.jsonl`
  
  download-cred-card-history might hit a hosted/preauthenticated service
  to fetch data. That service might decide that the request requires an
  end user approval the access to the personal data. It should be able to
  signal to the running thread that the command in question is blocked on
  user elicitation. In that case we want the exec to continue, but the
  timeout to not expire on the tool call, essentially freezing time until
  the user approves or rejects the command at which point the tool would
  signal the app-server to decrement the outstanding elicitation count.
  Now timeouts would proceed as normal.
  
  ### What's Added
  
  - New v2 RPC methods:
      - thread/increment_elicitation
      - thread/decrement_elicitation
  - Protocol updates in:
      - codex-rs/app-server-protocol/src/protocol/common.rs
      - codex-rs/app-server-protocol/src/protocol/v2.rs
  - App-server handlers wired in:
      - codex-rs/app-server/src/codex_message_processor.rs
  
  ### Behavior
  
  - Counter starts at 0 per thread.
  - increment atomically increases the counter.
  - decrement atomically decreases the counter; decrement at 0 returns
  invalid request.
  - Transition rules:
  - 0 -> 1: broadcast pause state, pausing all active stopwatches
  immediately.
      - \>0 -> >0: remain paused.
      - 1 -> 0: broadcast unpause state, resuming stopwatches.
  - Core thread/session logic:
      - codex-rs/core/src/codex_thread.rs
      - codex-rs/core/src/codex.rs
      - codex-rs/core/src/mcp_connection_manager.rs
  
  ### Exec-server stopwatch integration
  
  - Added centralized stopwatch tracking/controller:
      - codex-rs/exec-server/src/posix/stopwatch_controller.rs
  - Hooked pause/unpause broadcast handling + stopwatch registration:
      - codex-rs/exec-server/src/posix/mcp.rs
      - codex-rs/exec-server/src/posix/stopwatch.rs
      - codex-rs/exec-server/src/posix.rs

  Channing Conger · 2026-03-09 22:29:26 -07:00
  c6343e0649
• Move exec command truncation into ExecCommandToolOutput (#14169)

  Summary
  - relocate truncation logic for exec command output into the new
  `ExecCommandToolOutput` response helper instead of centralized handler
  code
  - update all affected tools and unified exec handling to use the new
  response item structure and eliminate `Function(FunctionToolOutput)`
  responses
  - adjust context, registry, and handler interfaces to align with the new
  response semantics and error fields
  
  Testing
  - Not run (not requested)

  pakrym-oai · 2026-03-09 22:13:48 -07:00
  a9ae43621b
• Add request permissions tool (#13092)

  Adds a built-in `request_permissions` tool and wires it through the
  Codex core, protocol, and app-server layers so a running turn can ask
  the client for additional permissions instead of relying on a static
  session policy.
  
  The new flow emits a `RequestPermissions` event from core, tracks the
  pending request by call ID, forwards it through app-server v2 as an
  `item/permissions/requestApproval` request, and resumes the tool call
  once the client returns an approved subset of the requested permission
  profile.

  Jack Mousseau · 2026-03-08 20:23:06 -07:00
  e6b93841c5
• sandboxing: plumb split sandbox policies through runtime (#13439)

  ## Why
  
  `#13434` introduces split `FileSystemSandboxPolicy` and
  `NetworkSandboxPolicy`, but the runtime still made most execution-time
  sandbox decisions from the legacy `SandboxPolicy` projection.
  
  That projection loses information about combinations like unrestricted
  filesystem access with restricted network access. In practice, that
  means the runtime can choose the wrong platform sandbox behavior or set
  the wrong network-restriction environment for a command even when config
  has already separated those concerns.
  
  This PR carries the split policies through the runtime so sandbox
  selection, process spawning, and exec handling can consult the policy
  that actually matters.
  
  ## What changed
  
  - threaded `FileSystemSandboxPolicy` and `NetworkSandboxPolicy` through
  `TurnContext`, `ExecRequest`, sandbox attempts, shell escalation state,
  unified exec, and app-server exec overrides
  - updated sandbox selection in `core/src/sandboxing/mod.rs` and
  `core/src/exec.rs` to key off `FileSystemSandboxPolicy.kind` plus
  `NetworkSandboxPolicy`, rather than inferring behavior only from the
  legacy `SandboxPolicy`
  - updated process spawning in `core/src/spawn.rs` and the platform
  wrappers to use `NetworkSandboxPolicy` when deciding whether to set
  `CODEX_SANDBOX_NETWORK_DISABLED`
  - kept additional-permissions handling and legacy `ExternalSandbox`
  compatibility projections aligned with the split policies, including
  explicit user-shell execution and Windows restricted-token routing
  - updated callers across `core`, `app-server`, and `linux-sandbox` to
  pass the split policies explicitly
  
  ## Verification
  
  - added regression coverage in `core/tests/suite/user_shell_cmd.rs` to
  verify `RunUserShellCommand` does not inherit
  `CODEX_SANDBOX_NETWORK_DISABLED` from the active turn
  - added coverage in `core/src/exec.rs` for Windows restricted-token
  sandbox selection when the legacy projection is `ExternalSandbox`
  - updated Linux sandbox coverage in
  `linux-sandbox/tests/suite/landlock.rs` to exercise the split-policy
  exec path
  - verified the current PR state with `just clippy`
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/13439).
  * #13453
  * #13452
  * #13451
  * #13449
  * #13448
  * #13445
  * #13440
  * __->__ #13439
  
  ---------
  
  Co-authored-by: viyatb-oai <viyatb@openai.com>

  Michael Bolin · 2026-03-07 02:30:21 +00:00
  22ac6b9aaa
• utils/pty: add streaming spawn and terminal sizing primitives (#13695)

  Enhance pty utils:
  * Support closing stdin
  * Separate stderr and stdout streams to allow consumers differentiate them
  * Provide compatibility helper to merge both streams back into combined one
  * Support specifying terminal size for pty, including on-demand resizes while process is already running
  * Support terminating the process while still consuming its outputs

  Ruslan Nigmatullin · 2026-03-06 15:13:12 -08:00
  5b04cc657f
• refactor: prepare unified exec for zsh-fork backend (#13392)

  ## Why
  
  `shell_zsh_fork` already provides stronger guarantees around which
  executables receive elevated permissions. To reuse that machinery from
  unified exec without pushing Unix-specific escalation details through
  generic runtime code, the escalation bootstrap and session lifetime
  handling need a cleaner boundary.
  
  That boundary also needs to be safe for long-lived sessions: when an
  intercepted shell session is closed or pruned, any in-flight approval
  workers and any already-approved escalated child they spawned must be
  torn down with the session, and the inherited escalation socket must not
  leak into unrelated subprocesses.
  
  ## What Changed
  
  - Extracted a reusable `EscalationSession` and
  `EscalateServer::start_session(...)` in `shell-escalation` so callers
  can get the wrapper/socket env overlay and keep the escalation server
  alive without immediately running a one-shot command.
  - Documented that `EscalationSession::env()` and
  `ShellCommandExecutor::run(...)` exchange only that env overlay, which
  callers must merge into their own base shell environment.
  - Clarified the prepared-exec helper boundary in `core` by naming the
  new helper APIs around `ExecRequest`, while keeping the legacy
  `execute_env(...)` entrypoints as thin compatibility wrappers for
  existing callers that still use the older naming.
  - Added a small post-spawn hook on the prepared execution path so the
  parent copy of the inheritable escalation socket is closed immediately
  after both the existing one-shot shell-command spawn and the
  unified-exec spawn.
  - Made session teardown explicit with session-scoped cancellation:
  dropping an `EscalationSession` or canceling its parent request now
  stops intercept workers, and the server-spawned escalated child uses
  `kill_on_drop(true)` so teardown cannot orphan an already-approved
  child.
  - Added `UnifiedExecBackendConfig` plumbing through `ToolsConfig`, a
  `shell::zsh_fork_backend` facade, and an opaque unified-exec
  spawn-lifecycle hook so unified exec can prepare a wrapped `zsh -c/-lc`
  request without storing `EscalationSession` directly in generic
  process/runtime code.
  - Kept the existing `shell_command` zsh-fork behavior intact on top of
  the new bootstrap path. Tool selection is unchanged in this PR: when
  `shell_zsh_fork` is enabled, `ShellCommand` still wins over
  `exec_command`.
  
  ## Verification
  
  - `cargo test -p codex-shell-escalation`
    - includes coverage for `start_session_exposes_wrapper_env_overlay`
    - includes coverage for `exec_closes_parent_socket_after_shell_spawn`
  - includes coverage for
  `dropping_session_aborts_intercept_workers_and_kills_spawned_child`
  - `cargo test -p codex-core
  shell_zsh_fork_prefers_shell_command_over_unified_exec`
  - `cargo test -p codex-core --test all
  shell_zsh_fork_prompts_for_skill_script_execution`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/13392).
  * #13432
  * __->__ #13392

  Michael Bolin · 2026-03-05 08:55:12 +00:00
  b4cb989563
• chore: migrate additional permissions to PermissionProfile (#12731)

  This PR replaces the old `additional_permissions.fs_read/fs_write` shape
  with a shared `PermissionProfile`
  model and wires it through the command approval, sandboxing, protocol,
  and TUI layers. The schema is adopted from the
  `SkillManifestPermissions`, which is also refactored to use this unified
  struct. This helps us easily expose permission profiles in app
  server/core as a follow-up.

  Celia Chen · 2026-02-25 03:35:28 +00:00
  16ca527c80
• feat(core) Introduce Feature::RequestPermissions (#11871)

  ## Summary
  Introduces the initial implementation of Feature::RequestPermissions.
  RequestPermissions allows the model to request that a command be run
  inside the sandbox, with additional permissions, like writing to a
  specific folder. Eventually this will include other rules as well, and
  the ability to persist these permissions, but this PR is already quite
  large - let's get the core flow working and go from there!
  
  <img width="1279" height="541" alt="Screenshot 2026-02-15 at 2 26 22 PM"
  src="https://github.com/user-attachments/assets/0ee3ec0f-02ec-4509-91a2-809ac80be368"
  />
  
  ## Testing
  - [x] Added tests
  - [x] Tested locally
  - [x] Feature

  Dylan Hurd · 2026-02-24 09:48:57 -08:00
  f6053fdfb3
• Use Arc-based ToolCtx in tool runtimes (#12583)

  ## Why
  Tool handlers and runtimes needed to pass the same turn/session context
  for shell and non-shell workflows without duplicative ownership churn.
  Using shared pointers avoids temporary lifetimes and keeps existing
  behavior unchanged while simplifying call sites.
  
  ## What changed
  - Converted `ToolCtx` to store shared context handles (`Arc`-based),
  including updates across shell, apply-patch, and unified-exec paths.
  - Updated orchestrator/runtime call sites to consume the shared context
  consistently and remove brittle move/borrow patterns.
  - Kept behavior unchanged while preparing the type surface for the new
  shell escalation integration in the next stack commit.
  
  ## Verification
  - Validated this commit stack point with `just clippy` and confirmed
  workspace compiles cleanly in this stack state.
  
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/12583).
  * #12584
  * __->__ #12583
  * #12556

  Michael Bolin · 2026-02-23 18:29:26 +00:00
  7f75e74201
• core: preserve constrained approval/sandbox policies in TurnContext (#12473)
  Michael Bolin · 2026-02-21 14:40:24 -08:00
  66d5d34e6e
• Refactor network approvals to host/protocol/port scope (#12140)

  ## Summary
  Simplify network approvals by removing per-attempt proxy correlation and
  moving to session-level approval dedupe keyed by (host, protocol, port).
  Instead of encoding attempt IDs into proxy credentials/URLs, we now
  treat approvals as a destination policy decision.
  
  - Concurrent calls to the same destination share one approval prompt.
  - Different destinations (or same host on different ports) get separate
  prompts.
  - Allow once approves the current queued request group only.
  - Allow for session caches that (host, protocol, port) and auto-allows
  future matching requests.
  - Never policy continues to deny without prompting.
  
  Example:
  - 3 calls: 
    - a.com (line 443)
    - b.com (line 443)
    - a.com (line 443)
  => 2 prompts total (a, b), second a waits on the first decision.
  - a.com:80 is treated separately from a.com line 443
  
  ## Testing
  - `just fmt` (in `codex-rs`)
  - `cargo test -p codex-core tools::network_approval::tests`
  - `cargo test -p codex-core` (unit tests pass; existing
  integration-suite failures remain in this environment)

  viyatb-oai · 2026-02-20 10:39:55 -08:00
  e8afaed502
• Revert "feat: no timeout mode on ue" (#12256)

  Reverts openai/codex#12250

  jif-oai · 2026-02-19 19:02:29 +00:00
  928be5f515
• feat: no timeout mode on ue (#12250)
  jif-oai · 2026-02-19 18:58:13 +00:00
  9719dc502c
• feat: add configurable write_stdin timeout (#12228)

  Add max timeout as config for `write_stdin`. This is only used for empty
  `write_stdin`.
  
  Also increased the default value from 30s to 5mins.

  jif-oai · 2026-02-19 17:22:13 +00:00
  547f462385
• feat: use shell policy in shell snapshot (#11759)

  Honor `shell_environment_policy.set` even after a shell snapshot

  jif-oai · 2026-02-16 09:11:00 +00:00
  825a4af42f
• feat(core): add structured network approval plumbing and policy decision model (#11672)

  ### Description
  #### Summary
  Introduces the core plumbing required for structured network approvals
  
  #### What changed
  - Added structured network policy decision modeling in core.
  - Added approval payload/context types needed for network approval
  semantics.
  - Wired shell/unified-exec runtime plumbing to consume structured
  decisions.
  - Updated related core error/event surfaces for structured handling.
  - Updated protocol plumbing used by core approval flow.
  - Included small CLI debug sandbox compatibility updates needed by this
  layer.
  
  #### Why
  establishes the minimal backend foundation for network approvals without
  yet changing high-level orchestration or TUI behavior.
  
  #### Notes
  - Behavior remains constrained by existing requirements/config gating.
  - Follow-up PRs in the stack handle orchestration, UX, and app-server
  integration.
  
  ---------
  
  Co-authored-by: Codex <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com>

  viyatb-oai · 2026-02-14 04:18:12 +00:00
  b527ee2890
• Remove test-support feature from codex-core and replace it with explicit test toggles (#11405)

  ## Why
  
  `codex-core` was being built in multiple feature-resolved permutations
  because test-only behavior was modeled as crate features. For a large
  crate, those permutations increase compile cost and reduce cache reuse.
  
  ## Net Change
  
  - Removed the `test-support` crate feature and related feature wiring so
  `codex-core` no longer needs separate feature shapes for test consumers.
  - Standardized cross-crate test-only access behind
  `codex_core::test_support`.
  - External test code now imports helpers from
  `codex_core::test_support`.
  - Underlying implementation hooks are kept internal (`pub(crate)`)
  instead of broadly public.
  
  ## Outcome
  
  - Fewer `codex-core` build permutations.
  - Better incremental cache reuse across test targets.
  - No intended production behavior change.

  Michael Bolin · 2026-02-10 22:44:02 -08:00
  476c1a7160
• Remove deterministic_process_ids feature to avoid duplicate codex-core builds (#11393)

  ## Why
  
  `codex-core` enabled `deterministic_process_ids` through a self
  dev-dependency.
  That forced a second feature-resolved build of the same crate, which
  increased
  compile time and test latency.
  
  ## What Changed
  
  - Removed the `deterministic_process_ids` feature from
  `codex-rs/core/Cargo.toml`.
  - Removed the self dev-dependency on `codex-core` that enabled that
  feature.
  - Removed the Bazel `deterministic_process_ids` crate feature for
  `codex-core`.
  - Added a test-only `AtomicBool` override in unified exec process-id
  allocation.
  - Added a test-support setter for that override and re-exported it from
  `codex-core`.
  - Enabled deterministic process IDs in integration tests via
  `core_test_support` ctor.
  
  ## Behavior
  
  - Production behavior remains random process IDs.
  - Unit tests remain deterministic via `cfg(test)`.
  - Integration tests remain deterministic via explicit test-support
  initialization.
  
  ## Validation
  
  - `just fmt`
  - `cargo test -p codex-core unified_exec::`
  - `cargo test -p codex-core --test all unified_exec -- --test-threads=1`
  - `cargo tree -p codex-core -e features` (verified the removed feature
  path)

  Michael Bolin · 2026-02-10 19:07:01 -08:00
  b68a84ee8e
• feat(sandbox): enforce proxy-aware network routing in sandbox (#11113)

  ## Summary
  - expand proxy env injection to cover common tool env vars
  (`HTTP_PROXY`/`HTTPS_PROXY`/`ALL_PROXY`/`NO_PROXY` families +
  tool-specific variants)
  - harden macOS Seatbelt network policy generation to route through
  inferred loopback proxy endpoints and fail closed when proxy env is
  malformed
  - thread proxy-aware Linux sandbox flags and add minimal bwrap netns
  isolation hook for restricted non-proxy runs
  - add/refresh tests for proxy env wiring, Seatbelt policy generation,
  and Linux sandbox argument wiring

  viyatb-oai · 2026-02-10 07:44:21 +00:00
  3391e5ea86
• feat: use a notify instead of grace to close ue process (#11219)
  jif-oai · 2026-02-09 22:14:33 +00:00
  c2ca51273f
• feat: include NetworkConfig through ExecParams (#11105)

  This PR adds the following field to `Config`:
  
  ```rust
  pub network: Option<NetworkProxy>,
  ```
  
  Though for the moment, it will always be initialized as `None` (this
  will be addressed in a subsequent PR).
  
  This PR does the work to thread `network` through to `execute_exec_env()`, `process_exec_tool_call()`, and `UnifiedExecRuntime.run()` to ensure it is available whenever we span a process.

  Michael Bolin · 2026-02-09 03:32:17 +00:00
  383b45279e
• Removed "exec_policy" feature flag (#10851)

  This is no longer needed because it's on by default

  Eric Traut · 2026-02-06 08:59:47 -08:00
  4521a6e852
• Inject CODEX_THREAD_ID into the terminal environment (#10096)

  Inject CODEX_THREAD_ID (when applicable) into the terminal environment
  so that the agent (and skills) can refer to the current thread / session
  ID.
  
  Discussion:
  https://openai.slack.com/archives/C095U48JNL9/p1769542492067109

  Max Johnson · 2026-02-03 11:31:12 -08:00
  66b196a725
• feat(core) RequestRule (#9489)

  ## Summary
  Instead of trying to derive the prefix_rule for a command mechanically,
  let's let the model decide for us.
  
  ## Testing
  - [x] tested locally

  Dylan Hurd · 2026-01-28 08:43:17 +00:00
  996e09ca24
• fix unified_exec::tests::unified_exec_timeouts to use a more unique match value (#9414)

  Fix unified_exec_timeouts to use a unique variable value rather than
  "codex" which was causing false positives when running tests locally
  (presumably from my bash prompts). Discovered while running tests to
  validate another change.
  
  Fixes https://github.com/openai/codex/issues/9413
  
  Test Plan:
  
  Ran test locally on my fedora 43 x86_64 machine with:
  ```
  cd codex/cargo-rs
  cargo nextest run --all-features --no-fail-fast unified_exec::tests::unified_exec_timeouts
  ```
  
  Before, unified_exec_timeouts fails:
  ```
      Finished `test` profile [unoptimized + debuginfo] target(s) in 0.38s
  ────────────
   Nextest run ID fa2b4949-a66c-408c-8002-32c52c70ec4f with nextest profile: default
      Starting 1 test across 107 binaries (3211 tests skipped)
          FAIL [   5.667s] codex-core unified_exec::tests::unified_exec_timeouts
    stdout ───
  
      running 1 test
      test unified_exec::tests::unified_exec_timeouts ... FAILED
  
      failures:
  
      failures:
          unified_exec::tests::unified_exec_timeouts
  
      test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 774 filtered out; finished in 5.66s
  
    stderr ───
  
      thread 'unified_exec::tests::unified_exec_timeouts' (459601) panicked at core/src/unified_exec/mod.rs:381:9:
      timeout too short should yield incomplete output
      note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
  
  ────────────
       Summary [   5.677s] 1 test run: 0 passed, 1 failed, 3211 skipped
          FAIL [   5.667s] codex-core unified_exec::tests::unified_exec_timeouts
  error: test run failed
  
  ```
  
  After, works:
  ```
      Finished `test` profile [unoptimized + debuginfo] target(s) in 0.34s
  ────────────
   Nextest run ID f49e9004-e30b-4049-b0ff-283b543a1cd7 with nextest profile: default
      Starting 1 test across 107 binaries (3211 tests skipped)
          SLOW [> 15.000s] codex-core unified_exec::tests::unified_exec_timeouts
          PASS [  17.666s] codex-core unified_exec::tests::unified_exec_timeouts
  ────────────
       Summary [  17.676s] 1 test run: 1 passed (1 slow), 3211 skipped
  ```

  Alex Hornby · 2026-01-17 09:05:53 -08:00
  b877a2041e
• chore: close pipe on non-pty processes (#9369)

  Closing the STDIN of piped process when starting them to avoid commands
  like `rg` to wait for content on STDIN and hangs for ever

  jif-oai · 2026-01-16 15:54:32 +01:00
  1668ca726f
• feat: CODEX_CI (#9366)
  jif-oai · 2026-01-16 13:52:16 +00:00
  7fc49697dd
• feat: adding piped process to replace PTY when needed (#8797)
  jif-oai · 2026-01-14 18:44:04 +00:00
  577e1fd1b2
• chore: clamp min yield time for empty write_stdin (#9156)

  After evals, 0 impact on performance

  jif-oai · 2026-01-14 16:25:40 +00:00
  32b1795ff4
• fix: drop double waiting header in TUI (#9145)
  jif-oai · 2026-01-14 09:52:34 +00:00
  7532f34699
• chore: rename unified exec sessions (#8822)

  Renaming done by Codex

  jif-oai · 2026-01-07 16:12:47 +00:00
  4cef89a122
• feat: add head-tail buffer for unified_exec (#8735)
  jif-oai · 2026-01-06 15:48:44 +00:00
  32db8ea5ca
• chore: emit unified exec begin only when PTY exist (#8780)
  jif-oai · 2026-01-06 13:12:54 +00:00
  8858012fd1
• chore: GH pager (#8747)
  jif-oai · 2026-01-05 18:40:34 +00:00
  fabb797097
• fix: limit output size for exec command in unified exec (#8460)

  ### Issue
  [Investigation
  thread](https://openai.slack.com/archives/C095U48JNL9/p1766426234975789)
  
  Github issue: [issue one](https://github.com/openai/codex/issues/8197),
  [issue two](https://github.com/openai/codex/issues/8358), [issue
  three](https://github.com/openai/codex/issues/7585)
  Commonality: working in monorepo and large projects. Multiple threads
  going and showing sluggishness ending with a crash and grey background.
  Potential high usage of context.
  How to reproduce:
  * Open the whole monorepo with cursor or VSC on the latest extension.
  * Run ls -R in current CWD.
  
  ### Change
  In unified exec, we do not have max output check to the delta we ouput
  for shell commands. This causes issue with our VSCE UI which take the
  delta and construct the shell output.

  Shijie Rao · 2025-12-23 14:36:15 -08:00
  fb24c47bea