177 Commits

• 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
• Apply sandbox intent inside remote exec servers (#29113)

  ## Why
  
  PR #29108 lets the orchestrator send sandbox intent with `process/start`
  without wrapping the command for its own operating system.
  
  This PR completes that boundary by making the executor interpret and
  enforce the intent using its own filesystem paths and sandbox
  implementation.
  
  For example, a macOS TUI targeting a Linux devbox sends `/bin/bash -lc
  pwd`. The Linux executor turns that into its own `codex-linux-sandbox
  ... /bin/bash -lc pwd` launch.
  
  ## What changes
  
  - Keep `process/start` unchanged when no sandbox intent is present.
  - Convert sandbox `PathUri` values into native paths on the executor.
  - Bind symbolic `:workspace_roots` permissions to the executor's native
  sandbox cwd.
  - Select the sandbox implementation on the executor and wrap the
  original command immediately before spawning it.
  - Reject sandbox-required execution before spawning when the executor
  cannot enforce the intent.
  - Pass exec-server runtime paths into process creation so Linux can
  locate `codex-linux-sandbox`.
  
  The boundary is therefore:
  
  ```text
  orchestrator                         executor
  original argv + sandbox intent  ->  select and enforce local sandbox
  ```
  
  This PR intentionally treats a denied remote command as an ordinary
  command failure. Draft follow-up #29424 carries a semantic
  `sandboxDenied` result back to unified exec for the existing approval
  and retry flow.
  
  ## Platform scope
  
  Linux and macOS use their existing direct-spawn sandbox transforms.
  
  Windows sandboxed remote process launch is intentionally unsupported in
  this PR. The current Windows direct-spawn wrapper does not correctly
  preserve arbitrary argv, TTY behavior, or pass the full child
  environment out of band. The executor rejects the request instead of
  running it incorrectly or unsandboxed.
  
  ## Known follow-ups
  
  - The transported permission profile can still contain
  orchestrator-materialized helper or explicit paths. A `TODO(jif)` marks
  where the executor boundary should receive pre-host-materialization
  permission intent.
  - The sandbox wrapper currently replaces a requested custom inner
  `arg0`. A `TODO(jif)` marks where this must be preserved or rejected
  explicitly.
  - Draft PR #29424 contains the deferred sandbox-denial classification
  and approval/retry behavior.
  
  ## Rollout assumption
  
  This executor-sandbox stack is unreleased and its client and executor
  are expected to move together. This PR does not add mixed-version
  negotiation with older exec servers.

  jif · 2026-06-22 12:45:37 +02:00
  9c3b10e5d4
• Test pipelined scalar exec-server requests (#29325)

  ## Summary
  
  This adds focused coverage for the simpler same-connection scalar
  request path.
  
  The exec-server connection already supports multiple in-flight JSON-RPC
  scalar requests on one connection. This test locks in that behavior by
  sending two normal requests before reading either response, without
  adding a batch frame or any new API surface.
  
  ## What changed
  
  - Added a processor-level test that initializes an exec-server
  connection.
  - Sends two scalar `environment/info` requests back-to-back on the same
  connection.
  - Verifies both responses come back on the same connection by request
  id.
  
  Checked locally with:
  
  - `just test -p codex-exec-server
  connection_accepts_pipelined_scalar_requests`

  jif · 2026-06-21 13:40:51 +02:00
  1088b30fda
• 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
• [3/3] app-server: configure environment connection timeout (#29025)

  ## Why
  
  Remote environments registered through `environment/add` currently use
  the fixed 10-second WebSocket connection timeout. Slow-starting
  executors need a caller-selected connection window, but this should not
  add retry policy or couple exec-server behavior to Core’s
  `deferred_executor` feature.
  
  Make the timeout an optional part of the existing experimental request.
  Existing clients continue using the current default, while callers that
  know an executor may take longer can request a larger window explicitly.
  
  Depends on #28683.
  
  ## What changed
  
  - Add optional `connectTimeoutMs` to `EnvironmentAddParams` and document
  it in the app-server README.
  - Pass the optional timeout through `EnvironmentRequestProcessor` into
  one `EnvironmentManager::upsert_environment()` path; the manager applies
  the existing default when it is omitted.
  - Preserve the existing single-attempt lifecycle. The configured value
  controls WebSocket connection and handshake time for both initial
  connection and later reconnects; initialization retains its separate
  timeout.
  - Add an app-server integration test that sends the real JSON-RPC
  request and verifies a stalled handshake observes the requested timeout.
  
  ## Test plan
  
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-exec-server`
  - `just test -p codex-app-server
  environment_add_applies_connect_timeout`
  
  ## Rollout
  
  This is additive and does not enable `deferred_executor`. Callers should
  send a non-default timeout only after a compatible app-server is
  deployed; omitted or `null` values retain the existing 10-second
  default.

  sayan-oai · 2026-06-19 05:27:45 +00:00
  f886e33e5a
• [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
• core: load AGENTS.md from foreign environments (#28958)

  ## Why
  
  Make it possible to load AGENTS.md from remote exec-servers whose OS is
  different than app-server.
  
  ## What
  
  - keep `AGENTS.md` discovery and provenance as `PathUri`, with
  root-aware parent and ancestor traversal
  - expose lifecycle instruction sources as legacy app-server path strings
  in events while retaining `PathUri` internally
  - preserve and test mixed POSIX and Windows paths in model context and
  TUI status output
  - cover remote Windows loading end to end by seeding the Wine prefix
  through host filesystem APIs
  - fix bug in `PathUri`'s parent() implementation that would erase
  Windows drive letters

  Adam Perry @ OpenAI · 2026-06-18 15:06:23 -07:00
  dce673905a
• [codex] Initialize exec-server OpenTelemetry at startup (#25019)

  ## Summary
  
  - Initialize stderr tracing and the configured OpenTelemetry provider
  for local and remote `codex exec-server` startup.
  - Instrument the local and remote server entrypoints with a root runtime
  span.
  - Keep raw Noise environment, registration, and stream identifiers out
  of exported spans while preserving them in local debug events.
  - Keep telemetry setup in a focused CLI module instead of growing the
  top-level command entrypoint.
  
  ## Stack
  
  - Previous: none (`#27058` has merged)
  - Next: #27466
  
  ## Validation
  
  - `just test -p codex-exec-server --lib` (139 passed)
  - `just test -p codex-cli --test exec_server` (3 passed)
  - `just bazel-lock-check`
  - `just fix -p codex-exec-server -p codex-cli`
  - `just fmt`
  
  ---------
  
  Co-authored-by: Richard Lee <richardlee@openai.com>

  starr-openai · 2026-06-18 11:03:42 -07:00
  4c7228e423
• 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
• Add network environment ID plumbing (#28766)

  ## Why
  
  Prepare network approval scoping to distinguish execution environments
  without changing behavior yet.
  
  ## What changed
  
  - Add optional environment IDs to network policy requests.
  - Add optional network environment IDs to exec and sandbox request
  structs.
  - Thread default None values through existing construction points.
  - Fix stale constructor call sites that caused the CI compile failures.
  
  ## Not included
  
  - Per-environment proxy listeners.
  - Network approval cache or prompt behavior changes.
  - Ambiguous request attribution handling.
  
  Those behavior changes moved to stacked follow-up #28899.
  
  ## Validation
  
  - just fmt
  - CI will run tests and clippy

  jif · 2026-06-18 14:09:38 +02:00
  0369b24d54
• Refresh signed exec-server URLs on reconnect (#28374)

  ## Summary
  
  - add a provider API that supplies a fresh signed WebSocket URL for each
  remote exec-server connection
  - refresh the signed URL after disconnects and retry once when a
  handshake returns `401 Unauthorized`
  - allow `EnvironmentManager` consumers to register remote environments
  backed by the URL provider
  
  ## Tests
  
  - `just test -p codex-exec-server -E
  'test(remote_websocket_client_refreshes_url_after_unauthorized_handshake)
  | test(remote_websocket_client_refreshes_url_after_disconnect)'` — 2
  passed
  - `cargo check -p codex-core-api` — passed
  - `just fix -p codex-exec-server` — passed
  - `just fix -p codex-core-api` — no test targets; no-op
  - `just fmt` — passed
  - `just test -p codex-exec-server` — 187 passed; 32 unrelated macOS
  sandbox tests could not invoke nested `sandbox-exec` (`Operation not
  permitted`)

  Anton Panasenko · 2026-06-17 20:58:48 -07:00
  ac3fe64100
• feat(exec-server): add Noise rendezvous environment (#28774)

  ## Why
  
  Codex can run a remote exec server through the Noise relay, but the
  normal
  environment-manager path could not establish an
  environment-registry-backed
  harness connection. Signed rendezvous URLs and harness authorizations
  are
  short-lived, so reconnects must fetch a fresh bundle instead of
  retaining
  stale connection credentials. A stalled registry request must also fail
  within
  the regular remote connection deadline, without exposing these
  credentials in
  debug logs.
  
  Issue: N/A (internal environment-service integration).
  
  ## What Changed
  
  - Add environment-manager configuration for a registry-backed Noise
  rendezvous
    environment.
  - Request a fresh bundle from
  `/cloud/environment/{environment_id}/connect` for every physical harness
    connection, using the existing 10-second remote connection timeout.
  - Share the Environment Registry register, connect, and validate wire
  payloads
    through `codex-exec-server` and `codex-core-api`.
  - Redact the signed rendezvous URL and harness authorization from the
  public
    connect response's `Debug` output.
  - Add focused coverage for registry bundle retrieval, stalled requests,
  and
    credential redaction.

  Anton Panasenko · 2026-06-17 17:20:53 -07:00
  c274a83f8b
• exec-server: expose environment registry payloads (#28651)

  ## Why
  
  Services that proxy the exec-server environment registry endpoints need
  to deserialize and forward the same Noise registration and harness-key
  validation payloads. Those wire models currently live as private,
  serialize-only structs in `exec-server`, which forces consumers to
  duplicate the contract.
  
  ## What changed
  
  - Add owned serde models for registration and harness-key validation
  requests and responses.
  - Use those models in the existing exec-server registry client.
  - Re-export the models from `codex-exec-server` and `codex-core-api`.
  - Keep the harness authorization request free of a derived `Debug`
  implementation so it is not accidentally logged.
  
  ## Testing
  
  - Focused exec-server registration and harness-key validation tests: 2
  passed.
  - `cargo check -p codex-core-api`
  
  The full `codex-exec-server` suite compiled and ran 254 tests: 222
  passed, while 32 existing filesystem sandbox tests could not run under
  the nested macOS sandbox (`sandbox_apply: Operation not permitted`).
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-06-17 13:27:25 -07:00
  a0586ad12d
• unified-exec: preserve PathUri through exec-server (#28681)

  ## Why
  
  It should be possible for app-server to handle "foreign" OS paths in
  unified_exec working directories, allowing e.g. a Linux app-server to
  run processes on e.g. a Windows exec-server.
  
  ## What
  
  Convert the core unified_exec cwd values to use `PathUri`.
  
  Adds fallible path conversion in several places to try to minimize the
  scope of this change. The only time this change suppresses errors from
  converting `PathUri` to an `AbsolutePathBuf` is when the turn is
  configured with no sandboxing at all to allow us to make progress
  testing without sandboxing.
  
  Future changes to apply_patch and sandboxing will clean up these error
  paths.
  
  A tool's cwd is resolved from joining a model-provided workdir to the
  environment's cwd. When using `AbsolutePathBuf::join()`, an
  absolute-path workdir would overwrite the environment's cwd and we would
  resolve permissions/sandboxing against the model-provided path. This
  change extends `PathUri::join()` to also treat an absolute rhs as an
  override of the base/lhs.
  
  This also removes some coverage from the remove_env_windows tests until
  a follow-up converts foreign paths in command exec events correctly.
  
  ## Breaking Changes
  
  When using `AbsolutePathBuf::join()` for workdir resolution, we ended up
  resolving tilde-prefixed paths against the app-server's `$HOME`, e.g.
  `~/foo/bar` becomes `/home/anp/foo/bar`. It's difficult to do this with
  `PathUri` joining, so after offline discussion this PR no longer
  implements it.
  
  A quick check of some power users' rollouts suggests that models don't
  actually generate home-prefixed absolute working directories for their
  spawns, so this shouldn't have any real blast radius.

  Adam Perry @ OpenAI · 2026-06-17 19:36:16 +00:00
  5867b529ae
• 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
• Back off registry retries during exec recovery (#28546)

  ## Why
  
  PR #28512 retries a failed session recovery every 100 ms. Every Noise
  recovery attempt first asks the environment registry for a fresh
  connection bundle, even when the eventual failure comes from the
  WebSocket or initialize handshake. During an outage, that could make
  each disconnected client call the registry about 250 times during the
  25-second recovery window.
  
  ## What changes
  
  All retryable Noise recovery failures now use a separate backoff
  schedule:
  
  ```text
  base:    500 ms -> 1 s -> 2 s -> 4 s -> 5 s maximum
  actual:  500-750 ms, 1-1.5 s, 2-3 s, 4-6 s, 5-7.5 s
  ```
  
  The extra 0-50% is deterministic per-session jitter so disconnected
  clients do not retry together. Direct WebSocket recovery keeps the
  existing 100 ms retry because it does not re-enter the registry.

  jif · 2026-06-17 11:52:23 +02:00
  a5229e0686
• 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
• path-uri: clarify invalid host path errors (#28473)

  ## Why
  
  Ensure a consistent string format when exposing path conversion errors
  to the model.
  
  ## What
  
  - Render `PathUriParseError::InvalidFileUriPath` as `'$PATH' is invalid
  on '$OS'`.

  Adam Perry @ OpenAI · 2026-06-16 09:03:44 -07:00
  7162030b37
• [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
• Run core integration tests against a Wine-backed Windows executor (#28401)

  ## Why
  
  We want to exercise a linux app-server against a windows exec-server
  without having to repeat every test case. This approach has slight
  precedent in the remote docker test setup.
  
  ## What
  
  Run the shared `codex-core` integration suite against Windows
  exec-server behavior from Linux. This makes cross-OS path and shell
  regressions visible while keeping unsupported cases owned by individual
  tests.
  
  - Add `local`, `docker`, and `wine-exec` test environment selection with
  legacy Docker compatibility.
  - Extend `codex_rust_crate` to generate a sharded Wine-exec variant
  using a cross-built Windows server and pinned Bazel Wine/PowerShell
  runtimes.
  - Teach remote-aware helpers about Windows paths and track temporary
  incompatibilities with source-local `skip_if_wine_exec!` calls and
  follow-up reasons.

  Adam Perry @ OpenAI · 2026-06-16 00:38:41 +00:00
  1fe89de576
• 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
• exec-server: add Noise relay transport (#26242)

  ## Why
  
  Rendezvous forwards traffic between the orchestrator and exec-server.
  The endpoints need to authenticate each other and encrypt that traffic
  without trusting Rendezvous with plaintext or endpoint keys.
  
  ## Changes
  
  - Adds a hybrid Noise IK channel through Clatter using X25519,
  ML-KEM-768, AES-256-GCM, and SHA-256.
  - Binds each handshake to `environment_id`, `executor_registration_id`,
  and `stream_id`.
  - Pins the registry-provided executor key and carries the harness
  authorization inside the encrypted handshake.
  - Orders relay frames before consuming Noise nonces and fragments large
  JSON-RPC messages into bounded records.
  - Bounds handshake payloads, frames, streams, and message reassembly.
  
  Runtime activation is in
  [openai/codex#26245](https://github.com/openai/codex/pull/26245).
  
  ## 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`
  - Oversized initiator payload regression coverage
  - `just fix -p codex-exec-server`
  - `just bazel-lock-check`
  - `cargo shear`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-06-15 16:39:41 -07:00
  428cd44154
• chore: restore exec-server relay keepalives (#28286)

  ## Why
  
  The ws pump refactor removed the relay keepalive timers that had been
  added to keep idle rendezvous connections alive. An idle relay could
  therefore be closed by the rendezvous service or a load balancer,
  disconnecting executor-backed MCP processes.
  
  ## What
  
  - restore periodic WebSocket ping frames on both rendezvous relay
  endpoints
  - keep missed-tick behavior bounded with `MissedTickBehavior::Skip`
  - cover the harness and remote-environment pumps with focused
  traffic-after-keepalive tests

  jif · 2026-06-15 17:24:36 +02:00
  bbcfed8ac2
• [codex] exec-server honors remote environment cwd and shell (#28122)

  ## Why
  
  Next slice needed to make progress on the `remote_env_windows` test is
  to support passing a Windows cwd for the remote environment and using
  that environment's native shell. This lets the test run a real Windows
  process instead of only recording an early path or shell mismatch.
  
  ## What
  
  - change `TurnEnvironmentSelection.cwd` from `AbsolutePathBuf` to
  `PathUri`
  - convert local cwd values to URIs when constructing selections
  - preserve a remote primary cwd instead of replacing it with the local
  legacy fallback
  - prefer the selected environment's discovered shell for unified exec,
  falling back to the session shell when unavailable
  - convert back to a host-native absolute path at current native-only
  consumer boundaries
  - reject or deny unsupported foreign cwd values at the existing
  request-permissions boundary, with TODOs for its future migration
  - extend the hermetic Wine test to execute Windows PowerShell in
  `C:\windows` and verify successful process completion
  - record the current app-server rejection against the same Wine-backed
  remote Windows fixture when its cwd is supplied as a native Windows path

  Adam Perry @ OpenAI · 2026-06-14 06:07:46 +00:00
  efbd00f21f
• build: run buildifier from just fmt (#28125)

  ## Intent
  
  Keep Bazel and Starlark files consistently formatted without requiring
  contributors to install or version buildifier themselves.
  
  ## Implementation
  
  - Add a SHA-256-pinned, cross-platform DotSlash manifest for buildifier
  v8.5.1.
  - Run buildifier from the shared `just fmt` and `just fmt-check` driver,
  with Windows-safe explicit DotSlash invocation.
  - Provision DotSlash in formatting CI and contributor devcontainers, and
  document the source-build prerequisite.
  - Apply the initial mechanical buildifier formatting baseline.

  Adam Perry @ OpenAI · 2026-06-13 21:43:39 -07:00
  740c4f269d
• [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 hermetic Wine exec-server test (#27937)

  ## Why
  
  We want to make it possible for an app-server orchestrator on one OS to
  control an exec-server on another host running a different OS. In
  practice this kinda already works if you get lucky and the two hosts
  have the same path format, but we mangle quite a lot of operations if
  either end is Windows.
  
  This test starts exercising that interaction, although right now the
  initial bootstrap fails. Future changes will expand the test's
  assertions to match improved support.
  
  ## What
  
  Stacked on #27964. This adds a small Windows exec-server fixture and a
  Linux protocol smoke test using the reusable Wine harness, covering
  Windows environment discovery, non-TTY `cmd.exe` execution, output, exit
  status, and working directory.
  
  Once we've got the full codex binary cross-building under Bazel we could
  consider moving to the real binary instead of the stripped down
  exec-server-only binary used here.

  Adam Perry @ OpenAI · 2026-06-12 20:20:23 -07:00
  9d938a46d9
• [codex] make PathUri::from_abs_path infallible (#27976)

  ## Why
  
  `PathUri::from_abs_path` can fail for absolute paths that do not have a
  normal `file:` URI representation, forcing filesystem call sites to
  handle a conversion error even though the original path can be preserved
  losslessly.
  
  ## What
  
  Make `from_abs_path` infallible and migrate its callers. Unrepresentable
  paths use `file:///%00/bad/path/<base64>`, encoding Unix bytes or
  Windows UTF-16LE; `to_abs_path` validates and decodes that fallback. The
  leading encoded null reserves a namespace that cannot collide with a
  real Unix or Windows path, and fallback URIs remain opaque to lexical
  path operations.
  
  ## Validation
  
  Added path-URI coverage for Unix null and non-UTF-8 paths, Windows
  device/verbatim and non-Unicode paths, serialization, malformed
  fallbacks, opaque lexical operations, invalid native payloads, and
  literal `/bad/path` collision resistance.

  Adam Perry @ OpenAI · 2026-06-12 16:58:42 -07:00
  968a3ac9c1
• [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
• sandboxing: migrate cwd inputs to PathUri (#27816)

  ## Why
  
  Sandbox cwd values can cross app-server and exec-server host boundaries.
  They should retain URI semantics until the receiving host validates them
  instead of being interpreted early as native paths.
  
  ## What
  
  - Carry `PathUri` through filesystem sandbox contexts, sandbox commands,
  and transform inputs.
  - Convert command and policy cwd once in `SandboxManager::transform`,
  then keep launch requests native.
  - Preserve sandbox cwd over remote filesystem transport and reject
  non-native URIs without fallback.
  - Cache paired native/URI turn-environment cwd values during migration,
  with immutable access to keep them synchronized.
  - Extend existing protocol, forwarding, transform, and core runtime
  tests.

  Adam Perry @ OpenAI · 2026-06-12 11:38:01 -07:00
  52a50aec70
• [codex] Remove async_trait from first-party code (#27475)

  ## Why
  
  First-party async traits should expose their `Send` contracts explicitly
  without requiring `async_trait`. This completes the migration pattern
  established in #27303 and #27304.
  
  ## What changed
  
  - Replaced the remaining first-party `async_trait` traits with native
  return-position `impl Future + Send` where statically dispatched and
  explicit boxed `Send` futures where object safety is required.
  - Kept implementations behavior-preserving, outlining existing async
  bodies into inherent methods where that keeps the diff reviewable.
  - Removed all direct first-party `async-trait` dependencies and the
  workspace dependency declaration.
  - Added a cargo-deny policy that permits `async-trait` only through the
  remaining transitive wrapper crates.
  - Updated `rand` from 0.8.5 to 0.8.6 to resolve RUSTSEC-2026-0097 and
  keep the full cargo-deny check passing.
  
  ## Validation
  
  - `just test -p codex-exec-server`: 216 passed, 2 skipped.
  - `just test -p codex-model-provider`: 39 passed.
  - `just test -p codex-core` and `just test`: changed tests passed;
  remaining failures are environment-sensitive suites unrelated to this
  migration.
  - `cargo deny check`
  - `just fix`
  - `just fmt`
  - `cargo shear`
  - `just bazel-lock-check`

  Adam Perry @ OpenAI · 2026-06-11 18:16:39 -07:00
  5a56caf18c
• Remove fs/join and fs/parent from exec-server protocol (#27700)

  ## Summary
  
  Path composition is already handled by `PathUri`, leaving `fs/join` and
  `fs/parent` as redundant exec-server protocol surface. Because
  app-server and exec-server are deployed atomically, these obsolete
  methods can be removed without a compatibility shim.
  
  This removes the protocol constants and payloads, public client APIs,
  server registrations and handlers, and endpoint-only tests. Existing
  in-process `PathUri` join/parent coverage remains.
  
  ## Validation
  
  - `just test -p codex-exec-server` (215 passed, 2 skipped)

  Adam Perry @ OpenAI · 2026-06-11 15:48:53 -07:00
  e069153f2a
• [codex] migrate exec-server filesystem protocol to PathUri (#27653)

  Exec-server filesystem calls should preserve cross-platform `file:` URIs
  across the remote boundary instead of converting them through paths
  native to the client host.
  
  This changes the exec-server filesystem protocol DTOs to use `PathUri`,
  carries those values directly through remote and sandbox-helper
  transports, and keeps legacy native absolute-path request strings
  readable for compatibility. It also updates protocol documentation and
  coverage for URI serialization and non-native URI forwarding.

  Adam Perry @ OpenAI · 2026-06-11 15:09:12 -07:00
  d23bb22f25
• [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] remove EnvironmentPathRef (#27433)

  We're switching to using a static encoding of the host path in
  `PathUri`. We may need a type like this again but we can add it when
  it's more compelling.
  
  Stacked on #27454.

  Adam Perry @ OpenAI · 2026-06-11 18:26:12 +00:00
  4a05d3b282
• [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
• exec-server: add environment path refs (#25121)

  ## Summary
  - add public `codex_exec_server::EnvironmentPathRef`
  - bind an absolute path to its owning executor filesystem
  - keep path operations in the next review slice
  
  ## Stack
  - 1/5 in the skills path authority stack extracted from
  https://github.com/openai/codex/pull/25098
  
  ## Validation
  - `cd /Users/starr/code/codex-worktrees/pr-25098-restack4/codex-rs &&
  just fmt`
  - GitHub CI pending on rewritten head

  starr-openai · 2026-06-01 10:55:52 -07:00
  fb94703b21
• exec-server: preserve fs helper CoreFoundation env (#25118)

  ## Summary
  - preserve macOS `__CF_USER_TEXT_ENCODING` when launching the sandboxed
  fs helper
  - keep the fs-helper env narrow; this adds only the CoreFoundation
  startup var instead of copying the broader MCP stdio baseline
  - add focused coverage that the helper keeps that var without admitting
  `HOME`
  
  ## Diagnosis
  The sandboxed fs helper is not launched like a normal child process.
  Exec-server rebuilds its environment from an allowlist, then calls
  `env_clear()` before re-execing Codex with `--codex-run-as-fs-helper`.
  That helper dispatches before the normal Codex startup path and only
  needs to boot a small Tokio runtime, read one JSON request from stdin,
  perform the direct filesystem operation, and write one JSON response.
  
  The reported macOS hang sampled the helper before Rust main, in
  CoreFoundation initialization while resolving the default text encoding:
  `_CFStringGetUserDefaultEncoding -> getpwuid_r -> notify_register_check
  -> bootstrap_look_up3 -> mach_msg2_trap`. The fs-helper allowlist kept
  `PATH` and temp vars for runtime needs, but it dropped macOS
  `__CF_USER_TEXT_ENCODING`. Other Codex subprocess launchers that
  intentionally build a minimal Unix baseline, such as MCP stdio, already
  preserve that variable.
  
  My read is that stripping `__CF_USER_TEXT_ENCODING` forced this internal
  helper down CoreFoundation's fallback user-lookup path, and that lookup
  intermittently wedged on the affected machine before the helper could
  read stdin or touch the target file. Preserving only this macOS startup
  variable avoids that fallback without broadening the fs-helper
  environment to shell-like vars such as `HOME`, `USER`, locale settings,
  terminal settings, or proxy credentials.
  
  Internal Slack thread omitted from the public PR body.
  
  ## Validation
  - `cd codex-rs && just fmt`
  - `git diff --check`

  starr-openai · 2026-05-29 12:20:17 -07:00
  a717e4ef31
• [exec-server] Kill dropped filesystem helpers (#25116)

  ## Summary
  - terminate sandbox filesystem helpers when the Tokio child handle is
  dropped
  
  ## Why
  A sandbox filesystem helper can stall during process startup before
  reading stdin. If the owning async operation is cancelled or torn down,
  the spawned helper should not remain running as an orphaned process.
  
  Setting `kill_on_drop(true)` gives the filesystem helper the cleanup
  behavior that Tokio child processes otherwise do not enable by default.
  
  This intentionally does not add a timeout. It does not detect or recover
  an active hung file edit while the owning future remains alive. A more
  precise startup-health mechanism can be handled separately.
  
  ## Validation
  - `just test -p codex-exec-server` (186 tests passed; benchmark smoke
  passed)
  - `just fmt`
  - `just fix -p codex-exec-server`
  - `git diff --check`

  Eric Horacek · 2026-05-29 11:40:44 -07:00
  451b386442
• feat: Add focused diagnostics for MCP HTTP send failures (#25013)

  Adds failure-only logging for MCP streamable HTTP post_message calls and
  the underlying reqwest send path, capturing the MCP method/request id,
  endpoint shape, auth-header presence, timeout/connect classification,
  and sanitized error source chain without logging headers, bodies,
  tokens, or full URLs.

  xl-openai · 2026-05-29 10:09:33 -07:00
  e29bbb5368
• 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
• Allow API-key auth for remote exec-server registration (#24666)

  ## Overview
  Allow remote `codex exec-server` registration to use existing API-key
  auth while restricting where those credentials can be sent.
  
  - Accept `CodexAuth::ApiKey` for the normal `--remote` registration
  path.
  - Restrict API-key remote registration to HTTPS `openai.com` and
  `openai.org` hosts and subdomains, with explicit HTTP loopback support
  for local development.
  - Disable registry registration redirects so credentials cannot be
  forwarded to an unvalidated destination.
  - Retain `--use-agent-identity-auth` as the explicit Agent Identity
  path.
  - Document remote registration using `CODEX_API_KEY`.
  
  ## Big picture
  Callers can now provide an API key directly to `exec-server`
  registration without first establishing ChatGPT login state:
  
  ```sh
  CODEX_API_KEY="$OPENAI_API_KEY" \
  codex exec-server \
    --remote "https://<host>.openai.org/api" \
    --environment-id "$ENVIRONMENT_ID"
  ```
  
  ## Validation
  - `cargo fmt --all` (`just fmt` is not installed on this host)
  - `cargo test -p codex-cli -p codex-exec-server`

  Steve Coffey · 2026-05-27 21:17:38 +00:00
  c57dee98b7
• Uprev Rust toolchain pins to 1.95.0 (#24684)

  ## Summary
  - Bump the workspace Rust toolchain from `1.93.0` to `1.95.0` across
  Cargo, Bazel, CI, release workflows, devcontainers, and the Codex
  environment config.
  - Refresh `MODULE.bazel.lock` so the Bazel Rust toolchain artifacts
  match the new version.
  - Leave purpose-specific toolchains unchanged, including the
  `argument-comment-lint` nightly and the upstream `rusty_v8` `1.91.0`
  build pin.
  - Includes fixes for new lints from `just fix` and a few codex-authored
  fixes for lints without a suggestion.

  Adam Perry @ OpenAI · 2026-05-26 20:59:47 -07:00
  cca1e0ba1d
• Reconnect disconnected exec-server websocket clients with fresh sessions (#23867)

  ## Summary
  - replace the one-shot lazy remote exec-server cache with a
  lock-protected current client
  - when the cached websocket client is already disconnected, create one
  fresh websocket client/session on the next `get()`
  - keep existing disconnect failure behavior for old process sessions and
  HTTP body streams; do not add session resume or request retry
  
  ## Why
  The prior PR direction was trying to grow into session restore: resume
  the old `session_id`, preserve existing process handles, and add
  reconnect retry policy. That is more machinery than we want for this
  slice.
  
  For now, the useful minimum is simpler: later fresh remote operations
  should not be stuck behind a dead cached websocket client, but anything
  already attached to the dead connection should fail loudly through the
  existing disconnect path. The server already has detached-session
  cleanup via its existing TTL, so this PR does not need to add
  client-side session preservation.
  
  ## What Changed
  - `LazyRemoteExecServerClient::get()` now keeps the current concrete
  client in a small mutex-protected cache plus one async connect lock.
  - If that cached client is still connected, `get()` returns it.
  - If that cached websocket client has observed the transport close,
  `get()` creates a brand-new websocket client with a brand-new
  exec-server session and replaces the cache.
  - If that cached client is stdio-backed, behavior stays one-shot: the
  dead client is returned and later work surfaces the existing disconnect
  error.
  - No `resume_session_id`, backoff, request replay, or existing
  `RemoteExecProcess` rebinding is added here.
  - Added focused websocket coverage that proves two concurrent `get()`
  calls after disconnect share one fresh replacement client/session.

  starr-openai · 2026-05-21 18:43:45 +02:00
  de80fa6e31
• 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