160 Commits

• [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
• Refactor exec-server websocket pump (#23327)

  ## Why
  Exec-server websocket handling had separate reader and writer tasks for
  the same socket. That made websocket control-frame handling asymmetric:
  the task reading frames could observe `Ping`, but the task allowed to
  write frames was elsewhere. This PR moves each physical websocket onto
  one always-running pump so the socket owner can handle application
  frames and websocket control frames together.
  
  ## What changed
  - Refactored direct exec-server websocket connections in `connection.rs`
  to use one task that owns the websocket for outbound JSON-RPC, inbound
  JSON-RPC, periodic keepalive pings, and `Ping` -> `Pong` replies.
  - Refactored relay websocket handling in `relay.rs` the same way for
  both the harness-side logical connection and the multiplexed executor
  physical socket.
  - Preserved the existing keepalive ownership policy: outbound direct
  websocket clients still send periodic pings, inbound Axum accepts only
  reply with pongs, and relay physical websocket endpoints keep their
  existing periodic pings.
  - Added focused websocket pump tests for ping/pong, binary JSON-RPC,
  relay data, malformed relay text frames, and close/disconnect behavior.
  - Reconnect behavior is intentionally left for a follow-up.
  
  ## Validation
  - Devbox Bazel focused unit target:
  - `//codex-rs/exec-server:exec-server-unit-tests
  --test_filter='websocket_connection_|harness_connection_|multiplexed_executor_'`

  starr-openai · 2026-05-19 13:31:57 -07:00
  83af3abc68
• Make local environment optional in EnvironmentManager (#23369)

  ## Summary
  - make `EnvironmentManager` local environment/runtime paths optional
  - simplify constructor surface around snapshot materialization
  - rename local env accessors to `require_local_environment` /
  `try_local_environment`
  
  ## Validation
  - devbox Bazel build for touched crate surfaces
  - `//codex-rs/exec-server:exec-server-unit-tests`
  - `//codex-rs/app-server-client:app-server-client-unit-tests`
  - filtered touched `//codex-rs/core:core-unit-tests` cases

  starr-openai · 2026-05-19 12:55:34 -07:00
  5c43a64e2b
• Add exec-server websocket keepalive (#23226)

  ## Summary
  - send periodic websocket Ping frames from outbound exec-server
  websocket clients
  - cover direct exec-server websocket clients plus rendezvous
  harness/executor websocket connections
  - keep inbound axum-accepted exec-server websocket connections passive
  - add focused keepalive coverage for direct and relay websocket paths
  
  ## Validation
  - /Users/starr/code/openai/project/dotslash-gen/bin/bazel test
  //codex-rs/exec-server:exec-server-unit-tests
  --test_filter='websocket_connection_sends_keepalive_ping|harness_connection_sends_keepalive_ping|multiplexed_executor_sends_keepalive_ping'
  - /Users/starr/code/openai/project/dotslash-gen/bin/bazel test
  //codex-rs/exec-server:exec-server-relay-test
  --test_filter=multiplexed_remote_executor_routes_independent_virtual_streams

  starr-openai · 2026-05-18 03:07:32 +00:00
  64ead6a83a
• 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
• Fix remote environment test fixtures (#22572)

  ## Why
  The Docker remote-env coverage was failing before it reached the
  behavior those tests are meant to exercise. The remote-aware test
  fixture only registered the remote environment, so tests that
  intentionally select both `local` and `remote` could not start a turn.
  After that was fixed, two tests exposed stale fixtures: the approval
  test was auto-approving under workspace-write, and the remote
  `view_image` test was writing invalid PNG bytes.
  
  ## What Changed
  - Added `EnvironmentManager::create_for_tests_with_local(...)` so tests
  can keep the provider default while also selecting `local` explicitly.
  - Updated `build_remote_aware()` to use that test-only manager when a
  remote exec-server URL is present.
  - Changed the remote apply-patch approval helper to use
  `SandboxPolicy::new_read_only_policy()` so the test actually exercises
  approval caching per environment.
  - Replaced the hardcoded remote `view_image` PNG blob with the existing
  `png_bytes(...)` helper so the test uses a valid image fixture.
  
  ## Validation
  Ran these isolated Docker remote-env tests on the devbox with
  `$remote-tests` setup:
  -
  `suite::remote_env::apply_patch_freeform_routes_to_selected_remote_environment`
  -
  `suite::remote_env::apply_patch_approvals_are_remembered_per_environment`
  -
  `suite::remote_env::apply_patch_intercepted_exec_command_routes_to_selected_remote_environment`
  -
  `suite::remote_env::exec_command_routes_to_selected_remote_environment`
  - `suite::view_image::view_image_routes_to_selected_remote_environment`
  
  All five pass.

  starr-openai · 2026-05-14 12:40:01 -07:00
  255748638c
• 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
• fix(exec-server): suppress Windows taskkill output (#22058)

  ## Summary
  
  This is the `exec-server` follow-up to #21759.
  
  #21759 fixed the Windows `taskkill` output leak for the `rmcp-client`
  MCP teardown path, but #22050 showed that `exec-server` still had a
  parallel `taskkill /T /F` cleanup path in
  `exec-server/src/connection.rs`. Because that command inherited the
  parent stdio handles, Windows could still print `SUCCESS:` lines into
  the user's terminal during stdio child cleanup.
  
  This change silences that remaining `exec-server` callsite by
  redirecting `taskkill` stdin, stdout, and stderr to `Stdio::null()`.
  
  ## What Changed
  
  - add a Windows-only `Stdio` import in `exec-server/src/connection.rs`
  - redirect the `taskkill` command in `kill_windows_process_tree` to
  `Stdio::null()` for stdin, stdout, and stderr
  - keep the existing kill semantics unchanged by still checking
  `.status()` and preserving the existing fallback/logging behavior
  
  ## How to Test
  
  Manual validation is Windows-only, so I did not run the UI repro path
  locally here.
  
  1. On Windows, use a Codex build from this branch.
  2. Exercise an `exec-server` stdio flow that spawns a child process tree
  and then triggers transport cleanup.
  3. Confirm the child process tree is still torn down.
  4. Confirm the terminal no longer shows `SUCCESS: The process with PID
  ... has been terminated.` lines during cleanup.
  
  Targeted tests:
  - `cargo test -p codex-exec-server
  client::tests::dropping_stdio_client_terminates_spawned_process --
  --exact`
  - `cargo test -p codex-exec-server
  client::tests::malformed_stdio_message_terminates_spawned_process --
  --exact`
  
  Notes:
  - `cargo test -p codex-exec-server` still hits unrelated local macOS
  `sandbox-exec: sandbox_apply: Operation not permitted` failures in
  `tests/file_system.rs`.
  
  ## References
  
  - Fixes the remaining callsite discussed in #22050
  - Related earlier fix: #21759

  Felipe Coury · 2026-05-11 15:40:56 -03:00
  90bd445e7f
• 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
• Increase exec-server environment transport timeouts (#21825)

  ## Why
  
  The environment-backed exec-server transport currently hardcodes 5
  second connect and initialize timeouts in `client_transport.rs`. That is
  short for SSH-backed stdio environments and remote websocket
  environments, and there is currently no way to raise those values from
  `CODEX_HOME/environments.toml`.
  
  This stacked follow-up raises the default environment transport timeouts
  and lets each configured environment override them in
  `environments.toml`.
  
  ## What Changed
  
  - raise the default environment transport connect and initialize
  timeouts from 5s to 10s
  - store concrete timeout values on `ExecServerTransportParams` instead
  of hardcoding them in `connect_for_transport(...)`
  - add `connect_timeout_sec` and `initialize_timeout_sec` to
  `[[environments]]` entries in `environments.toml`
  - apply parse-time defaults so runtime transport code receives fully
  resolved timeout values
  - reject `connect_timeout_sec` on stdio environments because it only
  applies to websocket transports
  - extend parser tests to cover the new fields and defaults
  
  ## Stack
  
  - base: https://github.com/openai/codex/pull/21794
  - this PR: configurable environment transport timeouts
  
  ## Validation
  
  - `cd
  /Users/starr/code/codex-worktrees/exec-env-timeouts-config-20260508/codex-rs
  && just fmt`
  - not run: tests
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-08 16:33:29 -07:00
  faa5d4a5e2
• [codex] support executor registry remote environments (#21323)

  ## Summary
  
  Support registry-backed remote executors end to end so downstream
  services can resolve an executor id into an exec-server URL and make
  that environment available to Codex without relying on the legacy cloud
  environments flow.
  
  ## What changed
  
  - switch remote executor registration to the executor registry bootstrap
  contract
  - allow named remote environments to be inserted into
  `EnvironmentManager` at runtime
  - add the experimental app-server RPC `environment/add` so initialized
  experimental clients can register those remote environments for later
  `thread/start` and `turn/start` selection
  
  ## Validation
  
  Ran focused validation locally:
  - `cargo test -p codex-exec-server environment_manager_`
  - `cargo test -p codex-exec-server
  register_executor_posts_with_bearer_token_header`
  - `cargo test -p codex-app-server-protocol`

  Michael Zeng · 2026-05-08 16:30:07 -07:00
  8f4020846e
• Make environment provider snapshots path-free (#21794)

  ## Summary
  - make EnvironmentProvider::snapshot path-free and keep providers
  focused on provider-owned remote environments
  - let provider snapshots request local inclusion via include_local, with
  environments.toml including local and CODEX_EXEC_SERVER_URL excluding
  local
  - move reserved local environment construction into EnvironmentManager
  using ExecServerRuntimePaths
  
  Follow-up to https://github.com/openai/codex/pull/20667
  
  ## Testing
  - just fmt
  - git diff --check
  - devbox: bazel build --bes_backend= --bes_results_url=
  //codex-rs/exec-server:exec-server
  - devbox: bazel test --bes_backend= --bes_results_url=
  //codex-rs/exec-server:exec-server-unit-tests
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-08 15:30:00 -07:00
  dac108f2f1
• Enable --deny-warnings for cargo shear (#21616)

  ## Summary
  
  In https://github.com/openai/codex/pull/21584, we disabled doctests for
  crates that lack any doctests. We can enforce that property via `cargo
  shear --deny-warnings`: crates that lack doctests will be flagged if
  doctests are enabled, and crates with doctests will be flagged if
  doctests are disabled.
  
  A few additional notes:
  
  - By adding `--deny-warnings`, `cargo shear` also flagged a number of
  modules that were not reachable at all. Some of those have been removed.
  - This PR removes a usage of `windows_modules!` (since `cargo shear` and
  `rustfmt` couldn't see through it) in favor of simple `#[cfg(target_os =
  "windows")]` macros. As a consequence, many of these files exhibit churn
  in this PR, since they weren't being formatted by `rustfmt` at all on
  main.
  - Again, to make the code more analyzable, this PR also removes some
  usages of `#[path = "cwd_junction.rs"]` in favor of a more standard
  module structure. The bin sidecar structure is still retained, but,
  e.g., `windows-sandbox-rs/src/bin/command_runner.rs‎` was moved to
  `windows-sandbox-rs/src/bin/command_runner/main.rs`, and so on.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Charlie Marsh · 2026-05-08 20:29:00 +00:00
  7c9731c9af
• Load configured environments from CODEX_HOME (#20667)

  ## Why
  
  The earlier PRs add stdio transport support and the config-backed
  environment provider, but the feature remains inert until normal Codex
  entrypoints construct `EnvironmentManager` with enough context to
  discover `CODEX_HOME/environments.toml`. This final stack PR activates
  the provider while preserving the legacy `CODEX_EXEC_SERVER_URL`
  fallback when no environments file exists.
  
  **Stack position:** this is PR 5 of 5. It is the product wiring PR that
  activates the configured environment provider added in PR 4.
  
  ## What Changed
  
  - Thread `codex_home` into `EnvironmentManagerArgs`.
  - Change `EnvironmentManager::new(...)` to load the provider from
  `CODEX_HOME`.
  - Preserve legacy behavior by falling back to
  `DefaultEnvironmentProvider::from_env()` when `environments.toml` is
  absent.
  - Make `environments.toml`-backed managers start new threads with all
  configured environments, default first, while keeping the legacy env-var
  path single-default.
  - Update the app-server, TUI, exec, MCP server, connector, prompt-debug,
  and thread-manager-sample callsites to pass `codex_home` and handle
  provider-loading errors.
  
  ## Self-Review Notes
  
  - The multi-environment startup path is intentionally tied to the
  `environments.toml` provider. Using `>1` configured environment as the
  only signal would also expand the legacy `CODEX_EXEC_SERVER_URL`
  provider because it keeps `local` addressable alongside `remote`.
  - The startup environment list is still derived inside
  `EnvironmentManager`; the provider only says whether its snapshot should
  start new threads with all configured environments.
  - The thread-manager sample was updated to pass the current
  `ThreadManager::new(...)` installation id argument so the stack compiles
  under Bazel.
  
  ## Stack
  
  - 1. https://github.com/openai/codex/pull/20663 - Add stdio exec-server
  listener
  - 2. https://github.com/openai/codex/pull/20664 - Add stdio exec-server
  client transport
  - 3. https://github.com/openai/codex/pull/20665 - Make environment
  providers own default selection
  - 4. https://github.com/openai/codex/pull/20666 - Add CODEX_HOME
  environments TOML provider
  - **5. This PR:** https://github.com/openai/codex/pull/20667 - Load
  configured environments from CODEX_HOME
  
  Split from original draft: https://github.com/openai/codex/pull/20508
  
  ## Validation
  
  - `just fmt`
  - `git diff --check`
  - `bazel build --config=remote --strategy=remote
  --remote_download_toplevel
  //codex-rs/thread-manager-sample:codex-thread-manager-sample`
  - `bazel test --config=remote --strategy=remote
  --remote_download_toplevel
  //codex-rs/exec-server:exec-server-unit-tests`
  - `bazel test --config=remote --strategy=remote
  --remote_download_toplevel --test_sharding_strategy=disabled
  --test_arg=default_thread_environment_selections_use_manager_default_id
  //codex-rs/core:core-unit-tests`
  - `bazel test --config=remote --strategy=remote
  --remote_download_toplevel --test_sharding_strategy=disabled
  --test_arg=start_thread_uses_all_default_environments_from_codex_home
  //codex-rs/core:core-unit-tests`
  
  ## Documentation
  
  This activates `CODEX_HOME/environments.toml`; user-facing documentation
  should be added before this stack is treated as a documented public
  workflow.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-08 11:17:56 -07:00
  5f2543b74e
• Add CODEX_HOME environments TOML provider (#20666)

  ## Why
  
  After stdio transports and provider-owned defaults exist, Codex needs a
  config-backed provider that can describe more than the single legacy
  `CODEX_EXEC_SERVER_URL` remote. This PR adds that provider without
  activating it in product entrypoints yet, keeping parser/validation
  review separate from runtime wiring.
  
  **Stack position:** this is PR 4 of 5. It builds on PR 3's
  provider/default model and adds the `environments.toml` provider used by
  PR 5.
  
  ## What Changed
  
  - Add `environment_toml.rs` as the TOML-specific home for parsing,
  validation, and provider construction.
  - Keep the TOML schema/provider structs private; the public constructor
  added here is `EnvironmentManager::from_codex_home(...)`.
  - Add `TomlEnvironmentProvider`, including validation for:
    - reserved ids such as `local` and `none`
    - duplicate ids
    - unknown explicit defaults
    - empty programs or URLs
    - exactly one of `url` or `program` per configured environment
  - Support websocket environments with `url = "ws://..."` / `wss://...`.
  - Support stdio-command environments with `program = "..."`.
  - Add helpers to load `environments.toml` from `CODEX_HOME`, but do not
  wire entrypoints to call them yet.
  - Add the `toml` dependency for parsing.
  
  ## Stack
  
  - 1. https://github.com/openai/codex/pull/20663 - Add stdio exec-server
  listener
  - 2. https://github.com/openai/codex/pull/20664 - Add stdio exec-server
  client transport
  - 3. https://github.com/openai/codex/pull/20665 - Make environment
  providers own default selection
  - **4. This PR:** https://github.com/openai/codex/pull/20666 - Add
  CODEX_HOME environments TOML provider
  - 5. https://github.com/openai/codex/pull/20667 - Load configured
  environments from CODEX_HOME
  
  Split from original draft: https://github.com/openai/codex/pull/20508
  
  ## Validation
  
  Not run locally; this was split out of the original draft stack.
  
  ## Documentation
  
  This introduces the config shape for `environments.toml`; user-facing
  documentation should be added before this stack is treated as a
  documented public workflow.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-08 01:37:47 +00:00
  07b695190f
• Make environment providers own default selection (#20665)

  ## Why
  
  The next PR in this stack introduces configured environments, where the
  provider knows both which environments exist and which one should be
  selected by default. The existing manager derived the default internally
  by checking for the legacy `remote` and `local` ids, and it treated
  "remote" as equivalent to "has a websocket URL." That does not work
  cleanly for stdio-command remotes because they are remote environments
  without an `exec_server_url`.
  
  **Stack position:** this is PR 3 of 5. It is the environment-model
  bridge between PR 2's transport enum and PR 4's TOML provider.
  
  ## What Changed
  
  - Add `DefaultEnvironmentSelection` to the `EnvironmentProvider`
  contract:
    - `Derived` preserves the old `remote`-then-`local` fallback behavior.
  - `Environment(id)` lets a provider explicitly select a configured
  default.
  - `Disabled` lets a provider intentionally expose no default
  environment.
  - Move the legacy `CODEX_EXEC_SERVER_URL=none` default-disabling
  behavior into `DefaultEnvironmentProvider`.
  - Make `EnvironmentManager` validate explicit provider defaults and
  return an error if the selected id is missing.
  - Track `remote_transport` separately from `exec_server_url` so
  stdio-command environments are still recognized as remote.
  - Add `Environment::remote_stdio_shell_command(...)` for the TOML
  provider added in the next PR.
  
  ## Stack
  
  - 1. https://github.com/openai/codex/pull/20663 - Add stdio exec-server
  listener
  - 2. https://github.com/openai/codex/pull/20664 - Add stdio exec-server
  client transport
  - **3. This PR:** https://github.com/openai/codex/pull/20665 - Make
  environment providers own default selection
  - 4. https://github.com/openai/codex/pull/20666 - Add CODEX_HOME
  environments TOML provider
  - 5. https://github.com/openai/codex/pull/20667 - Load configured
  environments from CODEX_HOME
  
  Split from original draft: https://github.com/openai/codex/pull/20508
  
  ## Validation
  
  Not run locally; this was split out of the original draft stack.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-08 01:00:31 +00:00
  9669756b5f
• Add stdio exec-server client transport (#20664)

  ## Why
  
  Configured environments need to connect to exec-server instances that
  are not necessarily already listening on a websocket URL. A
  command-backed stdio transport lets Codex start an exec-server process,
  speak JSON-RPC over its stdio streams, and clean up that child process
  with the client lifetime.
  
  **Stack position:** this is PR 2 of 5. It builds on the server-side
  stdio listener from PR 1 and provides the client transport used by later
  environment/config PRs.
  
  ## What Changed
  
  - Add `ExecServerTransport` variants for websocket URLs and stdio shell
  commands.
  - Add stdio command connection support for `ExecServerClient`.
  - Move websocket/stdio transport setup into `client_transport.rs` so
  `client.rs` stays focused on shared JSON-RPC client, session, HTTP, and
  notification behavior.
  - Tie stdio child process cleanup to the JSON-RPC connection lifetime
  with a RAII lifetime guard.
  - Keep existing websocket environment behavior by adapting URL-backed
  remotes to `ExecServerTransport::WebSocketUrl`.
  
  ## Stack
  
  - 1. https://github.com/openai/codex/pull/20663 - Add stdio exec-server
  listener
  - **2. This PR:** https://github.com/openai/codex/pull/20664 - Add stdio
  exec-server client transport
  - 3. https://github.com/openai/codex/pull/20665 - Make environment
  providers own default selection
  - 4. https://github.com/openai/codex/pull/20666 - Add CODEX_HOME
  environments TOML provider
  - 5. https://github.com/openai/codex/pull/20667 - Load configured
  environments from CODEX_HOME
  
  Split from original draft: https://github.com/openai/codex/pull/20508
  
  ## Validation
  
  Not run locally; this was split out of the original draft stack and then
  refactored to separate transport setup from the base client.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-07 23:48:50 +00:00
  a3de5bde6e