93 Commits

• [codex] consume pushed exec-server process events (#30273)

  ## Summary
  
  - complete unified-exec processes from the ordered event stream instead
  of issuing a final zero-wait `process/read`
  - add optional executor sandbox-denial state to `process/exited`
  - retain `process/read` as a retained-output and compatibility fallback
  for receiver lag, sequence gaps, and legacy servers
  - recover sandbox-denial state across transport reconnection
  - cover the real `TestCodex` remote-exec path without adding a public
  test-only event constructor
  
  ## Why
  
  A successful one-shot tool call currently receives its output and
  terminal notifications, then pays another wide-area `process/read` round
  trip before returning. Staging traces showed that remote response wait
  accounted for more than 99.8% of RPC time; local serialization,
  queueing, and deserialization were below 0.6 ms.
  
  ## Measured impact
  
  A direct staging A/B used the same build and route and changed only
  completion mode. Each arm ran three times with 30 one-shot
  `/usr/bin/true` calls per run. The table reports the median of the three
  per-run percentiles.
  
  | Metric | Final `process/read` | Pushed events | Change |
  | --- | ---: | ---: | ---: |
  | End-to-end completion p50 | 159.5 ms | 118.7 ms | -40.8 ms (-25.6%) |
  | End-to-end completion p95 | 182.4 ms | 131.7 ms | -50.6 ms (-27.8%) |
  | Completion-wait p50 | 80.1 ms | 41.5 ms | -38.5 ms (-48.1%) |
  | Final `process/read` RPC p50 | 79.9 ms | eliminated | -79.9 ms |
  
  TCP_NODELAY was enabled in both A/B arms, so its effect cancels out. The
  successful, complete, in-order event path issued zero final
  `process/read` calls.
  
  ## Compatibility and recovery
  
  - new servers send `sandboxDenied` on `process/exited`
  - legacy servers omit it, which triggers one compatibility
  `process/read`
  - broadcast lag or a sequence gap triggers a retained-output read
  - recovery remains bounded by the server's existing 1 MiB
  retained-output window
  - complete, in-order event streams issue no completion read
  - sandbox denial is attached to the exit event before consumers can
  observe process completion
  - server-first and client-first rollouts remain wire-compatible;
  server-first realizes the latency win immediately
  
  ## Integration coverage
  
  The `TestCodex` suite exercises four distinct remote-exec contracts:
  
  - complete pushed output/exit/close with zero reads
  - direct pushed sandbox denial with zero reads
  - legacy missing denial metadata with exactly one compatibility read
  - count-bounded replay eviction recovered from retained output without
  duplication
  
  ## Validation
  
  - `just test -p codex-core
  exec_command_consumes_pushed_remote_process_events`: 4 passed
  - `just test -p codex-core unified_exec::process_tests::`: 4 passed
  - `just test -p codex-exec-server`: 294 passed, 2 skipped
  - `just test -p codex-exec-server-protocol`: 5 passed
  - `just test -p codex-rmcp-client`: 89 passed, 2 skipped
  - focused Bazel `//codex-rs/core:core-all-test`: passed across 16 shards
  - scoped `just fix` passed for core and exec-server
  - `just fmt` passed
  
  The complete workspace suite was not rerun; focused Cargo and Bazel
  coverage passed for the changed behavior.

  richardopenai · 2026-06-26 18:05:52 -07:00
  d4ec08b8f0
• Persist Cloudflare affinity cookies for MCP HTTP (#29516)

  [Codex Thread
  019ef1f9-36e2-7e91-9337-504f097b9dc1](https://codex-thread-link.openai.chatgpt-team.site/thread/019ef1f9-36e2-7e91-9337-504f097b9dc1)
  
  ## Why
  
  Hosted plugin-service Streamable HTTP MCP traffic uses
  `https://chatgpt.com/backend-api/ps/mcp` and depends on Cloudflare's
  `__cflb` cookie for load-balancer affinity. The local and exec-server
  `http/request` path built a fresh reqwest client for each request
  without installing Codex's existing shared ChatGPT Cloudflare cookie
  store, so affinity could be lost between calls.
  
  This is an affinity-hardening change motivated by an incident
  investigation. It does not establish the broader connector-cache
  incident RCA or claim to fix that incident in full.
  
  ## What changed
  
  - Install the existing process-local, strictly allowlisted ChatGPT
  Cloudflare cookie store on the reqwest client used by
  `ReqwestHttpClient`.
  - Fresh clients now share allowed Cloudflare infrastructure cookies
  within the process that originates the local or exec-server network
  request.
  - Keep the existing HTTPS ChatGPT-host and Cloudflare-cookie-name
  restrictions. This does not introduce a general cookie jar or send
  ChatGPT Cloudflare cookies to unrelated hosts.
  
  ## Test coverage
  
  - `codex-client` unit coverage verifies that the existing strict store
  accepts and returns `__cflb` for HTTPS ChatGPT URLs.
  - The exec-server HTTPS integration test sends four independent
  `http/request` calls through a local TLS-intercepting proxy and verifies
  that:
  - `Set-Cookie: __cflb=west` is sent on the next plugin-service request;
    - a later `Set-Cookie: __cflb=central` replaces the stored value;
    - non-Cloudflare session cookies are discarded;
    - no stored ChatGPT Cloudflare cookie is sent to a non-ChatGPT host.
  - `just test -p codex-client` — 38 passed.
  - `just test -p codex-exec-server --test chatgpt_cloudflare_affinity` —
  1 passed.
  - `just bazel-lock-check` — passed.
  
  ## Non-goals
  
  - No persistence of ChatGPT auth, account, session, residency, or
  arbitrary cookies.
  - No cookie persistence for third-party MCP servers.
  - No special composition of caller-provided `Cookie` headers.
  - No plugin-service, connector-cache, Habitat/habicache, routing,
  redirect, or API-contract changes.
  - No broader incident RCA conclusions.

  stevenlee-oai · 2026-06-26 02:23:24 -04:00
  b5866eebd6
• Persist selected capability roots and resolve availability per model step (#29856)

  ## Why
  
  `selectedCapabilityRoots` is durable thread intent: “use this capability
  root from environment `worker`.”
  
  The important product assumption is:
  
  > One environment ID always names the same logical executor and stable
  contents.
  
  `worker` does not silently change from executor A to an unrelated
  executor B. The process-local connection handle for `worker` can still
  be replaced while Codex is running, though, for example when
  `environment/add` registers a fresh handle for the same logical
  environment.
  
  The thread should persist only the stable selection. Each model step
  should pair that selection with the exact ready handle captured for that
  step.
  
  ## The boundary
  
  ```text
  persisted thread intent
    plugin@1 -> environment "worker"
                  |
                  | capture the current step
                  v
  model-step view
    unavailable, or
    plugin@1 + worker's exact captured ready handle
  ```
  
  The environment ID is the stable identity and cache key. The
  `Arc<Environment>` is only a process-local handle retained so consumers
  of one model step use the same captured environment. It is never
  persisted and it does not imply different environment contents.
  
  ## What changes
  
  ### Persist the stable selection
  
  Selected roots are written into `SessionMeta` and restored with the
  thread. Forked subagents inherit the same selections, including
  bounded-history forks.
  
  Only stable data is persisted: root ID, environment ID, and root path.
  
  ### Capture readiness together with the exact handle
  
  The environment snapshot records:
  
  ```rust
  environment_id -> Some(Arc<Environment>) // ready in this step
  environment_id -> None                   // still starting in this step
  ```
  
  This prevents readiness and execution from coming from different
  registry snapshots.
  
  For example:
  
  ```text
  step snapshot: worker -> handle A, ready
  environment/add: worker -> fresh handle B for the same logical environment
  current step: plugin@1 still uses captured handle A
  ```
  
  Without carrying handle A in the snapshot, the resolver could combine “A
  was ready” with handle B and treat B as ready before it had finished
  starting.
  
  This does not change cache invalidation. Stable capability metadata
  remains identified by environment ID and capability root. Replacing a
  process-local handle under the same stable environment ID does not
  invalidate or rediscover that metadata.
  
  ### Resolve availability per model step
  
  - A ready captured environment produces resolved roots using its
  captured handle.
  - A starting, missing, or failed environment is omitted from that step.
  - A selected lazy environment that is outside the turn's captured
  environment set is asked to start, and a later step can observe it as
  ready.
  - No capability files are scanned here.
  
  Transient transport disconnects remain the remote client's reconnect
  concern. This PR models initial attachment/readiness; it does not add
  live socket-connectivity state.
  
  ## Example
  
  ```text
  thread selection: plugin@1 -> environment "worker"
  
  step 1: worker is starting -> plugin@1 unavailable
  step 2: worker is ready    -> plugin@1 resolves through worker's captured handle
  step 3: fresh local handle -> current step remains pinned; a later step captures its own view
  ```
  
  Temporary unavailability does not discard the durable selection. Later
  PRs can retain stable metadata caches while projecting only currently
  available capabilities into model-visible World State.
  
  ## Compatibility
  
  The app-server request shape does not change. Older rollouts without
  `selected_capability_roots` deserialize to an empty list.
  
  ## Stack
  
  1. **This PR:** persist stable selected roots and resolve them through
  an exact model-step handle.
  2. #29960: cache stable skill metadata and project available skills into
  World State.
  3. #29946: cache stable plugin declarations and manage the separate live
  MCP runtime.

  jif · 2026-06-25 17:49:43 +00:00
  8f02973d25
• Support OAuth for HTTP MCP servers from selected executor plugins (#28529)

  ## Why
  
  #28522 routes selected-plugin HTTP MCP traffic through the owning
  executor, but OAuth bootstrap and refresh still used host-local clients.
  Executor-only servers therefore cannot complete discovery or login
  through the same network boundary as the MCP connection.
  
  ## What changed
  
  - adapt `codex_exec_server::HttpClient` to RMCP 1.8's `OAuthHttpClient`
  contract
  - let RMCP own discovery, dynamic registration, PKCE, token exchange,
  and refresh
  - route auth status, persisted-token startup, and app-server login
  through the server runtime while preserving the existing local discovery
  path
  - add optional `threadId` to `mcpServer/oauth/login` and echo it in the
  completion notification
  - implement RMCP's redirect policy and 1 MiB OAuth response limit over
  executor HTTP
  - cover selected-thread OAuth discovery and login through an
  executor-only route
  
  Depends on #28522.

  jif · 2026-06-25 10:31:17 +01:00
  b215961a56
• Follow directory symlinks in filesystem walks (#29844)

  Stack 3 of 3. Stacked on #29842.
  
  ## What changes
  
  Adds an opt-in `followDirectorySymlinks` setting to `fs/walk`.
  
  When enabled, the walk follows directory symlinks but continues to
  ignore symlinked files. Canonical directory identities prevent symlink
  cycles, while normal paths keep their existing spelling.
  
  Environment skill discovery enables the setting so symlinked skill
  directories continue to work with the new single-RPC scan.

  jif · 2026-06-24 20:52:36 +01:00
  96d8e34712
• [codex] Trace exec-server JSON-RPC requests (#27466)

  ## Why
  
  Exec-server JSON-RPC calls can cross local and remote transports, but
  trace context stopped at the RPC boundary. That made client and server
  work difficult to correlate when diagnosing latency or failures.
  
  ## What changed
  
  - Propagate the current W3C trace context on outbound JSON-RPC requests.
  - Parent inbound request spans from received trace context.
  - Record the received JSON-RPC method on server spans and keep each span
  open through response enqueue.
  - Add only the OTEL dependencies required by the exec-server crate.
  
  ## Stack
  
  Review and land this stack in order:
  
  1. #27466 — trace exec-server JSON-RPC requests **(this PR)**
  2. #27467 — record bounded connection, request, and process lifecycle
  metrics
  3. #27470 — observe remote registration and Noise rendezvous lifecycle
  
  ## Validation
  
  - `just test -p codex-exec-server --lib` (153 passed)
  - `just bazel-lock-check`
  - `just fix -p codex-exec-server`

  richardopenai · 2026-06-24 12:50:18 -07:00
  74dcce594d
• Add a bounded filesystem walk RPC (#29841)

  Stack 1 of 3. Follow-ups: #29842 and #29844.
  
  ## What changes
  
  Adds a general bounded `fs/walk` operation to the exec server.
  
  The operation returns file and directory entries plus recoverable
  per-path errors. It skips symlinks, preserves the existing filesystem
  sandbox routing, and enforces depth, directory, entry, and response-size
  limits.
  
  This PR only defines and wires the filesystem operation. It does not
  change any callers yet.

  jif · 2026-06-24 16:05:43 +01:00
  c14623d04c
• protocol: separate app and exec RPC ownership (#29714)

  ## Why
  
  The app-server and exec-server expose separate JSON-RPC APIs, but
  exec-server currently sources its serialized protocol and envelope types
  through app-server-oriented code. Giving each API an explicit owner
  makes the crate boundary legible without introducing shared generic
  envelopes.
  
  ## What changed
  
  - Added `codex-exec-server-protocol` to own exec DTOs, process IDs, and
  JSON-RPC envelopes.
  - Updated exec-server clients, transports, handlers, and tests to use
  the new crate.
  - Exposed app-server's existing JSON-RPC types through a public `rpc`
  module while retaining root re-exports.
  - Preserved existing wire shapes, including exec `PathUri` behavior.
  
  ## Stack
  
  This is PR 1 of 6. Next: [PR
  #29721](https://github.com/openai/codex/pull/29721), which moves auth
  mode below the app wire boundary.
  
  ## Validation
  
  - Exec-server protocol and server coverage passed in the focused
  protocol test runs.
  - App-server protocol schema fixtures passed.

  Adam Perry @ OpenAI · 2026-06-23 22:37:31 +00:00
  829f5b6b59
• path-uri: remove legacy path deserialization (#29158)

  ## Why
  
  I'd originally added `PathUri` legacy path deserialization thinking we'd
  want it for having `PathUri` in public app-server APIs. Since then we've
  added `LegacyAppPathString` to handle the messy conversions that we need
  for backcompat. It's confusing for `PathUri` to support deserializing
  legacy paths when we don't yet want to actually expose app-server
  callers or rollout storage to the new URI format.
  
  Stacked on top of #29472 to avoid breaking compatibility in case those
  types ended up stored somewhere for someone.
  
  ## What changed
  
  - Parse deserialized `PathUri` values exclusively as valid `file:` URIs.
  - Replace legacy acceptance coverage with rejection coverage for
  top-level filesystem paths and sandbox working directories.
  - Serialize CWDs in hand-built exec-server process requests as `PathUri`
  values.

  Adam Perry @ OpenAI · 2026-06-23 21:47:00 +00:00
  c26f961b85
• Prepare managed network sandbox context (#29456)

  ## Why
  
  Managed network configures commands to use local HTTP and SOCKS proxies.
  For commands delegated to the exec server, the proxy environment and the
  sandbox policy were prepared separately. On macOS, that meant a command
  could receive `HTTPS_PROXY=http://127.0.0.1:43123` while Seatbelt still
  denied access to port `43123`.
  
  ## What changed
  
  `NetworkProxy` now prepares the command environment and sandbox context
  together from the same runtime snapshot:
  
  ```text
  Prepared managed network
  ├── command environment: HTTPS_PROXY=http://127.0.0.1:43123
  └── sandbox context: allow outbound to 127.0.0.1:43123
  ```
  
  That context travels with remote exec requests. The exec server
  preserves the managed proxy and CA environment, and macOS Seatbelt
  allows only the prepared loopback proxy ports without enabling broad
  network access or local binding.
  
  The protocol field is optional and the existing enforcement flag remains
  in place, preserving compatibility with callers that do not send the new
  context.

  jif · 2026-06-23 20:07:09 +01:00
  e476fc16ce
• path-uri: clarify host-native path conversion (#29501)

  ## Why
  
  Downstream refactors are producing confusing code with this
  functionality having a very generic name. Encoding the specific
  conversion approach in the method name makes it clearer.
  
  ## What
  
  Rename `PathUri::from_path` to `PathUri::from_host_native_path` and
  update its Rust call sites.

  Adam Perry @ OpenAI · 2026-06-23 00:02:33 +00:00
  11fab432be
• Report remote sandbox denials semantically (#29424)

  ## Why
  
  #29113 moved remote sandbox setup and enforcement to the exec server.
  That gives the executor ownership of the platform-specific work: a Linux
  executor chooses and runs a Linux sandbox even when the Codex
  orchestrator is running on macOS or Windows.
  
  It also means the orchestrator no longer knows which concrete sandbox
  the executor selected. When that sandbox blocks a remote command, the
  orchestrator currently sees only a failed process and can treat the
  denial as an ordinary command failure. The existing sandbox approval and
  retry path is then skipped.
  
  This PR lets the executor report one portable fact:
  
  > This command probably failed because the executor sandbox blocked it.
  
  The executor keeps its concrete sandbox type private. The protocol sends
  only the semantic result.
  
  ## Example
  
  Suppose a local macOS Codex session asks a Linux devbox to write outside
  the allowed workspace.
  
  Before this PR:
  
  ```text
  Linux sandbox blocks the write
      -> remote process exits with "Permission denied"
      -> local orchestrator sees an ordinary command failure
      -> the normal sandbox approval and retry path can be skipped
  ```
  
  With this PR:
  
  ```text
  Linux sandbox blocks the write
      -> executor reports sandboxDenied: true
      -> unified exec returns UnifiedExecError::SandboxDenied
      -> the existing approval prompt is shown
      -> an approved retry runs through the existing unsandboxed retry path
  ```
  
  ## What changes
  
  ### The executor remembers its selected sandbox
  
  The prepared remote process now retains the executor-selected
  `SandboxType`. This value never crosses the executor boundary.
  
  Commands started without a sandbox retain `SandboxType::None` and are
  never reported as sandbox denials.
  
  ### The executor uses the existing denial heuristic
  
  The existing local denial heuristic moves from `codex-core` into the
  shared `codex-sandboxing` crate.
  
  When a sandboxed remote process exits, the executor:
  
  1. waits the same short output grace period used by local unified exec;
  2. reads the output currently available in the existing retained output
  buffer;
  3. runs the existing heuristic using the exit code and common denial
  messages;
  4. stores the yes/no result before publishing the process exit.
  
  This deliberately matches the old local unified-exec behavior. It does
  not add a new streaming classifier, another output buffer, or stronger
  output-retention guarantees.
  
  ### The protocol reports a portable boolean
  
  `process/read` gains `sandboxDenied`:
  
  ```json
  {
    "exited": true,
    "exitCode": 1,
    "closed": false,
    "sandboxDenied": true
  }
  ```
  
  The field defaults to `false` when an older executor omits it. The
  response does not expose the executor sandbox implementation or
  executor-native paths.
  
  ### Unified exec uses the existing error path
  
  The exec-server client carries `sandboxDenied` into the unified process
  state. If it is true, unified exec returns the existing `SandboxDenied`
  error instead of trying to classify remote output using an
  orchestrator-side sandbox type.
  
  Remote process exit remains visible as soon as the process exits. This
  PR does not wait for stdout or stderr to close and does not change the
  existing process lifecycle.
  
  ## Scope
  
  This PR is intentionally limited to matching the existing local
  unified-exec behavior for the initial command execution path.
  
  It does not add:
  
  - incremental denial tracking across the full output stream;
  - new denial handling for commands completed later through
  `write_stdin`;
  - new guarantees for preserving the semantic flag during the narrow
  reconnect-recovery race.
  
  Those can be considered separately if the same behavior is added for
  local execution.
  
  ## Test coverage
  
  One remote end-to-end integration test covers the complete intended
  flow:
  
  ```text
  remote read-only sandbox
      -> denied write
      -> executor reports the denial
      -> Codex requests approval
      -> user approves
      -> retry succeeds on the remote executor
  ```
  
  Existing lifecycle coverage continues to verify that remote process exit
  is reported before late output streams close.

  jif · 2026-06-22 19:33:28 +02:00
  9f06cf1a09
• Carry sandbox intent to remote exec servers (#29108)

  ## What changed
  
  PR #29099 stopped sending the orchestrator's concrete sandbox wrapper to
  a remote exec-server. Remote commands now arrive as plain native argv.
  
  This PR adds the next piece: Codex also sends portable sandbox intent
  next to that plain argv.
  
  For a remote unified-exec command, the request can now include:
  
  - the canonical permission profile before local workspace-root
  materialization
  - the sandbox cwd and workspace roots as `PathUri` values
  - Windows sandbox settings
  - the legacy Landlock setting
  - whether managed networking must be enforced
  
  The important part is that symbolic entries such as `:workspace_roots`
  stay symbolic while crossing the boundary. The executor can then bind
  them to its own workspace-root paths instead of receiving
  orchestrator-local absolute paths.
  
  The data travels through `ExecRequest` into `ExecParams`. Older
  exec-servers can still deserialize requests because the new fields have
  defaults.
  
  ## Why
  
  The orchestrator should not decide how another machine implements
  sandboxing.
  
  For example:
  
  - a local macOS Codex would normally build a Seatbelt command
  - a remote Linux executor needs a Linux sandbox command instead
  
  The orchestrator now sends the plain command plus the policy it intended
  to enforce. A later PR can let the exec-server choose and build the
  correct sandbox for its own operating system.
  
  ## Important detail
  
  This keeps the portable intent separate from the local `SandboxType`.
  
  `SandboxType::None` is ambiguous:
  
  - it can mean the command was explicitly approved to run without a
  sandbox
  - it can also mean the orchestrator host has no concrete sandbox
  implementation available
  
  Those cases are different for remote execution. This PR adds
  `sandbox_requested` so an executor can still receive sandbox intent when
  the orchestrator cannot build a local wrapper. Explicit unsandboxed
  retries still send no sandbox context.
  
  ## Behavior today
  
  This PR only transports the intent. The exec-server accepts the new
  fields but does not apply them yet.
  
  Remote commands therefore remain unsandboxed after this PR, just as they
  are after PR #29099.
  
  ## Follow-up
  
  The next PR will make exec-server read this portable intent, bind
  symbolic workspace permissions to executor-native roots, choose the
  sandbox for its own operating system, build the wrapper locally, and
  then spawn the command.

  jif · 2026-06-21 12:33:21 +02:00
  bd2968a4db
• [1/3] core: add remote environment connection lifecycle (#28674)

  ## Why
  
  Remote environments can be registered before their exec-server is first
  used. Starting the connection at registration time uses that startup
  window, while sharing one startup result prevents background work and
  capability calls from opening competing connections.
  
  Keep initial startup simple: each environment makes one connection
  attempt using its configured transport timeout. A failed initial attempt
  is final for that environment, while an environment that disconnects
  after connecting can still recover on a later operation.
  
  ## What changed
  
  - Start URL and Noise environments in the background when they are added
  to `EnvironmentManager`. Provider snapshots are fully validated before
  connection work begins.
  - Share one initial connection attempt and its saved result across
  metadata, process, filesystem, and HTTP callers.
  - Keep configured stdio environments lazy until first use so
  registration does not launch a process.
  - Tie background startup work to the environment lifetime so replacing
  or dropping an environment cancels unfinished work.
  - After an established client disconnects, share one fresh connection
  attempt across concurrent callers. A failed attempt fails the current
  operation without permanently preventing a later attempt.
  - Store the shared lazy client directly on `Environment` and expose
  small methods for starting, observing, and awaiting startup.
  
  ## Test plan
  
  - `just test -p codex-exec-server`
  - `just test -p codex-app-server
  turn_start_resolves_sticky_thread_local_environment_and_turn_overrides`

  sayan-oai · 2026-06-18 21:50:15 -07:00
  41988e6a24
• Recover exec process stdin writes (#28895)

  ## Summary
  
  Remote stdio MCP servers send tool calls by writing JSON-RPC bytes
  through `process/write`.
  
  When the exec-server websocket drops at the wrong time, the remote
  process can survive session recovery, but the stdin write can still fail
  back to RMCP as a transport send error. RMCP then closes the stdio MCP
  transport, so tools like `node_repl` are lost even though the
  process/session recovery path is working.
  
  This changes `process/write` to be safe to retry across exec-server
  recovery:
  
  - adds a required `writeId` to `process/write`
  - retries remote `Session::write` with the same `writeId` after
  reconnect
  - remembers accepted write ids per process so duplicate retries return
  `Accepted` without writing the same bytes to child stdin again
  - covers both the client retry path and server-side write id dedupe with
  tests
  
  In simple terms:
  
  ```text
  before:
  write to MCP stdin -> websocket closes -> write errors -> RMCP closes node_repl
  
  after:
  write to MCP stdin -> websocket closes -> reconnect -> retry same writeId
  server either writes once or recognizes it already did
  ```

  jif · 2026-06-18 19:04:26 +02:00
  83e6a786a2
• Run fs helper through Windows sandbox wrapper (#28359)

  ## Why
  
  This is the final PR in the Windows fs-helper sandbox stack and contains
  the actual bug fix.
  
  The exec-server filesystem helper is a direct-spawn path: it asks
  `SandboxManager` for a `SandboxExecRequest`, then launches the returned
  argv itself. That works on macOS and Linux because the transformed argv
  is already a self-contained sandbox wrapper. On Windows, the transformed
  request carried `WindowsRestrictedToken` metadata, but the direct-spawn
  fs-helper runner still launched the helper argv directly.
  
  That means Windows filesystem built-ins backed by the fs-helper could
  run with the parent Codex process permissions instead of the configured
  Windows sandbox. This PR makes the direct-spawn transform produce a
  self-contained Windows wrapper argv before fs-helper launches it.
  
  ## What Changed
  
  - Added `SandboxManager::transform_for_direct_spawn()` for callers that
  launch the returned argv themselves.
  - Wrapped Windows restricted-token direct-spawn requests with `codex.exe
  --run-as-windows-sandbox` and then marked the outer request as
  unsandboxed, matching the macOS/Linux wrapper argv shape.
  - Updated `exec-server/src/fs_sandbox.rs` to use the direct-spawn
  transform for fs-helper launches.
  - Materialized the inner `codex.exe --codex-run-as-fs-helper` executable
  into `.sandbox-bin` so the sandboxed user can run it.
  - Carried runtime workspace roots through `FileSystemSandboxContext` as
  `PathUri` values so `:workspace_roots` policies resolve correctly
  without sending native client paths over exec-server JSON.
  - Preserved wrapper setup identity environment needed by Windows sandbox
  setup without changing the serialized inner helper environment.
  
  ## Verification
  
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `just test -p codex-sandboxing transform_for_direct_spawn_windows`
  - `just test -p codex-exec-server fs_sandbox::tests`
  - `just fix -p codex-windows-sandbox -p codex-sandboxing -p
  codex-exec-server -p codex-core -p codex-file-system`
  
  Local note: `just fmt` completed Rust formatting, but this workstation
  still fails the non-Rust formatter phases because uv cannot open its
  cache and the local buildifier/dotslash path is missing.

  iceweasel-oai · 2026-06-17 10:00:42 -07:00
  ef75171f18
• Resume exec-server sessions after disconnect (#28512)

  Supersedes #28288 (closed).
  
  ## Why
  
  A short WebSocket interruption currently ends every client-side process
  handle, even though exec-server keeps the server session and its
  processes alive for a short time.
  
  This is especially visible for executor-backed stdio MCP servers: a
  temporary connection loss becomes a permanent `Transport closed` error.
  The server already has the information needed to resume the session, but
  the client opens a fresh session instead of using it.
  
  This change reconnects below the process and MCP layers. Existing
  process handles stay valid, missed output is recovered, and the same
  server-side processes continue running.
  
  ## State machine
  
  One logical `ExecServerClient` stays alive while its underlying RPC
  connection changes generations.
  
  ```text
                           transport closes
         +------------------------------------------------+
         |                                                v
  +-------------+                                  +-------------+
  |  Connected  |                                  | Recovering  |
  +-------------+                                  +-------------+
         ^                                                |
         | session resumed, processes caught up           | retryable error
         +------------------------------------------------+ loops until deadline
                                                          |
                                                          | deadline or permanent error
                                                          v
                                                    +-------------+
                                                    |   Failed    |
                                                    +-------------+
  ```
  
  ### `Connected`
  
  - New RPC calls use the current connection.
  - Process notifications are published in sequence order.
  - A disconnect only starts recovery if it came from the current
  connection generation. Late events from older generations cannot replace
  the active connection.
  
  ### `Recovering`
  
  - New calls wait instead of choosing a half-connected RPC client.
  - Existing process handles, wake subscriptions, and event subscriptions
  stay open.
  - Streaming HTTP response bodies fail immediately because their byte
  streams cannot be resumed safely.
  - Recovery first waits for process starts that were already in flight. A
  start whose result became ambiguous is cleaned up after reconnection
  instead of being silently adopted.
  - The client reconnects with the learned `session_id`. The server may
  briefly report that the old connection is still attached, so that error
  is retried until the detach finishes.
  - The notification consumer starts before the resume handshake
  completes. This prevents a busy process from filling the notification
  queue and blocking the initialize response.
  - Before installing the new connection, the client catches up every
  recoverable process with `process/read`.
  
  ### `Failed`
  
  - Recovery stops after 25 seconds or after a permanent error.
  - Waiting calls are released with one stable disconnect error.
  - Existing process sessions receive a terminal failure instead of
  waiting forever.
  
  ## Recovering process events
  
  Output, exit, and close events share one sequence. During normal
  operation, the client buffers early events until every lower sequence
  has been published.
  
  After reconnection, the client reads each process starting after its
  last published sequence:
  
  1. Retained output chunks are inserted by sequence number.
  2. Exit and close state are reconstructed in their sequence positions.
  3. Events already received as live notifications are ignored as
  duplicates.
  4. Newly contiguous events are published in order.
  5. If the server no longer retains enough output to fill a sequence gap,
  only that process is terminated and failed. The recovered connection
  remains usable for other processes.
  
  The server reports its full next event sequence for unbounded reads,
  including exit and close events. Closed processes remain readable for
  the same 30-second window used to retain detached sessions.
  
  ## Other details
  
  - Detached server sessions are retained for 30 seconds, leaving margin
  around the client's 25-second recovery deadline.
  - Session attach and detach update the active notification sender under
  the same attachment lock, so an old connection cannot clear a newly
  attached sender.
  - A dedicated error code distinguishes the temporary "session is still
  attached" race from permanent initialization errors.
  - Process starts are identity-checked on both client and server. Cleanup
  from an older start cannot remove a newer process that reused the same
  ID.
  - Mutating requests that were already in flight when the transport
  closed are not replayed, because the client cannot know whether the
  server applied them. Requests started after recovery is known wait for
  the replacement connection.
  - We assume the server/client version stays in sync (on the before/after
  this PR)
  
  ## User impact
  
  Long-running commands and stdio MCP servers can survive a temporary
  exec-server WebSocket interruption without changing process IDs or
  losing output produced during the outage.

  jif · 2026-06-17 10:20:39 +02:00
  cf17e1bc20
• [codex] exec-server: stream files in chunks (#28354)

  ## Why
  
  `fs/readFile` buffers the entire file in one response, which makes large
  remote reads expensive and prevents callers from applying backpressure.
  We need an opt-in streaming path with bounded block sizes while
  preserving the existing single-call API for small and sandboxed reads.
  
  ## What changed
  
  - Add `ExecServerClient::stream`, returning a named `FileReadStream`
  that implements `futures::Stream` and yields immutable 1 MiB byte
  blocks.
  - Add internal `fs/open`, `fs/readBlock`, and `fs/close` RPCs.
  `fs/readBlock` accepts an explicit offset and length.
  - Keep unsandboxed files open between block reads, cap open handles per
  connection, and clean them up on EOF, error, stream drop, explicit
  close, or connection shutdown.
  - Reject platform-sandboxed streaming opens instead of turning the
  one-shot sandbox helper into a persistent server. Existing `fs/readFile`
  behavior is unchanged.
  
  ## Testing
  
  - `just test -p codex-exec-server`
  - Integration coverage for 1 MiB chunking, exact block-boundary EOF,
  sandbox rejection, and continued reads from the opened file after path
  replacement.
  - Handle-manager coverage for non-sequential offsets, variable block
  lengths, the 128-handle limit, and capacity release after close.

  pakrym-oai · 2026-06-16 09:50:55 -07:00
  a4711b88dd
• [codex] Use expect in integration tests (#28441)

  The workspace denies `clippy::expect_used` in production. Although
  `clippy.toml` allows `expect` in tests, Bazel Clippy compiles
  integration-test helper code in a way that does not receive that
  exemption, which encouraged verbose `unwrap_or_else(... panic!(...))`
  and equivalent `match`/`let else` forms.
  
  This allows `clippy::expect_used` once at each integration-test crate
  root (including aggregated suites and test-support libraries), then
  replaces manual panic-based Result and Option unwraps with
  `expect`/`expect_err`. Standalone `tests/*.rs` files remain their own
  crate roots. Intentional assertion and unexpected-variant panics remain
  unchanged, and the production `expect_used = "deny"` lint remains in
  place.
  
  The cleanup is mechanical and net-negative in line count.

  pakrym-oai · 2026-06-15 21:53:47 -07:00
  e752f7b4ae
• exec-server: default remote transport to Noise (#26245)

  ## Why
  
  The transport in
  [openai/codex#26242](https://github.com/openai/codex/pull/26242) needs
  to be used by every remote orchestrator-to-executor connection before
  JSON-RPC traffic starts.
  
  ## Changes
  
  - Generates one executor Noise identity when remote exec-server starts
  and registers its public key.
  - Creates a harness identity for each physical remote environment
  connection.
  - Fetches a fresh registry bundle before connecting and validates the
  authenticated harness key before completing the executor handshake.
  - Multiplexes encrypted logical streams over the existing executor
  WebSocket.
  - Adds bounded stream, handshake-failure, and reassembly state.
  - Adds safe lifecycle diagnostics without logging keys, authorizations,
  plaintext, or ciphertext.
  - Covers reconnects, replay rejection, validation failure, framing
  limits, and encrypted JSON-RPC tool traffic.
  
  ## Stack
  
  1. [openai/codex#26242](https://github.com/openai/codex/pull/26242):
  Noise channel and relay transport
  2. **[openai/codex#26245](https://github.com/openai/codex/pull/26245)**:
  remote registration and runtime activation
  
  ## Verification
  
  - `just test -p codex-exec-server`
  - `just fix -p codex-exec-server`
  - `just bazel-lock-check`
  - `cargo shear`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-06-15 17:39:00 -07:00
  6e50b22e55
• Use PathUri in filesystem permission paths for exec-server (#28165)

  ## Why
  
  Progress towards letting app-server and exec-server run on different
  platforms, specifically for sandbox configuration.
  
  ## What
  
  - Make the filesystem path containment hierarchy generic, defaulting to
  `AbsolutePathBuf` for now.
  - Have clients specify `AbsolutePathBuf` or `PathUri` directly where
  needed.
  - Use `PathUri` throughout exec-server filesystem protocol and trait
  boundaries.
  - Implement `From` for conversion to path URIs and `TryFrom` for
  fallible conversion to absolute paths through the generic type
  hierarchy.

  Adam Perry @ OpenAI · 2026-06-15 23:55:23 +00:00
  46f17930b6
• [codex] Carry exec-server cwd as PathUri (#28032)

  ## Why
  
  This is the second-to-last place in the exec-server protocol that needs
  to migrate to URIs to support cross-OS operation.
  
  ## What
  
  - Change `ExecParams.cwd` to `PathUri`.
  - Keep the cwd URI-shaped through core and rmcp producers, converting it
  to `AbsolutePathBuf` only in `LocalProcess::start_process`.
  - Reject non-native cwd URIs before launch and update the affected
  protocol documentation and call sites.

  Adam Perry @ OpenAI · 2026-06-13 20:56:42 +00:00
  0fed4497f5
• [codex] Add size to internal filesystem metadata (#27927)

  ## Why
  
  `ExecutorFileSystem::get_metadata` reports file kind and timestamps but
  not size. Internal callers that need to enforce a size limit therefore
  have to read the complete file first, which is especially wasteful for
  remote filesystems.
  
  This adds the missing internal metadata so consumers can reject
  oversized files before transferring or buffering them. The field is
  named `size`, matching VS Code's `FileStat.size` filesystem convention.
  
  ## What changed
  
  - add `size: u64` to internal `FileMetadata`
  - populate it from the underlying filesystem metadata
  - carry it through sandbox-helper and remote exec-server responses
  - cover files, directories, symlink targets, and sandboxed reads across
  local and remote filesystem implementations
  
  The new field is intentionally not exposed through the app-server API.
  
  ## Testing
  
  - `just test -p codex-exec-server get_metadata`
  - `just test -p codex-exec-server
  file_system_sandboxed_metadata_and_read_allow_readable_root`
  - `just test -p codex-core-plugins`
  - `just test -p codex-skills-extension`

  pakrym-oai · 2026-06-12 12:12:08 -07:00
  76d8f20241
• [codex] migrate ExecutorFileSystem paths to PathUri (#27424)

  ## Why
  
  We're moving exec-server to use PathUri for its internal path
  representations.
  
  ## What
  
  Move `ExecutorFileSystem` APIs to use `PathUri` instead of
  `AbsolutePathBuf`. Future changes will convert higher-level parts of
  exec-server.

  Adam Perry @ OpenAI · 2026-06-11 18:44:18 +00:00
  b2a4e3be27
• [codex] add cross-platform filesystem adapter coverage (#27454)

  ## Why
  
  The exec-server's existing filesystem tests only run on `#[cfg(unix)]`.
  We should be running the applicable ones on Windows, and also include
  the basic filesystem operations that will be modified by migrating to
  `PathUri`.
  
  ## What
  
  Split platform-neutral local/remote tests into a shared Unix/Windows
  suite while keeping the existing `AbsolutePathBuf` API, and add Windows
  junction canonicalization coverage.

  Adam Perry @ OpenAI · 2026-06-11 17:53:18 +00:00
  cc97839068
• [codex] Handle Ctrl-C for non-TTY unified exec (#26734)

  ## Why
  
  A long-running unified exec process started with `tty: false` could not
  be interrupted via `write_stdin`: ordinary non-TTY stdin writes are
  rejected once stdin is closed, but an exact U+0003 payload should still
  map to a process interrupt. The interrupt should flow through the same
  process lifecycle path as a real signal so Codex preserves
  process-reported output and exit metadata instead of fabricating a
  Ctrl-C exit code or tearing down the session early.
  
  ## What Changed
  
  - Add `process/signal` to exec-server with `ProcessSignal::Interrupt`
  and an empty response.
  - Add a non-consuming `ProcessHandle::signal` path for spawned
  processes; on Unix it sends SIGINT to the process group and leaves
  terminate/hard-kill unchanged.
  - Route non-TTY U+0003 `write_stdin` through `process.signal(...)`
  instead of `terminate`, then let the normal post-write collection path
  drain output and observe exit.
  - Add exec-server coverage where a shell `trap INT` handler prints the
  signal and exits with its own code.
  - Add unified exec coverage where a `tty: false` process traps SIGINT,
  emits output, and exits with its own code.
  
  ## Validation
  
  - `just test -p codex-exec-server
  exec_process_signal_interrupts_process`
  - `just test -p codex-exec-server`
  - `just test -p codex-core
  write_stdin_ctrl_c_interrupts_non_tty_session`

  pakrym-oai · 2026-06-09 15:10:17 -07:00
  f2969f36e8
• [codex] Add environment shell info (#26480)

  ## Why
  
  Shell detection needs to be available through the `Environment`
  abstraction so callers can ask the selected local or remote environment
  for shell metadata without adding a separate HTTP endpoint or parallel
  info-source path. This keeps shell metadata shaped like the existing
  environment-owned filesystem capability and lets remote environments
  answer through exec-server JSON-RPC.
  
  ## What changed
  
  - Added `environment/info` to the exec-server protocol/client/server and
  exposed `Environment::info()`.
  - Added local and remote environment info providers on `Environment`,
  following the existing capability-provider pattern used for filesystem
  access.
  - Moved the shared shell detection logic into `codex-shell-command` and
  kept core shell APIs as wrappers around that implementation.
  - Returned shell metadata as `EnvironmentInfo { shell: ShellInfo }`
  using the existing shell detection path.
  - Added a remote environment test that calls `Environment::info()`
  through an exec-server-backed environment.
  
  ## Validation
  
  - `git diff --check`
  - `just test -p codex-shell-command`
  - `just test -p codex-core -E 'test(/shell::tests::/)'`\n- `just test -p
  codex-exec-server environment`

  pakrym-oai · 2026-06-04 22:36:25 -07:00
  6a6a5f925e
• exec-server: canonicalize bound filesystem paths (#25149)

  ## Summary
  - add executor filesystem canonicalization as a bound-path operation
  - route remote canonicalization through the exec-server filesystem RPC
  surface
  - keep path normalization attached to the filesystem that owns the path
  
  ## Stack
  - 2/5 in the skills path authority stack extracted from
  https://github.com/openai/codex/pull/25098
  - follows merged https://github.com/openai/codex/pull/25121
  
  ## Validation
  - `cd
  /Users/starr/code/codex-worktrees/pr-25098-restack-review-pr1b/codex-rs
  && just fmt`
  - Not run: tests/checks (not requested)
  - GitHub CI pending on rewritten head

  starr-openai · 2026-06-01 11:53:31 -07:00
  53ac02356e
• fix(exec-server): reject websocket requests with Origin headers (#24947)

  ## Why
  
  `codex exec-server` has a local WebSocket listener, but it did not apply
  the same browser-origin request handling as the `app-server` WebSocket
  transport. Requests that carry an `Origin` header should not be upgraded
  by this local transport, keeping both local WebSocket servers consistent
  and avoiding unexpected browser-initiated connections.
  
  ## What changed
  
  - Added an Axum middleware guard in
  `codex-rs/exec-server/src/server/transport.rs` that returns `403
  Forbidden` for requests carrying an `Origin` header.
  - Added an integration test in `codex-rs/exec-server/tests/websocket.rs`
  that covers rejection of an `Origin`-bearing WebSocket handshake.
  - Kept ordinary WebSocket clients unchanged: existing no-`Origin`
  initialization and process behavior remains covered by the crate tests.
  
  ## Validation
  
  - `just test -p codex-exec-server` test phase (`186 passed`; run outside
  the parent macOS sandbox so nested sandbox tests can execute)
  - `just clippy -p codex-exec-server`

  viyatb-oai · 2026-05-28 14:44:14 -07:00
  a027135bc6
• Migrate exec-server remote registration to environments (#23633)

  ## Summary
  - migrate exec-server remote registration naming from executor to
  environment
  - align CLI, public Rust exports, registry error messages, and relay
  test fixtures with the environment registry contract
  - keep the live registration path and response model consistent with
  `/cloud/environment/{environment_id}/register`
  
  ## Verification
  - `cargo test -p codex-exec-server
  remote::tests::register_environment_posts_with_auth_provider_headers
  --manifest-path /Users/richardlee/code/codex/codex-rs/Cargo.toml`
  - `cargo test -p codex-exec-server --test relay
  multiplexed_remote_environment_routes_independent_virtual_streams
  --manifest-path /Users/richardlee/code/codex/codex-rs/Cargo.toml`
  - `cargo check -p codex-cli --manifest-path
  /Users/richardlee/code/codex/codex-rs/Cargo.toml` (still running when PR
  opened; will update after completion if needed)

  richardopenai · 2026-05-20 00:25:04 -07:00
  000bf5ce6d
• exec-server: support auth-backed remote executor registration (#22769)

  This updates remote `exec-server` registration to use normal Codex auth
  instead of a registry-issued credential. The registry request is built
  from the existing auth-provider path, which preserves the biscuit-only
  registry contract introduced in
  [openai/openai#924101](https://github.com/openai/openai/pull/924101)
  while removing the old remote registry bearer env var and its direct
  transport assumptions.
  
  The default remote flow uses persisted ChatGPT auth from the normal
  Codex config/storage path. This PR also includes the containerized Agent
  Identity path needed by
  [openai/openai#924260](https://github.com/openai/openai/pull/924260):
  remote `exec-server` accepts `--allow-agent-identity-auth`, permits
  Agent Identity auth loaded from `CODEX_ACCESS_TOKEN` only when that flag
  is present, and reuses the existing Agent task registration plus derived
  `AgentAssertion` header generation. API-key auth remains unsupported,
  and Agent Identity stays opt-in.
  
  Validation performed beyond normal presubmit coverage:
  - `cargo fmt --all --check`
  - `cargo check -p codex-cli`
  - `cargo test -p codex-exec-server`
  - `cargo test -p codex-cli exec_server_agent_identity_auth_flag_`
  - `cargo test -p codex-cli remote_exec_server_auth_mode_`
  
  I also attempted `cargo test -p codex-cli`. The new CLI tests passed
  inside that run, but the suite ended on an unrelated local
  marketplace-state failure in
  `plugin_list_excludes_unconfigured_repo_local_marketplaces`.

  Michael Zeng · 2026-05-16 12:48:28 -07:00
  b200dd1b6f
• feat(exec-server): use protobuf relay frames (#22343)

  ## Why
  
  Remote exec-server now needs one executor websocket to serve multiple
  harness JSON-RPC sessions. Rendezvous routes by `stream_id`, and the
  exec-server side needs to use the same stable relay frame contract
  instead of a hand-rolled JSON shape.
  
  The relay protocol also needs to make ownership boundaries clear:
  harness and executor endpoints own sequencing, acks, retries, duplicate
  suppression, segmentation, and reassembly; rendezvous only routes
  frames.
  
  ## What Changed
  
  - Add the checked-in `codex.exec_server.relay.v1.RelayMessageFrame`
  proto plus generated prost bindings for `codex-exec-server`.
  - Encode remote harness/executor relay traffic as binary protobuf
  websocket frames while keeping local websocket JSON-RPC unchanged.
  - Demux executor-side relay streams into independent
  `ConnectionProcessor` sessions keyed by `stream_id`.
  - Add a programmatic `RemoteExecutorConfig::with_bearer_token(...)`
  constructor for non-CLI callers and integration tests.
  - Add an integration test that starts the remote executor against a fake
  registry/rendezvous websocket and verifies two virtual streams share one
  executor websocket without cross-talk, including per-stream reset
  behavior.
  - Document the remote relay envelope, sequence ranges, `ack`/`ack_bits`,
  and endpoint responsibilities in `exec-server/README.md`.
  
  ## Verification
  
  - `cargo test -p codex-exec-server --test relay
  multiplexed_remote_executor_routes_independent_virtual_streams --
  --exact`
  - `cargo test -p codex-exec-server --test relay`
  - `cargo test -p codex-exec-server` passed outside the sandbox. The
  sandboxed run hit macOS `sandbox-exec: sandbox_apply: Operation not
  permitted` in filesystem sandbox tests.

  Anton Panasenko · 2026-05-12 16:50:45 -07:00
  ac466c0dbd
• [exec-server] serve websocket listener via HTTP upgrade (#21963)

  ## Why
  
  `codex exec-server` should keep the existing public `ws://IP:PORT` URL
  shape while serving that websocket connection through an HTTP upgrade
  path internally. That keeps the client-facing configuration simple and
  allows the listener to work through intermediate HTTP-aware
  infrastructure.
  
  ## What changed
  
  - keep the emitted and configured exec-server URL as `ws://IP:PORT`
  - serve that websocket endpoint through Axum HTTP upgrade handling on
  `/`
  - expose `GET /readyz` from the same listener for readiness checks
  - route upgraded Axum websocket streams through the shared JSON-RPC
  connection machinery
  - initialize the rustls crypto provider before websocket client
  connections
  - preserve inbound binary websocket JSON-RPC parsing for compatibility
  with the prior transport behavior
  
  ## Verification
  
  - `cargo test -p codex-exec-server --test health --test process --test
  websocket --test initialize --test exec_process`

  Ruslan Nigmatullin · 2026-05-11 17:04:21 -07:00
  95d8669ab2
• tests: cover sandbox link write behavior (#21819)

  ## Why
  
  [PR #1705](https://github.com/openai/codex/pull/1705) moved
  `apply_patch` execution under the configured sandbox and called out the
  need for integration coverage. We already covered textual `../` escapes,
  but did not have coverage for link aliases that live inside a writable
  workspace while pointing at, or aliasing, files visible outside it.
  
  This PR locks in the current sandbox boundary without changing
  production write semantics. Symlink escapes into a read-only outside
  root should fail and leave the outside file unchanged. Existing hard
  links are characterized separately: if a user-created hard link already
  exists inside the writable root, sandboxed writes preserve normal
  hard-link semantics rather than replacing the link and silently breaking
  that relationship.
  
  ## What Changed
  
  - Added
  `apply_patch_cli_does_not_write_through_symlink_escape_outside_workspace`
  to verify `apply_patch` cannot update a symlink that targets a file
  outside the writable workspace.
  - Added `apply_patch_cli_preserves_existing_hard_link_outside_workspace`
  to verify `apply_patch` intentionally writes through an existing hard
  link and does not unlink or replace it.
  - Added `file_system_sandboxed_write_preserves_existing_hard_link` to
  verify sandboxed `fs/writeFile` preserves an existing hard link and
  writes the shared inode.
  
  ## Testing
  
  - `cargo test -p codex-exec-server file_system_sandboxed_write`
  - `cargo test -p codex-core
  apply_patch_cli_does_not_write_through_symlink_escape_outside_workspace`
  - `cargo test -p codex-core
  apply_patch_cli_preserves_existing_hard_link_outside_workspace`
  - `just fix -p codex-exec-server -p codex-core`
  - `just fix -p codex-core`
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/21819).
  * #21845
  * __->__ #21819

  Michael Bolin · 2026-05-09 08:28:15 -07:00
  0c70698e24
• fix(linux-sandbox): fall back when system bwrap lacks perms (#20628)

  ## Why
  
  Codex `0.128` started using `--perms` in more routine Linux sandbox
  construction when protected workspace metadata mounts landed in #19852.
  Upstream bubblewrap added `--perms` in `v0.5.0`, so system `bwrap`
  versions older than that, including the `v0.4.0` and `v0.4.1` family, do
  not support the flag. The launcher still selected those binaries as long
  as they existed on `PATH`.
  
  That means affected hosts can fail every sandboxed command up front
  with:
  
  ```text
  bwrap: Unknown option --perms
  ```
  
  The reports in #20590 and duplicate #20623 match that compatibility gap;
  #20623 explicitly shows system bubblewrap `0.4.0`.
  
  ## What changed
  
  - Replace the single `--argv0` probe with a small system-bwrap
  capability probe in `codex-rs/linux-sandbox/src/launcher.rs`.
  - Continue using the old-system `--argv0` compatibility path when
  needed, but only select a system `bwrap` if it also advertises
  `--perms`.
  - Fall back to the vendored `bwrap` when the system binary is too old
  for the flags Codex now requires.
  - Add regression coverage for the old-system-bwrap case so binaries
  without `--perms` stay on the vendored path.
  
  ## Verification
  
  - Added `falls_back_to_vendored_when_system_bwrap_lacks_perms` to cover
  the reported compatibility gap.
  - Ran `cargo test -p codex-linux-sandbox` and `cargo clippy -p
  codex-linux-sandbox --tests` locally. On macOS, the crate builds but its
  Linux-only tests are cfg-gated out, so the new regression test still
  needs Linux CI or a Linux devbox run for real execution coverage.
  
  ## Related issues
  
  - Fixes #20590
  - Duplicate report: #20623

  viyatb-oai · 2026-05-04 10:38:31 -07:00
  5b80f87c97
• permissions: make profiles represent enforcement (#19231)

  ## Why
  
  `PermissionProfile` is becoming the canonical permissions abstraction,
  but the old shape only carried optional filesystem and network fields.
  It could describe allowed access, but not who is responsible for
  enforcing it. That made `DangerFullAccess` and `ExternalSandbox` lossy
  when profiles were exported, cached, or round-tripped through app-server
  APIs.
  
  The important model change is that active permissions are now a disjoint
  union over the enforcement mode. Conceptually:
  
  ```rust
  pub enum PermissionProfile {
      Managed {
          file_system: FileSystemSandboxPolicy,
          network: NetworkSandboxPolicy,
      },
      Disabled,
      External {
          network: NetworkSandboxPolicy,
      },
  }
  ```
  
  This distinction matters because `Disabled` means Codex should apply no
  outer sandbox at all, while `External` means filesystem isolation is
  owned by an outside caller. Those are not equivalent to a broad managed
  sandbox. For example, macOS cannot nest Seatbelt inside Seatbelt, so an
  inner sandbox may require the outer Codex layer to use no sandbox rather
  than a permissive one.
  
  ## How Existing Modeling Maps
  
  Legacy `SandboxPolicy` remains a boundary projection, but it now maps
  into the higher-fidelity profile model:
  
  - `ReadOnly` and `WorkspaceWrite` map to `PermissionProfile::Managed`
  with restricted filesystem entries plus the corresponding network
  policy.
  - `DangerFullAccess` maps to `PermissionProfile::Disabled`, preserving
  the “no outer sandbox” intent instead of treating it as a lax managed
  sandbox.
  - `ExternalSandbox { network_access }` maps to
  `PermissionProfile::External { network }`, preserving external
  filesystem enforcement while still carrying the active network policy.
  - Split runtime policies that legacy `SandboxPolicy` cannot faithfully
  express, such as managed unrestricted filesystem plus restricted
  network, stay `Managed` instead of being collapsed into
  `ExternalSandbox`.
  - Per-command/session/turn grants remain partial overlays via
  `AdditionalPermissionProfile`; full `PermissionProfile` is reserved for
  complete active runtime permissions.
  
  ## What Changed
  
  - Change active `PermissionProfile` into a tagged union: `managed`,
  `disabled`, and `external`.
  - Keep partial permission grants separate with
  `AdditionalPermissionProfile` for command/session/turn overlays.
  - Represent managed filesystem permissions as either `restricted`
  entries or `unrestricted`; `glob_scan_max_depth` is non-zero when
  present.
  - Preserve old rollout compatibility by accepting the pre-tagged `{
  network, file_system }` profile shape during deserialization.
  - Preserve fidelity for important edge cases: `DangerFullAccess`
  round-trips as `disabled`, `ExternalSandbox` round-trips as `external`,
  and managed unrestricted filesystem + restricted network stays managed
  instead of being mistaken for external enforcement.
  - Preserve configured deny-read entries and bounded glob scan depth when
  full profiles are projected back into runtime policies, including
  unrestricted replacements that now become `:root = write` plus deny
  entries.
  - Regenerate the experimental app-server v2 JSON/TypeScript schema and
  update the `command/exec` README example for the tagged
  `permissionProfile` shape.
  
  ## Compatibility
  
  Legacy `SandboxPolicy` remains available at config/API boundaries as the
  compatibility projection. Existing rollout lines with the old
  `PermissionProfile` shape continue to load. The app-server
  `permissionProfile` field is experimental, so its v2 wire shape is
  intentionally updated to match the higher-fidelity model.
  
  ## Verification
  
  - `just write-app-server-schema`
  - `cargo check --tests`
  - `cargo test -p codex-protocol permission_profile`
  - `cargo test -p codex-protocol
  preserving_deny_entries_keeps_unrestricted_policy_enforceable`
  - `cargo test -p codex-app-server-protocol
  permission_profile_file_system_permissions`
  - `cargo test -p codex-app-server-protocol serialize_client_response`
  - `cargo test -p codex-core
  session_configured_reports_permission_profile_for_external_sandbox`
  - `just fix`
  - `just fix -p codex-protocol`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-core`
  - `just fix -p codex-app-server`

  Michael Bolin · 2026-04-23 23:02:18 -07:00
  4816b89204
• fix(exec-server): retain output until streams close (#18946)

  ## Why
  
  A Mac Bazel run hit a flake in
  `server::handler::tests::output_and_exit_are_retained_after_notification_receiver_closes`
  where the read path observed process exit but lost the expected buffered
  stdout (`first\nsecond\n`). See the [GitHub Actions
  job](https://github.com/openai/codex/actions/runs/24758468552/job/72436716505)
  and [BuildBuddy
  invocation](https://app.buildbuddy.io/invocation/37475a12-4ef2-45fb-ab8a-e49a2aba1d59).
  
  The underlying race is that process exit is not the same thing as
  stdout/stderr closure. If a child or grandchild inherits the pipe write
  end, or a process duplicates it with `dup2`, the watched process can
  exit while the stream is still open and more output can still arrive.
  The exec-server was starting exited-process retention cleanup from the
  exit event, so the process entry could be removed before the output
  streams had actually closed.
  
  While stress-testing the exec-server unit suite,
  `server::handler::tests::long_poll_read_fails_after_session_resume`
  exposed a separate test race: it started a short-lived command that
  could exit and wake the pending long-poll read before the session-resume
  assertion observed the resumed-session error. That test is intended to
  cover resume eviction, not process-exit delivery, so this change keeps
  the process alive and quiet while the second connection resumes the
  session.
  
  ## What changed
  
  - Keep exec-server process entries retained until stdout/stderr streams
  close, then start the post-exit retention timer from the closed event.
  - Wake long-poll readers when the closed event is emitted.
  - Add focused `local_process` unit coverage that proves late output is
  still retained after the short test retention interval has elapsed, and
  that closed process entries are eventually evicted.
  - Add a local and remote regression test where a parent exits while a
  child keeps inherited stdout open. The child waits on an explicit
  release file, so the test deterministically observes exit first,
  releases the child, then requires a nonzero-wait read from the exit
  sequence to receive the late output.
  - In `codex-rs/exec-server/src/server/handler/tests.rs`, make
  `long_poll_read_fails_after_session_resume` run a long-lived silent
  command instead of a short command that prints and exits. This isolates
  the test to session-resume behavior and prevents a normal process exit
  from satisfying the pending long-poll read first.
  
  ## Testing
  
  - `cargo test -p codex-exec-server
  exec_process_retains_output_after_exit_until_streams_close`
  - `cargo test -p codex-exec-server local_process::tests`
  - `cargo test -p codex-exec-server`
  - `just fix -p codex-exec-server`
  - `bazel test //codex-rs/exec-server:exec-server-unit-tests
  //codex-rs/exec-server:exec-server-exec_process-test
  //codex-rs/exec-server:exec-server-file_system-test
  //codex-rs/exec-server:exec-server-http_client-test
  //codex-rs/exec-server:exec-server-initialize-test
  //codex-rs/exec-server:exec-server-process-test
  //codex-rs/exec-server:exec-server-websocket-test`
  - `bazel test --runs_per_test=25
  //codex-rs/exec-server:exec-server-unit-tests`
  
  ## Documentation
  
  No docs update needed; this is an internal exec-server correctness fix.

  Michael Bolin · 2026-04-23 19:49:58 +00:00
  491a3058f6
• exec-server: require explicit filesystem sandbox cwd (#19046)

  ## Why
  
  This is a cleanup PR for the `PermissionProfile` migration stack. #19016
  fixed remote exec-server sandbox contexts so Docker-backed filesystem
  requests use a request/container `cwd` instead of leaking the local test
  runner `cwd`. That exposed the broader API problem:
  `FileSystemSandboxContext::new(SandboxPolicy)` could still reconstruct
  filesystem permissions by reading the exec-server process cwd with
  `AbsolutePathBuf::current_dir()`.
  
  That made `cwd`-dependent legacy entries, such as `:cwd`,
  `:project_roots`, and relative deny globs, depend on ambient process
  state instead of the request sandbox `cwd`. As later PRs make
  `PermissionProfile` the primary permissions abstraction, sandbox
  contexts should be explicit about whether they carry a request `cwd` or
  are profile-only. Removing the implicit constructor prevents new call
  sites from accidentally rebuilding permissions against the wrong `cwd`.
  
  ## What changed
  
  - Removed `FileSystemSandboxContext::new(SandboxPolicy)`.
  - Kept production callers on explicit constructors:
  `from_legacy_sandbox_policy(..., cwd)`, `from_permission_profile(...)`,
  and `from_permission_profile_with_cwd(...)`.
  - Updated exec-server test helpers to construct `PermissionProfile`
  values directly instead of routing through legacy `SandboxPolicy`
  projections.
  - Updated the environment regression test to use an explicit restricted
  profile with no synthetic `cwd`.
  
  ## Verification
  
  - `cargo test -p codex-exec-server`
  - `just fix -p codex-exec-server`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19046).
  * #18288
  * #18287
  * #18286
  * #18285
  * #18284
  * #18283
  * #18282
  * #18281
  * #18280
  * __->__ #19046

  Michael Bolin · 2026-04-22 23:05:12 +00:00
  44dbd9e48a
• [2/4] Implement executor HTTP request runner (#18582)

  ### Why
  Remote streamable HTTP MCP needs the executor to perform ordinary HTTP
  requests on the executor side. This keeps network placement aligned with
  `experimental_environment = "remote"` without adding MCP-specific
  executor APIs.
  
  ### What
  - Add an executor-side `http/request` runner backed by `reqwest`.
  - Validate request method and URL scheme, preserving the transport
  boundary at plain HTTP.
  - Return buffered responses for ordinary calls and emit ordered
  `http/request/bodyDelta` notifications for streaming responses.
  - Register the request handler in the exec-server router.
  - Document the runner entrypoint, conversion helpers, body-stream
  bridge, notification sender, timeout behavior, and new integration-test
  helpers.
  - Add exec-server integration tests with the existing websocket harness
  and a local TCP HTTP peer for buffered and streamed responses, with
  comments spelling out what each test proves and its
  setup/exercise/assert phases.
  
  ### Stack
  1. #18581 protocol
  2. #18582 runner
  3. #18583 RMCP client
  4. #18584 manager wiring and local/remote coverage
  
  ### Verification
  - `just fmt`
  - `cargo check -p codex-exec-server -p codex-rmcp-client --tests`
  - `cargo check -p codex-core --test all` compile-only
  - `git diff --check`
  - Online full CI is running from the `full-ci` branch, including the
  remote Rust test job.
  
  Co-authored-by: Codex <noreply@openai.com>
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-22 20:36:34 +00:00
  9360f267f3
• exec-server: carry filesystem sandbox profiles (#18276)

  ## Why
  
  The exec-server still needs platform sandbox inputs, but the migration
  should preserve the `PermissionProfile` that produced them. Keeping only
  the derived legacy sandbox map would keep `SandboxPolicy` as the
  effective abstraction and would make full-disk vs. restricted profiles
  harder to preserve as the permissions stack starts round-tripping
  profiles.
  
  `PermissionProfile` entries can also be cwd-sensitive (`:cwd`,
  `:project_roots`, relative globs), so the exec-server must carry the
  request sandbox cwd instead of resolving those entries against the
  long-lived exec-server process cwd.
  
  ## What changed
  
  `FileSystemSandboxContext` now carries `permissions: PermissionProfile`
  plus an optional `cwd`:
  
  - removed `sandboxPolicy`, `sandboxPolicyCwd`,
  `fileSystemSandboxPolicy`, and `additionalPermissions`
  - added `permissions` and `cwd`
  - kept the platform knobs `windowsSandboxLevel`,
  `windowsSandboxPrivateDesktop`, and `useLegacyLandlock`
  
  Core turn and apply-patch paths populate the context from the active
  runtime permissions and request cwd. Exec-server derives platform
  `SandboxPolicy`/`FileSystemSandboxPolicy` at the filesystem boundary,
  adds helper runtime reads there, and rejects cwd-dependent profiles that
  arrive without a cwd.
  
  The legacy `FileSystemSandboxContext::new(SandboxPolicy)` constructor
  now preserves the old workspace-write conversion semantics for
  compatibility tests/callers.
  
  ## Verification
  
  - `cargo test -p codex-exec-server`
  - `cargo test -p codex-exec-server sandbox_cwd -- --nocapture`
  - `cargo test -p codex-exec-server
  sandbox_context_new_preserves_legacy_workspace_write_read_only_subpaths
  -- --nocapture`
  - `cargo test -p codex-core --lib
  file_system_sandbox_context_uses_active_attempt -- --nocapture`

  Michael Bolin · 2026-04-21 20:22:28 -07:00
  36f8bb4ffa
• Support multiple managed environments (#18401)

  ## Summary
  - refactor EnvironmentManager to own keyed environments with
  default/local lookup helpers
  - keep remote exec-server client creation lazy until exec/fs use
  - preserve disabled agent environment access separately from internal
  local environment access
  
  ## Validation
  - not run (per Codex worktree instruction to avoid tests/builds unless
  requested)
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-21 15:29:35 -07:00
  ddbe2536be
• [1/4] Add executor HTTP request protocol (#18581)

  ### Why
  Remote streamable HTTP MCP needs a transport-shaped executor primitive
  before the MCP client can move network I/O to the executor. This layer
  keeps the executor unaware of MCP and gives later PRs an ordered
  streaming surface for response bodies.
  
  ### What
  - Add typed `http/request` and `http/request/bodyDelta` protocol
  payloads.
  - Add executor client helpers for buffered and streamed HTTP responses.
  - Route body-delta notifications to request-scoped streams with sequence
  validation and cleanup when a stream finishes or is dropped.
  - Document the new protocol constants, transport structs, public client
  methods, body-stream lifecycle, and request-scoped routing helpers.
  - Add in-memory JSON-RPC client coverage for streamed HTTP response-body
  notifications, with comments spelling out what the test proves and each
  setup/exercise/assert phase.
  
  ### Stack
  1. #18581 protocol
  2. #18582 runner
  3. #18583 RMCP client
  4. #18584 manager wiring and local/remote coverage
  
  ### Verification
  - `just fmt`
  - `cargo check -p codex-exec-server -p codex-rmcp-client --tests`
  - `cargo check -p codex-core --test all` compile-only
  - `git diff --check`
  - Online full CI is running from the `full-ci` branch, including the
  remote Rust test job.
  
  Co-authored-by: Codex <noreply@openai.com>
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-21 02:21:08 +00:00
  d6af7a6c03
• [6/6] Fail exec client operations after disconnect (#18027)

  ## Summary
  - Reject new exec-server client operations once the transport has
  disconnected.
  - Convert pending RPC calls into closed errors instead of synthetic
  server errors.
  - Cover pending read and later write behavior after remote executor
  disconnect.
  
  ## Verification
  - `just fmt`
  - `cargo check -p codex-exec-server`
  
  ## Stack
  ```text
  @  #18027 [6/6] Fail exec client operations after disconnect
  │
  o  #18212 [5/6] Wire executor-backed MCP stdio
  │
  o  #18087 [4/6] Abstract MCP stdio server launching
  │
  o  #18020 [3/6] Add pushed exec process events
  │
  o  #18086 [2/6] Support piped stdin in exec process API
  │
  o  #18085 [1/6] Add MCP server environment config
  │
  o  main
  ```
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-20 23:24:06 +00:00
  9ef1cab6f7
• protocol: canonicalize file system permissions (#18274)

  ## Why
  
  `PermissionProfile` needs stable, canonical file-system semantics before
  it can become the primary runtime permissions abstraction. Without a
  canonical form, callers have to keep re-deriving legacy sandbox maps and
  profile comparisons remain lossy or order-dependent.
  
  ## What changed
  
  This adds canonicalization helpers for `FileSystemPermissions` and
  `PermissionProfile`, expands special paths into explicit sandbox
  entries, and updates permission request/conversion paths to consume
  those canonical entries. It also tightens the legacy bridge so root-wide
  write profiles with narrower carveouts are not silently projected as
  full-disk legacy access.
  
  ## Verification
  
  - `cargo test -p codex-protocol
  root_write_with_read_only_child_is_not_full_disk_write -- --nocapture`
  - `cargo test -p codex-sandboxing permission -- --nocapture`
  - `cargo test -p codex-tui permissions -- --nocapture`

  Michael Bolin · 2026-04-20 09:57:03 -07:00
  dcec516313
• exec-server: preserve fs helper runtime env (#18380)

  ## Summary
  - preserve a small fs-helper runtime env allowlist (`PATH`, temp vars)
  instead of launching the sandboxed helper with an empty env
  - add unit coverage for the allowlist and transformed sandbox request
  env
  - add a Linux smoke test that starts the test exec-server with a fake
  `bwrap` on `PATH`, runs a sandboxed fs write through the remote fs
  helper path, and asserts that bwrap path was exercised
  
  ## Validation
  - `cd /tmp/codex-worktrees/fs-helper-env-defaults/codex-rs && export
  PATH=$HOME/code/openai/project/dotslash-gen/bin:$HOME/.local/bin:$PATH
  && bazel test --bes_backend= --bes_results_url=
  //codex-rs/exec-server:exec-server-file_system-test
  --test_filter=sandboxed_file_system_helper_finds_bwrap_on_preserved_path`
  - `cd /tmp/codex-worktrees/fs-helper-env-defaults/codex-rs && export
  PATH=$HOME/code/openai/project/dotslash-gen/bin:$HOME/.local/bin:$PATH
  && bazel test --bes_backend= --bes_results_url=
  //codex-rs/exec-server:exec-server-unit-tests
  --test_filter="helper_env|sandbox_exec_request_carries_helper_env"`
  - earlier on this branch before the smoke-test harness adjustment: `cd
  /tmp/codex-worktrees/fs-helper-env-defaults/codex-rs && export
  PATH=$HOME/code/openai/project/dotslash-gen/bin:$HOME/.local/bin:$PATH
  && bazel test --bes_backend= --bes_results_url=
  //codex-rs/exec-server:all`
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-17 20:44:01 +00:00
  63e4a900c9
• [3/6] Add pushed exec process events (#18020)

  ## Summary
  - Add a pushed `ExecProcessEvent` stream alongside retained
  `process/read` output.
  - Publish local and remote output, exit, close, and failure events.
  - Cover the event stream with shared local/remote exec process tests.
  
  ## Testing
  - `cargo check -p codex-exec-server`
  - `cargo check -p codex-rmcp-client`
  - Not run: `cargo test` per repo instruction; CI will cover.
  
  ## Stack
  ```text
  o  #18027 [6/6] Fail exec client operations after disconnect
  │
  o  #18212 [5/6] Wire executor-backed MCP stdio
  │
  o  #18087 [4/6] Abstract MCP stdio server launching
  │
  @  #18020 [3/6] Add pushed exec process events
  │
  o  #18086 [2/6] Support piped stdin in exec process API
  │
  o  #18085 [1/6] Add MCP server environment config
  │
  o  main
  ```
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-17 19:07:43 +00:00
  9d3a5cf05e
• [2/8] Support piped stdin in exec process API (#18086)

  ## Summary
  - Add an explicit stdin mode to process/start.
  - Keep normal non-interactive exec stdin closed while allowing
  pipe-backed processes.
  
  ## Stack
  ```text
  o  #18027 [8/8] Fail exec client operations after disconnect
  │
  o  #18025 [7/8] Cover MCP stdio tests with executor placement
  │
  o  #18089 [6/8] Wire remote MCP stdio through executor
  │
  o  #18088 [5/8] Add executor process transport for MCP stdio
  │
  o  #18087 [4/8] Abstract MCP stdio server launching
  │
  o  #18020 [3/8] Add pushed exec process events
  │
  @  #18086 [2/8] Support piped stdin in exec process API
  │
  o  #18085 [1/8] Add MCP server environment config
  │
  o  main
  ```
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-16 10:30:10 -07:00
  2ca270d08d
• Stabilize Bazel tests (timeout tweaks and flake fixes) (#17791)
  David de Regt · 2026-04-16 07:57:51 -07:00
  6adba99f4d
• [codex] Restore remote exec-server filesystem tests (#17989)

  ## Summary
  
  - Re-enable remote variants for the exec-server filesystem
  sandbox/symlink tests that were made local-only in PR #17671.
  - Restore `use_remote` parameterization for the readable-root,
  normalized symlink escape, symlink removal, and symlink
  copy-preservation cases.
  - Preserve `mode={use_remote}` context on key async filesystem failures
  so CI failures point at the local or remote lane.
  
  ## Validation
  
  - `cd codex-rs && just fmt`
  - Not run: `bazel test
  //codex-rs/exec-server:exec-server-file_system-test` per local Codex
  development guidance to avoid test runs unless explicitly requested.
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-15 20:48:13 +00:00
  ba36415a30
• Fix fs/readDirectory to skip broken symlinks (#17907)

  ## Summary
  - Skip directory entries whose metadata lookup fails during
  `fs/readDirectory`
  - Add an exec-server regression test covering a broken symlink beside
  valid entries
  
  ## Testing
  - `just fmt`
  - `cargo test -p codex-exec-server` (started, but dependency/network
  updates stalled before completion in this environment)

  willwang-openai · 2026-04-15 10:50:22 -07:00
  a3d475d33f