21 Commits

• 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
• Add environment provider snapshot (#20058)

  ## Summary
  - Change `EnvironmentProvider` to return concrete `Environment`
  instances instead of `EnvironmentConfigurations`.
  - Make `DefaultEnvironmentProvider` provide the provider-visible `local`
  environment plus optional `remote` environment from
  `CODEX_EXEC_SERVER_URL`.
  - Keep `EnvironmentManager` as the concrete cache while exposing its own
  explicit local environment for `local_environment()` fallback paths.
  
  ## Validation
  - `just fmt`
  - `git diff --check`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-28 20:05:18 -07:00
  e1ec9e63a0
• Refactor exec-server filesystem API into codex-file-system (#19892)

  ## Summary
  - Extracted the shared filesystem types and `ExecutorFileSystem` trait
  into a new `codex-file-system` crate
  - Switched `codex-config` and `codex-git-utils` to depend on that crate
  instead of `codex-exec-server`
  - Kept `codex-exec-server` re-exporting the same API for existing
  callers
  
  ## Testing
  - Ran `cargo test -p codex-file-system`
  - Ran `cargo test -p codex-git-utils`
  - Ran `cargo test -p codex-config`
  - Ran `cargo test -p codex-exec-server`
  - Ran `just fix -p codex-file-system`, `just fix -p codex-git-utils`,
  `just fix -p codex-config`, `just fix -p codex-exec-server`
  - Ran `just fmt`
  - Updated and verified the Bazel module lockfile

  Michael Zeng · 2026-04-27 17:43:15 -07:00
  a3350de855
• Add sticky environment API and thread state (#18897)

  ## Summary
  - add sticky environment selections to app-server v2 thread/start and
  turn/start request flow
  - carry thread-level selections through core session/thread state
  - add app-server coverage for sticky selections and turn overrides
  
  ## Stack
  1. This PR: API and thread persistence
  2. #18898: config.toml named environment loading
  3. #18899: downstream tool/runtime consumers
  
  ## Validation
  - Not run locally; split only.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-23 18:57:13 -07:00
  49fb25997f
• [3/4] Add executor-backed RMCP HTTP client (#18583)

  ### Why
  The RMCP layer needs a Streamable HTTP client that can talk either
  directly over `reqwest` or through the executor HTTP runner without
  duplicating MCP session logic higher in the stack. This PR adds that
  client-side transport boundary so remote Streamable HTTP MCP can reuse
  the same RMCP flow as the local path.
  
  ### What
  - Add a shared `rmcp-client/src/streamable_http/` module with:
    - `transport_client.rs` for the local-or-remote transport enum
    - `local_client.rs` for the direct `reqwest` implementation
    - `remote_client.rs` for the executor-backed implementation
    - `common.rs` for the small shared Streamable HTTP helpers
  - Teach `RmcpClient` to build Streamable HTTP transports in either local
  or remote mode while keeping the existing OAuth ownership in RMCP.
  - Translate remote POST, GET, and DELETE session operations into
  executor `http/request` calls.
  - Preserve RMCP session expiry handling and reconnect behavior for the
  remote transport.
  - Add remote transport coverage in
  `rmcp-client/tests/streamable_http_remote.rs` and keep the shared test
  support in `rmcp-client/tests/streamable_http_test_support.rs`.
  
  ### Verification
  - `cargo check -p codex-rmcp-client`
  - online CI
  
  ### Stack
  1. #18581 protocol
  2. #18582 runner
  3. #18583 RMCP client
  4. #18584 manager wiring and local/remote coverage
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-22 17:38:04 -07:00
  0e78ce80ee
• exec-server: require explicit filesystem sandbox cwd (#19046)

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

  Michael Bolin · 2026-04-22 23:05:12 +00:00
  44dbd9e48a
• Support multiple managed environments (#18401)

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

  starr-openai · 2026-04-21 15:29:35 -07:00
  ddbe2536be
• [2/8] Support piped stdin in exec process API (#18086)

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

  Ahmed Ibrahim · 2026-04-16 10:30:10 -07:00
  2ca270d08d
• Build remote exec env from exec-server policy (#17216)

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

  jif-oai · 2026-04-13 09:59:08 +01:00
  bacb92b1d7
• Run exec-server fs operations through sandbox helper (#17294)

  ## Summary
  - run exec-server filesystem RPCs requiring sandboxing through a
  `codex-fs` arg0 helper over stdin/stdout
  - keep direct local filesystem execution for `DangerFullAccess` and
  external sandbox policies
  - remove the standalone exec-server binary path in favor of top-level
  arg0 dispatch/runtime paths
  - add sandbox escape regression coverage for local and remote filesystem
  paths
  
  ## Validation
  - `just fmt`
  - `git diff --check`
  - remote devbox: `cd codex-rs && bazel test --bes_backend=
  --bes_results_url= //codex-rs/exec-server:all` (6/6 passed)
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-12 18:36:03 -07:00
  d626dc3895
• feat: move exec-server ownership (#16344)

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

  jif-oai · 2026-04-10 14:11:47 +01:00
  085ffb4456
• [codex] Support remote exec cwd in TUI startup (#17142)

  When running with remote executor the cwd is the remote path. Today we
  check for existence of a local directory on startup and attempt to load
  config from it.
  
  For remote executors don't do that.

  pakrym-oai · 2026-04-08 13:09:28 -07:00
  e4d6702b87
• Disable env-bound tools when exec server is none (#16349)

  ## Summary
  - make `CODEX_EXEC_SERVER_URL=none` map to an explicit disabled
  environment mode instead of inferring from a missing URL
  - expose environment capabilities (`exec_enabled`, `filesystem_enabled`)
  so tool building can gate behavior explicitly and future
  multi-environment work has a clearer seam
  - suppress env-backed tools when the relevant capability is unavailable,
  including exec tools, `js_repl`, `apply_patch`, `list_dir`, and
  `view_image`
  - keep handler/runtime backstops so disabled environments still reject
  execution if a tool path somehow bypasses registration
  
  ## Testing
  - `just fmt`
  - `cargo test -p codex-exec-server`
  - `cargo test -p codex-tools
  disabled_environment_omits_environment_backed_tools`
  - `cargo test -p codex-tools
  environment_capabilities_gate_exec_and_filesystem_tools_independently`
  - remote devbox Bazel build via `codex-applied-devbox`:
  `//codex-rs/cli:cli`

  starr-openai · 2026-04-06 17:22:06 -07:00
  a504d8f0fa
• feat: use ProcessId in exec-server (#15866)

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

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

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

  jif-oai · 2026-03-26 15:22:34 +01:00
  7dac332c93
• Add cached environment manager for exec server URL (#15785)

  Add environment manager that is a singleton and is created early in
  app-server (before skill manager, before config loading).
  
  Use an environment variable to point to a running exec server.

  pakrym-oai · 2026-03-25 16:14:36 -07:00
  8fa88fa8ca
• Split exec process into local and remote implementations (#15233)

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

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

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

  pakrym-oai · 2026-03-19 17:08:04 -07:00
  403b397e4e
• Add experimental exec server URL handling (#15196)

  Add a config and attempt to start the server.

  pakrym-oai · 2026-03-19 18:25:11 +00:00
  1837038f4e
• Move environment abstraction into exec server (#15125)

  The idea is that codex-exec exposes an Environment struct with services
  on it. Each of those is a trait.
  
  Depending on construction parameters passed to Environment they are
  either backed by local or remote server but core doesn't see these
  differences.

  pakrym-oai · 2026-03-19 08:31:14 -07:00
  dee03da508