926 Commits

• [codex] implement standalone code-mode process host (#30111)

  ## Summary
  
  - implement the standalone `codex-code-mode-host` stdio service
  - route sessions, cells, delegate requests, responses, and cancellation
  through a bounded host peer
  - supervise request, writer, cell-forwarding, actor, and V8 failure
  boundaries
  - bound request/session tombstones and fail-stop the connection on
  invalid protocol state
  - add host-only duplex protocol tests and local Cargo/Bazel run recipes
  
  ## Why
  
  This stage makes the host process independently runnable and reviewable
  before exposing any remote client in Codex. Transport or runtime failure
  closes the connection and relies on process replacement rather than
  transactional recovery.
  
  ## Stack
  
  This is **3 of 4** in the process-owned code-mode session stack.
  
  - Depends on #30110
  - The final client PR targets this branch
  
  ## Validation
  
  - `just test -p codex-code-mode-host` — 7 host-only tests passed
  - `just fix -p codex-code-mode-host`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `just fmt`

  Channing Conger · 2026-06-25 18:00:39 -07:00
  da78d5fdc5
• Project selected plugin runtime by environment availability (#30093)

  ## Why
  
  Selected plugin metadata is stable, but MCP processes are live runtime
  state. They need different lifetimes:
  
  - the MCP extension caches manifest, MCP, and connector declarations for
  each stable selected root;
  - each model step projects that cached metadata through the roots that
  resolved as ready for that exact step;
  - the MCP manager is rebuilt only when that availability projection
  changes.
  
  This matches executor skills: both features consume the same resolved
  step roots instead of inferring readiness from the turn's selected
  environments.
  
  ## Behavior
  
  ```text
  E1 not ready for this step
    -> no E1 MCP servers or connectors
    -> cached plugin metadata stays in ext/mcp
  
  E1 becomes ready
    -> reuse cached metadata
    -> publish one MCP runtime containing E1 capabilities
  
  same ready roots on the next step
    -> reuse the exact runtime; no rediscovery and no MCP restart
  
  resume
    -> create new extension thread state and a new MCP runtime
  ```
  
  All model-facing consumers use the same step snapshot:
  
  ```text
  resolved selected roots
          |
          v
  extension MCP/connector projection
          |
          v
  { MCP config, connector snapshot, MCP manager }
          |
          +-> advertise model tools
          +-> build app/connector tools
          +-> execute MCP calls
  ```
  
  ## Cache contract
  
  The existing MCP extension owns a cache keyed by the full
  `SelectedCapabilityRoot`:
  
  ```rust
  let state = thread_store.get_or_init(SelectedExecutorPluginMcpState::default);
  ```
  
  The cache lives with extension thread state. Environment availability
  filters projection but does not invalidate metadata. Resume creates new
  thread state. There is no file watcher or executor generation because
  contents behind a stable environment/root are assumed stable.
  
  ## What changes
  
  - Keeps executor plugin discovery and cached metadata in `ext/mcp`.
  - Caches MCP and connector declarations together per selected root.
  - Uses the step's already-resolved capability roots, including lazy
  environments that are not turn environments.
  - Reuses the current MCP runtime when the ready-root projection is
  unchanged.
  - Uses the same step MCP manager and connector snapshot for
  model-visible tools and execution.
  - Resolves direct thread-scoped MCP requests from the current
  selected-root projection.
  
  ## Deliberately out of scope
  
  - `app/list` remains based on the latest global host-plugin state; this
  PR does not make its response or notifications thread-specific.
  - `required = true` startup semantics do not apply to delayed executor
  MCP activation.
  - No filesystem/content invalidation.
  - No transport-disconnect watcher.
  - No executor generations or environment replacement semantics.
  - No client sharing across complete manager replacements.
  
  ## Stack
  
  1. Extension-owned World State sections.
  2. Project executor skills through World State.
  3. Pin one MCP runtime to each model step.
  4. **This PR:** project selected MCP and connector state from
  extension-owned metadata.
  5. Integration coverage for selected capability availability and resume.
  
  ## Verification
  
  -
  `selected_plugin_servers_use_managed_requirements_for_the_selected_root_id`
  - The stacked integration PR covers unavailable to ready activation,
  unchanged-runtime reuse, skills, MCP tools, connector attribution, and
  cold resume.

  jif · 2026-06-26 01:36:44 +01:00
  3095ea9c3d
• [codex] add code-mode host failure supervision hooks (#30110)

  ## Why
  
  A process host should be discarded and rebuilt after critical actor or
  V8 failure, while the existing in-process production path must keep its
  current cell-error semantics. This change establishes that failure
  boundary without adding the host process or remote client.
  
  ## What changed
  
  - add optional task-failure supervision to the transport-neutral
  code-mode session runtime
  - report Tokio cell-actor failures and V8 runtime-thread panics to a
  host-provided fail-stop handler
  - preserve the existing handler-less in-process behavior
  - make host-owned cell ID allocation fail before numeric wraparound
  
  ## Follow-up
  
  The V8 panic signal surfaced here should also be consumed by the
  `InProcessCodeModeSession` manager in a future change so it can fail the
  affected cell. This PR intentionally leaves the handler-less in-process
  behavior unchanged while putting the required panic tracking in place.
  
  ## Stack
  
  This is **2 of 4** in the process-owned code-mode session stack.
  
  - #30108 is merged into `main`
  - The next PR targets this branch
  
  ## Validation
  
  - `just test -p codex-code-mode` — 53 passed
  - `just argument-comment-lint -p codex-code-mode`
  - `just fix -p codex-code-mode`

  Channing Conger · 2026-06-25 15:33:58 -07:00
  6c21297bba
• Let extensions contribute World State sections (#30100)

  ## Why
  
  #29856 already owns the durable thread intent and exact environment
  binding. This PR adds only the small missing extension boundary: an
  extension can contribute one named World State section, while core still
  owns persistence, diffing, and model-visible fragment types.
  
  This lets skills stay in the skills extension instead of moving their
  runtime into core.
  
  ## Shape
  
  ```text
  extension-owned state
          |
          | contribute section id + JSON snapshot + renderer
          v
  core World State
          |
          | compare with the previous snapshot
          v
  no message, or one incremental model-visible update
  ```
  
  The extension API is deliberately small:
  
  ```rust
  fn contribute_world_state(...) -> Vec<WorldStateSectionContribution>
  ```
  
  Core adapts the rendered result to `ContextualUserFragment`, records the
  snapshot, and keeps the existing compaction/resume behavior.
  
  ## What changes
  
  - Adds extension-owned World State section contributions.
  - Calls those contributors from the existing per-step World State
  builder.
  - Restores durable selected capability roots into extension thread state
  on resume.
  - Keeps the actual model-context fragment and rollout machinery in core.
  
  ## What does not change
  
  - No skill or MCP implementation moves out of its extension.
  - No new file watcher, generation, or RPC.
  - No generic migration of existing World State sections.
  - No change to the stable environment-ID assumption from #29856.
  
  ## Example
  
  ```text
  step 1 snapshot: skills = []
  step 2 snapshot: skills = [executor-demo:deploy]
  
  core asks the skills extension to render only that change.
  ```
  
  ## Stack
  
  1. **This PR:** let extensions contribute World State sections.
  2. Project executor skills through the skills extension.
  3. Pin one MCP runtime to each model step.
  4. Project selected MCP/app/connector metadata by environment
  availability.
  5. One end-to-end integration scenario.

  jif · 2026-06-25 22:23:51 +01:00
  c9e6d9783d
• [codex] Add managed MCP server matchers (#29648)

  ## Summary
  
  This PR extends the existing managed `mcp_servers` identity requirement
  so that one name-qualified rule can use either:
  
  - the released exact command or URL identity;
  - an exact stdio executable with an exact-length, ordered argument
  matcher list; or
  - a direct MCP URL matcher.
  
  Matcher-based rules stay under the released `identity` key and use the
  same `McpServerRequirement` abstraction and `mcp_servers.<server_name>`
  namespace.
  
  ## Behavior
  
  Policy activation and name qualification are unchanged:
  
  - If `mcp_servers` is absent, ordinary configured MCP servers remain
  unrestricted.
  - If `mcp_servers` is present, a server needs a matching same-name
  requirement.
  - `mcp_servers = {}` continues to deny every configured MCP server.
  - Existing exact identity requirements keep their released semantics.
  
  Plugin-bundled MCP servers use the same requirement shapes under
  `plugins.<plugin_name>.mcp_servers.<server_name>`. Top-level non-empty
  rules continue to govern only ordinary configured servers; plugin rules
  remain explicitly plugin-scoped. The existing globally empty
  `mcp_servers = {}` plugin kill switch is preserved.
  
  Requirements layers continue to use the existing regular TOML merge
  behavior. Atomic replacement of named MCP requirements is intentionally
  out of scope here and is tracked independently in #30118.
  
  ## Requirement contract
  
  The released exact identity contract remains valid:
  
  ```toml
  [mcp_servers.docs.identity]
  command = "codex-mcp"
  
  [mcp_servers.remote.identity]
  url = "https://example.com/mcp"
  ```
  
  Command identities continue to check only `command`; they do not inspect
  arguments, `cwd`, `env`, or `env_vars`.
  
  A command matcher uses an exact executable plus an exact-length, ordered
  argument list. Each argument position supports `exact`, `prefix`, or
  full-value `regex` matching:
  
  ```toml
  [mcp_servers.internal_mcp_proxy.identity]
  command = { executable = "company-cli", args = [
    { match = "exact", value = "mcp" },
    { match = "exact", value = "proxy" },
    { match = "exact", value = "--server" },
    { match = "regex", expression = '^https://[A-Za-z0-9-]+\.mcp\.internal\.example\.com(?::443)?(?:/.*)?$' },
  ] }
  ```
  
  Direct streamable HTTP MCP definitions can use the same value matcher
  types through `identity.url`:
  
  ```toml
  [mcp_servers.internal_http.identity]
  url = {
    match = "regex",
    expression = '^https://[A-Za-z0-9-]+\.mcp\.internal\.example\.com(?:/.*)?$',
  }
  ```
  
  Plugin-bundled MCP matchers use the same contract inside the
  plugin-qualified allowlist:
  
  ```toml
  [plugins."sample@test".mcp_servers.internal_mcp_proxy.identity]
  command = { executable = "company-cli", args = [
    { match = "exact", value = "mcp" },
    { match = "exact", value = "proxy" },
  ] }
  ```
  
  Regexes are validated while managed requirements are loaded, and regex
  matching must cover the complete value. Command matchers constrain only
  the executable and arguments.
  
  ## Why
  
  Enterprise administrators need to allow MCP servers by executable and
  positional-argument shape, including fixed arguments plus constrained
  values such as internal MCP URLs passed to a proxy.
  
  ## Validation
  
  - `just fmt`
  - `git diff --check`
  - `just test -p codex-config` (198 passed)
  - `just test -p codex-core mcp_servers_by_matchers --lib` (2 passed)

  felixxia-oai · 2026-06-25 22:15:50 +01:00
  db541f4553
• Support OAuth for HTTP MCP servers from selected executor plugins (#28529)

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

  jif · 2026-06-25 10:31:17 +01:00
  b215961a56
• Read connector declarations from executor plugins (#29852)

  ## Why
  
  Selected capability roots can live on a different executor and operating
  system from app-server. Their connector declarations must therefore be
  read through the executor that owns the package, without converting
  executor URIs into host paths.
  
  This PR adds that authority-bound reader without activating connectors
  or changing thread startup.
  
  ## What changed
  
  - Add a small `codex-connectors-extension` crate for executor-owned
  connector I/O.
  - Read only the app configuration explicitly declared by the resolved
  plugin manifest.
  - Read through the `ExecutorFileSystem` retained by
  `ResolvedExecutorPlugin`; there is no host-filesystem fallback or
  default-file probe.
  - Keep `PathUri` values intact so Windows, Unix, and remote executor
  paths work from any orchestrator OS.
  - Return full `AppDeclaration` values so the caller retains declaration
  names and categories for routing.
  - Preserve the selected plugin ID and exact executor URI in read and
  parse errors.
  
  The contract is intentionally narrow: selected packages are trusted,
  valid packages and packages that provide connectors explicitly declare
  their app configuration.
  
  ## Stack scope
  
  This PR is stacked on #29851. It only provides the executor-backed
  reader. #29856 resolves selected roots at thread start, freezes their
  connector snapshot, and contains the remote-capable end-to-end authority
  test for the complete path.

  jif · 2026-06-24 23:56:50 +01:00
  9ff8068880
• Add a connector declaration snapshot (#29851)

  ## Why
  
  Connector declarations currently enter Codex through broad plugin
  capability summaries, then MCP setup, turn tooling, and `app/list` each
  reconstruct the same information. That makes executor-selected
  connectors difficult to add without coupling connector behavior to the
  host plugin loader.
  
  This PR introduces a small connector-owned value that later stack layers
  can populate before thread startup.
  
  ## What changed
  
  - Move the pure app-declaration parser into `codex-connectors`,
  preserving declaration order and category cleanup while leaving
  host-side validation and deduplication unchanged.
  - Add an immutable `ConnectorSnapshot` with ordered connector IDs and
  plugin display-name provenance.
  - Adapt the existing local-plugin capability summaries into that
  snapshot at current consumer boundaries.
  - Use the snapshot for MCP tool provenance, turn connector inventory,
  and `app/list`.
  - Keep the crate API narrow: no test-only snapshot accessors are
  exposed.
  
  The externally visible behavior is unchanged. Connector tools still come
  from the orchestrator-owned `/ps/mcp` server, and local plugin
  enablement remains owned by the existing plugin loader.
  
  ## Stack scope
  
  This is the foundation only. It does not read selected executor packages
  or change thread startup. #29852 adds the executor-backed declaration
  reader, and #29856 composes selected declarations into a thread
  snapshot.

  jif · 2026-06-24 23:24:01 +01:00
  4e0f863df3
• mcp: keep elicitation requests below app wire types (#29724)

  ## Why
  
  Core and tools need to request MCP elicitation without constructing
  app-server wire payloads. The request should remain a neutral protocol
  concept until app-server serializes it for a client.
  
  ## What changed
  
  - Switched core and tools to
  `codex_protocol::approvals::ElicitationRequest`.
  - Derived turn and server context inside core instead of carrying
  app-server request types through lower layers.
  - Kept the app-server payload unchanged through an explicit boundary
  conversion.
  - Removed the remaining production app-server-protocol dependency from
  tools.
  
  ## Stack
  
  This is PR 5 of 6, stacked on [PR
  #29723](https://github.com/openai/codex/pull/29723). Review only the
  delta from `codex/split-connector-metadata-types`. Next: [PR
  #29725](https://github.com/openai/codex/pull/29725).
  
  ## Validation
  
  - `codex-core` MCP coverage passed: 87 tests.
  - Tools elicitation and app-server round-trip coverage passed.

  Adam Perry @ OpenAI · 2026-06-24 20:53:27 +00:00
  df1ee09ec5
• [codex] Inject agent graph store into ThreadManager (#29736)

  Pick up the AgentGraphStore migration.
  
  - Inject an explicit optional agent graph store into `ThreadManager` 
  - Move all calls to spawn, close, recursive resume, and
  subtree/archive/delete/feedback traversal through it
  - Keep using  `LocalAgentGraphStore` when SQLite is available
  
  This required some changes to the interface to deal with futures:
  
  - The interface now matches `ThreadStore`'s object-safe pattern by
  returning a boxed `AgentGraphStoreFuture` directly, allowing
  `ThreadManager` to hold `Arc<dyn AgentGraphStore>`
  
  *Slight behavior change!* Unfiltered subtree enumeration now performs a
  single all-status breadth-first traversal, so a closed grandchild
  beneath an open edge is included; the previous Open-then-Closed
  traversals could not cross mixed-status paths and silently omitted it.

  Tom · 2026-06-24 13:24:10 -07:00
  ece1dfece0
• feat(network-proxy): experimental local credential broker (#28034)

  ## Why
  
  Codex child processes can inherit injectable local credentials directly,
  which lets commands read and exfiltrate the real values. This
  experimental slice keeps supported workflows working while moving those
  credentials behind the managed network proxy.
  
  This PR contains only the proxy-owned broker implementation. The Codex
  config and runtime integration is stacked separately in #29752.
  
  ## What changed
  
  - discover supported credentials during child setup, retain real values
  only in the in-memory proxy broker, and replace them with shaped dummy
  values
  - require a presented dummy to select a stored credential and preserve
  unrelated explicit authorization headers
  - bind GitHub cloud, GitHub Enterprise, and OpenAI credentials to their
  intended hosts
  - inject credentials only into TLS traffic by default; plaintext
  injection requires the explicit dangerous opt-in
  - use TLS ClientHello routing for CONNECT so non-TLS protocols remain
  opaque tunnels
  - expose a pure API that identifies environment keys still holding
  broker-generated dummies without mutating the caller's environment
  
  ## Scope
  
  - supported credentials: `GH_TOKEN`, `GITHUB_TOKEN`,
  `GH_ENTERPRISE_TOKEN`, `GITHUB_ENTERPRISE_TOKEN`, and `OPENAI_API_KEY`
  - GitHub cloud credentials match `github.com`, `api.github.com`, and
  `*.ghe.com`
  - GitHub Enterprise credentials match only the normalized non-cloud
  `GH_HOST`
  - OpenAI API keys match only `api.openai.com`
  - this does not cover SSH agents, kube client certificates, filesystem
  secret discovery, or context-injected secret scrubbing
  
  ## Validation
  
  - `just test -p codex-network-proxy` (191 passed)
  - focused opaque CONNECT, plaintext opt-in, dummy-selection, and
  child-isolation regressions passed
  - scoped Clippy check for `codex-network-proxy` passed
  
  ---------
  
  Co-authored-by: viyatb-oai <viyatb@openai.com>
  Co-authored-by: Codex <noreply@openai.com>

  Winston Howes · 2026-06-24 13:21:16 -07:00
  989f55defa
• [codex] Trace exec-server JSON-RPC requests (#27466)

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

  richardopenai · 2026-06-24 12:50:18 -07:00
  74dcce594d
• connectors: own app metadata types (#29723)

  ## Why
  
  Connector metadata is consumed by connector discovery, ChatGPT
  integration, core, and TUI code. Treating app-server's wire DTO as the
  shared domain model reverses the intended dependency direction.
  
  ## What changed
  
  - Added connector-owned app branding, review, screenshot, metadata, and
  info types.
  - Added explicit conversions in app-server and TUI while preserving
  app-server's wire payloads.
  - Removed production app-server-protocol dependencies from connectors
  and ChatGPT connector code.
  
  ## Stack
  
  This is PR 4 of 6, stacked on [PR
  #29722](https://github.com/openai/codex/pull/29722). Review only the
  delta from `codex/split-config-layer-types`. Next: [PR
  #29724](https://github.com/openai/codex/pull/29724).
  
  ## Validation
  
  - Connector and tools coverage passed.
  - App-server app-list coverage passed: 13 tests.

  Adam Perry @ OpenAI · 2026-06-23 22:08:23 -07:00
  e639e8c4bd
• config: own layer provenance types (#29722)

  ## Why
  
  Config layer provenance describes how effective configuration was
  assembled, so it belongs with the config loader rather than in
  app-server's serialized API types.
  
  ## What changed
  
  - Moved `ConfigLayerSource`, `ConfigLayerMetadata`, and `ConfigLayer`
  ownership into `codex-config`.
  - Kept app-server's wire payloads unchanged and added explicit
  conversions at the app boundary.
  - Removed lower-level app-server-protocol dependencies from config
  consumers.
  
  ## Stack
  
  This is PR 3 of 6, stacked on [PR
  #29721](https://github.com/openai/codex/pull/29721). Review only the
  delta from `codex/split-auth-domain-types`. Next: [PR
  #29723](https://github.com/openai/codex/pull/29723).
  
  ## Validation
  
  - `codex-config` coverage passed.
  - App-server config-manager and config RPC coverage passed.

  Adam Perry @ OpenAI · 2026-06-24 04:03:04 +00:00
  1d65ccabd5
• [plugins] Enforce marketplace source admission requirements (#29753)

  ## Why
  
  Managed marketplace source requirements only become effective when every
  local marketplace mutation path applies the same admission decision.
  This change centralizes that decision so CLI, app-server, and
  external-agent migration flows cannot add, install from, or refresh a
  disallowed source.
  
  ## What changed
  
  - Match exact normalized Git repository URLs with an optional exact
  `ref`.
  - Match Git hosts with managed regular expressions.
  - Match local marketplaces by exact absolute path.
  - Preserve the expected path/name boundary for managed OpenAI
  marketplaces.
  - Enforce source admission during marketplace add, plugin install, and
  configured Git marketplace upgrade.
  - Continue upgrading independent marketplaces when one source is
  rejected and return a per-marketplace error.
  - Load the effective requirements stack at CLI, app-server, and
  external-agent migration entry points.
  
  This PR does not filter already configured marketplaces at runtime; that
  remains in draft follow-up #29691.
  
  ## Stack
  
  This is PR 2 of 3 and is based on #29690, which introduces the
  requirements data shape and merge behavior.
  
  ## Test plan
  
  - Source matcher coverage for Git URL/ref, host-pattern, local-path, and
  managed marketplace cases.
  - Marketplace add and plugin install coverage for allowed and rejected
  sources.
  - Marketplace upgrade coverage for rejection and per-marketplace
  continuation.

  xl-openai · 2026-06-23 20:13:11 -07:00
  4fe02f4fcf
• auth: move domain mode below app wire types (#29721)

  ## Why
  
  Authentication mode is a domain concept used by login, model selection,
  telemetry, and transports. Keeping the canonical type in app-server
  protocol forces those lower-level crates to depend on an unrelated wire
  API.
  
  ## What changed
  
  - Added canonical `codex_protocol::auth::AuthMode` domain values.
  - Kept the app-server wire DTO unchanged and added an explicit app-side
  conversion.
  - Removed production app-server-protocol dependencies from login,
  model-provider-info, models-manager, and otel call paths.
  
  ## Stack
  
  This is PR 2 of 6, stacked on [PR
  #29714](https://github.com/openai/codex/pull/29714). Review only the
  delta from `codex/split-json-rpc-protocols`. Next: [PR
  #29722](https://github.com/openai/codex/pull/29722).
  
  ## Validation
  
  - Auth and login coverage passed in the focused protocol/domain test
  run.
  - App-server account and auth conversion coverage passed.

  Adam Perry @ OpenAI · 2026-06-24 03:10:20 +00:00
  31372078d1
• Let image generation extension hosts control output persistence (#29711)

  ## Why
  
  Some extension hosts need generated images returned without writing them
  to the local filesystem or giving the model a local path.
  
  ## What changed
  
  **tl;dr**: we now conduct all extension operations in the image gen
  extension
  
  - Let hosts provide an optional image save root when installing the
  extension.
  - Save images and return path hints only when a save root is configured.
  - Return image data without saving or adding a path hint when no save
  root is configured.
  - Preserve the extension-provided `saved_path` instead of persisting
  extension images again in core.
  - Leave built-in image generation unchanged.
  
  ## Validation
  
  - `just test -p codex-image-generation-extension`
  - `just test -p codex-app-server
  standalone_image_generation_returns_saved_path_hint_to_model`
  - `just test -p codex-core
  extension_tool_uses_granted_turn_permissions_without_local_persistence`
  - `just test -p codex-core tools::handlers::extension_tools::tests`
  - tested on CODEX CLI on both save_root: CODEX_HOME and None 
  - tested on CODEX APP on both as well

  Won Park · 2026-06-23 18:51:49 -07:00
  61f5a84930
• test: add app-server auto environment helper (#29746)

  ## Why
  
  Start moving towards app-server tests defaulting to running against
  remote & foreign OS executors. To do so we need a point of indirection
  similar to core integration tests' `build_with_auto_env`, but with the
  flexibility of letting tests control environment registration if they
  need to.
  
  ## What
  
  This adds:
  
  - `TestAppServer::new_with_auto_env()` for constructing an app server
  with a default environment defined by the test runner (e.g. bazel)
  - `TestAppServer::auto_env_params()` for tests to easily acquire turn
  env params tailored to the automatic environment
  - `TestAppServer::send_thread_start_request_with_auto_env()` to make it
  easy for tests to start a thread using the automatic environment
  
  The above methods all fail if the test calling them has set up an
  environment where the automatic environment configuration conflicts with
  test-created state.
  
  ## Validation
  
  Adds a couple of basic smoke tests to the app-server test suite.
  Follow-ups will migrate more tests to use it.

  Adam Perry @ OpenAI · 2026-06-24 01:06:29 +00:00
  283bc4cf01
• Support thread-level originator overrides (#29477)

  ## Why
  
  Work(TPP) threads can be launched from the Desktop app, but if they all
  keep the Desktop app's default originator then downstream attribution
  cannot distinguish local Work launches from cloud-backed Work launches.
  `thread/start.serviceName` already carries that launch signal, while
  `SessionMeta.originator` is the durable thread-level value that survives
  resume and fork.
  
  This change converts the Desktop Work service names into an effective
  originator at thread creation time, persists that originator with the
  thread, and keeps using it for later model requests and memory writes.
  
  ## What changed
  
  - Map `CODEX_WORK_LOCAL` and `CODEX_WORK_CLOUD` service names to
  per-thread originators, while preserving
  `CODEX_INTERNAL_ORIGINATOR_OVERRIDE` as the highest-precedence override.
  - Persist the effective originator in `SessionMeta.originator`, read it
  back on resume/fork, and inherit the parent originator for subagent
  spawns when there is no persisted session metadata.
  - Handle truncated `SpawnAgentForkMode::LastNTurns` forks by falling
  back to the live parent originator when the forked history no longer
  includes `SessionMeta`.
  - Thread the per-thread originator through Responses headers,
  websocket/compaction request paths, thread-store creation, rollout
  metadata, and memory stage-one telemetry.
  
  ## Verification
  
  - `just test -p codex-core
  agent::control::tests::spawn_thread_subagent_inherits_parent_originator_without_fork
  agent::control::tests::spawn_thread_subagent_fork_last_n_turns_inherits_parent_originator_without_session_meta
  thread_manager::tests::originator_override_precedes_service_name_remapping`
  - `just test -p codex-core
  agent::control::tests::resume_thread_subagent_restores_stored_metadata_and_effective_multi_agent_mode`
  - `just test -p codex-memories-write`
  - `just fix -p codex-core -p codex-memories-write`
  - `git diff --check`

  alexsong-oai · 2026-06-23 17:23:38 -07:00
  1acb722e8a
• protocol: separate app and exec RPC ownership (#29714)

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

  Adam Perry @ OpenAI · 2026-06-23 22:37:31 +00:00
  829f5b6b59
• Make selected plugin roots URI-native (#28918)

  ## Why
  
  Selected capability roots belong to the executor filesystem, not the
  app-server host. Converting their path strings into the host's native
  `Path` breaks whenever the two machines use different path conventions,
  such as a Windows executor behind a Unix app-server.
  
  This PR establishes `PathUri` as the selected-plugin boundary so the
  executor remains authoritative for its paths.
  
  ## What changed
  
  - Require `selectedCapabilityRoots[].location.path` to be a canonical
  `file:` URI and deserialize it directly as `PathUri`; native path
  strings are rejected.
  - Update the app-server schema, generated TypeScript, examples, and
  request coverage for the URI contract.
  - Keep selected roots, resolved plugin locations, manifest paths, and
  manifest resources as `PathUri`.
  - Inspect and read plugin roots and manifests only through the selected
  environment's `ExecutorFileSystem`.
  - Parse executor manifests with the shared URI-native parser from #29620
  instead of projecting them onto the host filesystem.
  - Enforce resource containment lexically and preserve the root URI's
  POSIX or Windows path convention.
  - Cover foreign Windows plugin roots and URI-native manifest resources.
  
  ```text
  thread/start
    selectedCapabilityRoots[].location.path = "file:///C:/plugins/demo"
                                | PathUri
                                v
                      ExecutorFileSystem
                                |
                                +--> plugin.json
                                +--> manifest resources
  ```
  
  This PR stops at the shared selected-plugin representation. The next two
  PRs remove the remaining host-path projections in the skill and MCP
  consumers.
  
  ## Stack
  
  1. #29614 — add lexical `PathUri` containment.
  2. #29620 — share URI-native manifest path resolution.
  3. **This PR** — keep selected plugin roots and resources URI-native.
  4. #29626 — load executor skills without host path conversion.
  5. #29628 — resolve executor MCP working directories without host path
  conversion.

  jif · 2026-06-23 22:51:19 +01:00
  2e69966cd8
• Prepare managed network sandbox context (#29456)

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

  jif · 2026-06-23 20:07:09 +01:00
  e476fc16ce
• [codex] Instrument rollout persistence bytes (#29498)

  - Add 1%-sampled rollout persistence metrics that report per-item and
  per-thread JSON byte totals before and after filtering when metrics
  export is enabled.
  - Tag each item with its exact response or event variant, including
  nested turn-item kinds for conditionally persisted completion events, so
  aggregate cloud-storage impact can be estimated by policy choice.

  Tom · 2026-06-23 09:26:30 -07:00
  02c326f646
• Update rmcp to 1.8.0 (#29634)

  ## Summary
  
  - Update `rmcp` and `rmcp-macros` from 1.7.0 to 1.8.0.
  - Adapt to the new shared `peer_info` return type.
  - Box OAuth status discovery at the MCP boundary to keep the expanded
  future type from overflowing Rust's trait recursion limit.
  
  This brings in custom OAuth HTTP client support from
  [modelcontextprotocol/rust-sdk#908](https://github.com/modelcontextprotocol/rust-sdk/pull/908).

  jif · 2026-06-23 15:25:28 +01:00
  bbe1006890
• PAC 4 - Add macOS system proxy resolver (#26709)

  ## Summary
  
  Stacked on #26708.
  
  Adds the macOS implementation of the shared system-proxy contract. This
  allows Codex-owned auth clients to use the route macOS selects for each
  auth URL through SystemConfiguration and CFNetwork, including PAC and
  WPAD results.
  
  The `respect_system_proxy` feature is disabled by default, so existing
  client behavior remains unchanged unless explicitly enabled.
  
  ## Implementation
  
  - Adds the macOS-only `system-configuration` dependency to
  `codex-client`.
  - Dispatches system-proxy resolution to `outbound_proxy/macos.rs` on
  macOS.
  - Reads system proxy settings from `SCDynamicStore` and resolves the
  target URL with `CFNetworkCopyProxiesForURL`.
  - Executes PAC URLs and inline PAC JavaScript through a bounded run loop
  with a five-second timeout.
  - Handles `DIRECT`, HTTP proxies, and CFNetwork HTTPS entries using HTTP
  CONNECT; unsupported SOCKS entries map to `UnsupportedProxyScheme`.
  - Builds concrete proxy URLs from host and port entries, including IPv6
  host bracketing.
  - Maps results into the shared `SystemProxyDecision::{Direct, Proxy,
  Unavailable}` contract.
  - Hashes URL-specific cache keys so PAC decisions remain distinct
  without retaining raw request URLs or query strings.
  
  ## End-user behavior
  
  - Disabled/default: existing client behavior is unchanged.
  - Enabled with `[features.respect_system_proxy]`:
    - macOS auth clients honor system proxy configuration, PAC, and WPAD;
    - valid OS/PAC `DIRECT` decisions use a direct connection;
  - unavailable system resolution falls back to explicit environment proxy
  variables, then `DIRECT`, through the shared contract from #26707.
  - Unsupported proxy schemes are not silently translated into another
  route.
  - Custom CA handling remains separate from proxy selection.
  - Known limitation: only the first supported system/PAC candidate is
  used. Subsequent proxy or `DIRECT` candidates are not attempted after a
  connection failure. This matches the current Windows behavior and leaves
  room for future ordered-fallback support.
  
  ## Tests
  
  - `just test -p codex-client` — 34 tests passed.
  - `just clippy -p codex-client`
  - `just fmt`
  - `just bazel-lock-check`

  canvrno-oai · 2026-06-22 17:56:04 -07:00
  b16d2858f5
• Upgrade bundled OpenSSL to 3.6.3 (#29487)

  ## Summary
  
  - upgrade the bundled OpenSSL source from 3.5.5 to 3.6.3
  - update the Bazel `openssl-sys` build dependency to use the upgraded
  source crate
  - refresh the Bazel module lockfile
  
  ## Why
  
  OpenSSL 3.5.5 is within the affected ranges for security issues fixed in
  later releases. The Rust `openssl-src` wrapper does not currently
  publish OpenSSL 3.5.7, so this moves the vendored Linux musl build to
  the available patched 3.6.3 release.

  jif · 2026-06-23 00:19:54 +02:00
  372b5ac7c2
• PAC 3 - Add Windows system proxy resolver (#26708)

  ## Summary
  
  Stacked on #26707.
  
  Adds the Windows implementation of the shared system-proxy contract.
  This allows Codex-owned auth clients to use the route Windows selects
  for each auth URL, including explicit PAC configuration, WPAD
  auto-detection, static proxies, and bypass rules.
  
  The `respect_system_proxy` feature is disabled by default, so existing
  client behavior remains unchanged unless explicitly enabled.
  
  ## Implementation
  
  - Adds Windows-only `codex-client` dependencies:
  - `windows-sys` with `Win32_Foundation` and `Win32_Networking_WinHttp`;
    - `sha2` for redacted cache keys.
  - Dispatches system-proxy resolution to `outbound_proxy/windows.rs` on
  Windows.
  - Reads the current-user WinHTTP/IE proxy configuration via
  `WinHttpGetIEProxyConfigForCurrentUser`.
  - Resolves explicit PAC URLs first, then OS-enabled WPAD auto-detection,
  then static proxy and bypass settings.
  - Uses `WinHttpGetProxyForUrl` for PAC/WPAD and maps results into the
  shared `SystemProxyDecision::{Direct, Proxy, Unavailable}` contract.
  - Parses `DIRECT`, `PROXY`, `HTTPS`, and keyed static proxy entries.
  - Treats unsupported schemes such as SOCKS as unavailable so the shared
  resolver can apply its environment-proxy fallback.
  - Handles Windows bypass entries, including `<local>` and host, suffix,
  wildcard, and port matching.
  - Releases WinHTTP-owned strings with `GlobalFree` and closes sessions
  with `WinHttpCloseHandle`.
  - Hashes URL-specific cache keys with SHA-256 so PAC decisions remain
  URL-specific without retaining raw request URLs or query strings.
  
  ## End-user behavior
  
  - Disabled/default: existing client behavior is unchanged.
  - Enabled with `[features.respect_system_proxy]`:
  - Windows auth clients honor explicit PAC configuration, OS-enabled
  WPAD, static proxies, and bypass rules;
    - valid OS/PAC `DIRECT` decisions use a direct connection;
  - unavailable system resolution falls back to explicit environment proxy
  variables, then `DIRECT`, through the shared contract from #26707.
  - Unsupported proxy schemes are not silently translated into a different
  route.
  - Custom CA handling remains separate from proxy selection.
  
  ## Tests
  
  Adds coverage for:
  
  - PAC-style proxy tokens such as `PROXY proxy.internal:8080` and `HTTPS
  proxy.internal:8443`;
  - static WinHTTP proxy entries keyed by target scheme;
  - `DIRECT` and unsupported proxy-token behavior;
  - Windows bypass matching, including `<local>`, wildcard, suffix, and
  port-qualified entries;
  - preserving URL-specific PAC cache decisions without retaining the raw
  URL on Windows.

  canvrno-oai · 2026-06-22 14:38:33 -07:00
  5f129a4703
• chore: advance tungstenite fork pins (#29480)

  ## Why
  
  `openai-oss-forks/tokio-tungstenite` now includes the updated
  `tungstenite` fork revision from
  [openai-oss-forks/tokio-tungstenite#3](https://github.com/openai-oss-forks/tokio-tungstenite/pull/3).
  Codex should consume the merged fork commit and resolve its direct and
  transitive `tungstenite` dependencies to the same revision instead of
  retaining the older pins.
  
  ## What Changed
  
  - Advanced the `tokio-tungstenite` git pin to
  `0e5b2d73aa18dd9f0a50ee9ff199d5aef7594186`.
  - Advanced the `tungstenite` fork pin to
  `4fffad30fe373adbdcffab9545e9e9bf4f2fc19f` and adjusted the patch source
  so the transitive dependency resolves to that revision.
  - Updated `Cargo.lock` and `MODULE.bazel.lock` to match the dependency
  graph.

  Anton Panasenko · 2026-06-22 14:24:02 -07:00
  0a9b7d2c36
• Honor startup custom CA bundles with managed MITM (#29014)

  ## Why
  
  When Codex starts with a custom CA override such as
  `SSL_CERT_FILE=/path/to/corp-ca.pem codex`, `rustls-native-certs` treats
  that override as a replacement for the platform trust store. The managed
  proxy then rewrites child CA variables to its generated bundle, so the
  custom root or the ordinary platform roots can be lost. The proxy's
  upstream TLS connector must trust the same roots or private and
  corporate upstream certificates still fail after interception.
  
  ## What
  
  - load platform-native roots without consulting inherited CA override
  variables
  - append certificates from the existing curated startup CA file
  variables and `SSL_CERT_DIR`
  - share those platform and startup roots with the MITM upstream rustls
  connector
  - exclude the Codex managed MITM CA from upstream trust
  - normalize OpenSSL `TRUSTED CERTIFICATE` blocks while dropping trailing
  trust metadata
  - skip an inherited current Codex-managed bundle so nested launches do
  not duplicate it
  - append the Codex managed MITM CA to the child-facing bundle
  - copy certificate material only, so a private key or unrelated text
  colocated in a startup file is never exposed through the public bundle
  
  This is intentionally limited to CA paths present when Codex starts. It
  does not parse inline shell assignments or add per-command bundle
  materialization.
  
  This changes only `codex-network-proxy` and dependency metadata; it does
  not touch `codex-core` or sandbox orchestration.
  
  ## Validation
  
  - `just test -p codex-network-proxy`
  - includes an end-to-end upstream TLS test using a server trusted only
  by the startup custom CA
  - `just fix -p codex-network-proxy`
  - `just bazel-lock-check`

  Winston Howes · 2026-06-22 14:16:48 -07:00
  527ccb4a5d
• [codex] handle request_user_input in app-server test client (#29476)

  ## Why
  
  `codex-app-server-test-client` previously treated
  `item/tool/requestUserInput` as an unsupported server request and
  terminated the connection. That made it impossible to use the client for
  end-to-end testing of interactive turns: an operator could observe the
  request, but could not answer it and confirm that the same turn resumed.
  
  ## What changed
  
  - Handle `ToolRequestUserInput` server requests in the test client's
  central request dispatcher.
  - Render numbered terminal choices, accept exact option labels, support
  free-form `Other` and text-only questions, and collect multiple answers.
  - Send a protocol-native `ToolRequestUserInputResponse` and continue
  streaming the active turn.
  - Fail clearly when interactive input is requested without a terminal.
  - Document the interactive behavior and add focused tests for option
  selection, free-form answers, multiple questions, and invalid-selection
  retries.
  
  ## Testing
  
  - `just test -p codex-app-server-test-client`
  - `just bazel-lock-check`
  - Manually exercised the app-server flow, selected `TUI`, observed
  `serverRequest/resolved`, and verified that the same turn completed with
  the selected answer.

  Celia Chen · 2026-06-22 13:55:32 -07:00
  cb255c52e9
• Allow ChatGPT accounts without email (#28991)

  # Summary
  
  Codex required every ChatGPT account to have an email address. A
  service-account personal access token can return valid account metadata
  without one, so PAT login failed while decoding the metadata response.
  
  This change makes email optional in the account metadata type that owns
  it and preserves that absence through authentication, provider account
  state, the app-server API, generated clients, and TUI bootstrap.
  Existing accounts with email addresses keep the same behavior.
  
  ## Behavior-changing call sites
  
  | Call site | Behavior after this change |
  | --- | --- |
  | `login/src/auth/personal_access_token.rs` | PAT metadata accepts a
  missing or null email and retains `None`. |
  | `agent-identity/src/lib.rs` | Agent Identity JWT claims accept an
  omitted email. |
  | `login/src/auth/storage.rs` and `login/src/auth/agent_identity.rs` |
  Stored and managed Agent Identity records carry `Option<String>`.
  Deserialization maps the legacy empty-string sentinel to `None`. |
  | `login/src/auth/manager.rs` | `get_account_email` returns the stored
  option, and managed identity bootstrap no longer converts `None` to an
  empty string. |
  | `model-provider/src/provider.rs` and `protocol/src/account.rs` | A
  ChatGPT provider account requires a plan type but may carry no email. |
  | `app-server-protocol/src/protocol/v2/account.rs` | `account/read`
  keeps the `email` field on the wire and returns `null` when the account
  has no email. Generated TypeScript and JSON schemas describe a required,
  nullable field. |
  | `sdk/python/src/openai_codex/generated/v2_all.py` | The generated
  Python `ChatgptAccount` model accepts `None` for email. |
  | `tui/src/app_server_session.rs` | Email-less ChatGPT accounts
  bootstrap normally, keep external feedback routing, omit account-email
  telemetry, and display the plan in account status. |
  
  ## Design decisions
  
  - Missing email remains `None` at every layer. The code never uses an
  empty string as a substitute.
  - The app-server response includes `"email": null` instead of omitting
  the field. Clients retain a stable response shape.
  - Plan type remains required for provider account state. This change
  relaxes only the email assumption.
  
  ## Testing
  
  Tests: affected test targets compile, scoped Clippy and formatting pass,
  a focused TUI snapshot covers plan-only account status, real
  before/after PAT login smoke covers metadata without email, app-server
  smoke covers `account/read` with `email: null`, and a regression smoke
  covers an existing email-bearing PAT. Unit tests run in CI.
  
  ## Evidence
  
  Visual smoke evidence will be attached here.

  efrazer-oai · 2026-06-22 13:19:40 -07:00
  5a67d898a5
• Parallelize skill metadata stats (#29326)

  ## Summary
  
  This switches skill discovery to the simpler same-connection scalar
  request shape.
  
  After reading a skills directory, discovery now starts the existing
  `fs/getMetadata` calls for all visible entries in that directory before
  awaiting the results. There is no JSON-RPC batch frame and no new
  filesystem API; remote filesystems use the existing request-id
  multiplexing on the same exec-server connection.
  
  This is the scoped alternative to the batch-frame approach in #29074 /
  #29075.
  
  ## What changed
  
  - Collect visible directory entries before processing them.
  - Run their existing `fs.get_metadata(...)` calls with `join_all`.
  - Process the results in the original directory order, so skill
  discovery behavior stays the same.
  
  ## Benchmarks
  
  Fresh local benchmark against generated skill trees over a real
  exec-server remote filesystem. The benchmark calls the actual
  `load_skills_from_roots` path, so this includes directory reads,
  metadata stats, `SKILL.md` reads, and parsing.
  
  Times are p50 milliseconds from 5 samples after 1 warmup, using warmed
  runs.
  
  | Scenario | Legacy `main` | Batch frame stack (#29074 / #29075) |
  Same-connection scalar stack |
  | --- | ---: | ---: | ---: |
  | 100 flat skills | 377.4 | 389.0 | 378.6 |
  | 500 flat skills | 1983.2 | 1856.6 | 1757.5 |
  
  Takeaway: for the actual skill discovery path, same-connection scalar is
  tied with legacy at 100 skills and best at 500 skills. The batch-frame
  stack does not show enough win here to justify the extra protocol/API
  surface.
  
  Benchmark command:
  
  - `just test -p codex-exec-server benchmark_remote_skill_discovery
  --run-ignored ignored-only --no-capture`
  
  Checked locally with:
  
  - `just test -p codex-core-skills`
  - `just bazel-lock-update`
  - `just bazel-lock-check`

  jif · 2026-06-21 14:04:18 +02:00
  c2fbf4247a
• chore(deps): advance tokio-tungstenite (#29132)

  ## Why
  
  Responses websocket connections use `tokio-tungstenite`. When DNS
  returns an unusable native IPv6 address before a working IPv4 address,
  sequential dialing can consume Codex's outer websocket timeout before
  reaching IPv4. The merged fork change adds Happy Eyeballs-style
  alternate-family racing so websocket dialing matches the recovery
  behavior already present in the HTTP path.
  
  ## What Changed
  
  Advance the workspace `tokio-tungstenite` patch from `132f5b39` to
  merged commit `e5e64b86`, and update the matching lockfile source. The
  new revision comes from
  [openai-oss-forks/tokio-tungstenite#1](https://github.com/openai-oss-forks/tokio-tungstenite/pull/1).

  Anton Panasenko · 2026-06-19 12:02:12 -07:00
  abd901770e
• feat: opt ChatGPT auth into agent identity (#19049)

  ## Stack
  
  This is PR 2 of the simplified HAI single-run-task stack:
  
  - [#19047](https://github.com/openai/codex/pull/19047) Agent Identity
  assertion and task-registration primitives, including the shared
  run-task helper used by existing Agent Identity JWT auth.
  - [#19049](https://github.com/openai/codex/pull/19049)
  Disabled-by-default ChatGPT auth opt-in that provisions/reuses persisted
  Agent Identity runtime auth and its single run task.
  - [#19051](https://github.com/openai/codex/pull/19051) Run-scoped
  provider auth that uses one backend-owned task id for first-party
  inference and compaction requests.
  
  [#19054](https://github.com/openai/codex/pull/19054) collapsed out of
  the active stack because the simplified design no longer needs a
  separate background/control-plane task helper.
  
  ## Summary
  
  This PR adds the disabled-by-default path for normal ChatGPT-login Codex
  sessions to obtain Agent Identity runtime auth through the Codex
  backend. Existing Agent Identity JWT startup mode remains a separate
  path and does not require the feature flag.
  
  What changed:
  
  - adds the experimental `use_agent_identity` feature flag and config
  schema entry
  - adds an explicit `AgentIdentityAuthPolicy` so call sites choose
  `JwtOnly` or `ChatGptAuth` instead of passing a bare boolean
  - stores standalone Agent Identity JWT credentials separately from
  backend-registered Agent Identity records
  - persists the registered Agent Identity record, private key, and single
  run task id in `auth.json` so process restarts reuse the same identity
  - derives the agent/task registration base URL from ChatGPT/Codex auth
  config while keeping JWT JWKS lookup separate
  - provisions and caches ChatGPT-derived Agent Identity runtime auth when
  `use_agent_identity` is enabled
  - reuses the shared run-task registration helper from PR1 rather than
  adding a second task-registration path
  
  This PR intentionally does not switch model inference over to
  `AgentAssertion` auth. The provider-auth integration lands in the next
  PR.
  
  ## Testing
  
  - `just test -p codex-login`

  Adrian · 2026-06-18 14:05:27 -07:00
  ec848dde0e
• [codex] Remove hardcoded app ID filters (#28947)

  ## Summary
  
  - remove the duplicated originator-specific connector ID denylists
  - stop filtering connector directory/accessibility results and
  live/cached Codex Apps MCP tools by hardcoded connector ID
  - remove the now-unused `codex-login` dependency from
  `codex-utils-plugins`
  - update regression coverage so formerly blocked connector IDs are
  preserved
  
  ## Why
  
  The client-side policy was duplicated across crates, used opaque IDs
  without ownership or expiry information, and could drift between app
  listing and MCP tool behavior. Server-provided visibility,
  authorization, plugin discoverability, accessibility, enabled-state
  handling, and consequential-tool approval templates remain unchanged.
  
  ## Validation
  
  - `just fmt`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `git diff --check`
  - confirmed the final diff contains no hardcoded denylist symbols
  
  A targeted `codex-mcp` test build spent an unusually long time in local
  compilation/linking. Its first attempt exposed a test-only `PartialEq`
  assertion issue, which was corrected. A follow-up non-linking `cargo
  check -p codex-mcp --tests` was still running when this draft was
  opened; CI should provide the complete Rust validation.

  Eric Ning · 2026-06-18 20:29:01 +00:00
  29eb434bc5
• Scope MCP sandbox metadata to server environment (#28914)

  Scope MCP sandbox metadata to the MCP server's owning environment.
  
  Previously, `codex/sandbox-state-meta` always used the turn's primary
  cwd and rebuilt a legacy sandbox policy from that cwd. That can be wrong
  for MCP servers owned by a different execution environment.
  
  This now sends the owning environment cwd as a `file:` URI in
  `sandboxCwd`, keeps `permissionProfile` as the permission source of
  truth, and omits sandbox-state metadata when a non-default server
  environment is not selected for the turn. Local/default MCP servers keep
  the existing fallback cwd behavior.
  
  Tests:
  - `just fmt`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `just test -p codex-mcp`
  - `just test -p codex-core mcp_sandbox_cwd`
  - `cargo build -p codex-rmcp-client --bin test_stdio_server`
  - `just test -p codex-core
  stdio_mcp_tool_call_includes_sandbox_state_meta`

  jif · 2026-06-18 19:31:07 +02:00
  790213ded0
• 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
• [codex] [3/4] Activate endpoint plugin recommendations (#27704)

  Summary\n- Await endpoint recommendation selection while constructing
  each authenticated turn, removing the first-turn cache race.\n- Snapshot
  and filter endpoint candidates once per turn, then use that same set for
  the bounded contextual user fragment, tool exposure, and exact install
  validation.\n- Keep recommendation selection ephemeral: do not persist
  recommendation state in or gate resumed threads on prior context.\n-
  Hide the legacy list tool in endpoint mode and preserve legacy discovery
  unchanged when the endpoint is disabled or unavailable.\n- Keep remote
  plugin and connector app identities out of model-visible context and
  attach them only to Codex-owned elicitation metadata.\n\nStack\n- 3/4,
  based on #28400.\n- Endpoint client and cache: #28399.\n- Generalized
  suggestion presentation: #28400.\n- Install-schema follow-up:
  #28403.\n\nValidation\n- \n- \n- \n- \n- Full : 2,649 passed and 88
  environment-dependent tests failed because this sandbox cannot write ,
  nest Seatbelt, or locate auxiliary test binaries.

  Alex Daley · 2026-06-16 23:04:07 +00:00
  a34da3b295
• [codex] Route MCP file uploads through environment filesystem (#27923)

  ## Why
  
  Codex Apps tools can mark arguments with `openai/fileParams`, but the
  execution path resolved and opened those files directly on the host.
  That bypassed the selected turn environment and prevented annotated file
  arguments from working with remote environments.
  
  ## What changed
  
  - resolve annotated file arguments against the primary turn environment
  - read file metadata and contents through that environment's sandboxed
  `ExecutorFileSystem`
  - reject files over the 512 MiB limit from metadata before reading or
  transferring them
  - retain the buffered upload-size check as defense in depth
  - make the OpenAI upload API accept a filename and buffered contents
  instead of owning local filesystem access
  - describe the model-visible argument as a path in the primary
  environment
  
  This builds on #27927, which added `size` to internal filesystem
  metadata.
  
  ## Testing
  
  - `just test -p codex-api upload_openai_file_returns_canonical_uri`
  - `just test -p codex-mcp
  tool_with_model_visible_input_schema_masks_file_params`
  - `just test -p codex-core mcp_openai_file`
  - `just test -p codex-core
  codex_apps_file_params_upload_environment_files_before_mcp_tool_call`

  pakrym-oai · 2026-06-16 11:27:46 -07:00
  7baf7e467e
• [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
• Use ApiPathString in app-server filesystem permission paths (#28367)

  ## Why
  
  Clients running an app-server on one OS and an exec-server on another OS
  need to be able to pass sandbox config to app-server that refers to
  resources on the executor's foreign OS.
  
  ## What
  
  `AbsolutePathBuf` can't represent these paths and we don't want users to
  be exposed to `PathUri` yet, so this moves the public app-server API to
  be expressed in terms of `ApiPathString`.
  
  Stacked on #28165.
  
  - change app-server v2 filesystem permission paths, including legacy
  read/write roots, to `ApiPathString`
  - localize API paths through `PathUri` when converting into the current
  native core permission types
  - make path-bearing permission conversions fallible and surface
  localization failures instead of silently treating malformed grants as
  ordinary denials
  - propagate conversion failures through app-server and TUI approval
  handling
  - regenerate the app-server JSON and TypeScript schemas
  - leave migration TODOs on native-path conversions so they can be
  removed once core permission paths use `PathUri`

  Adam Perry @ OpenAI · 2026-06-15 19:25:54 -07:00
  ecfe174d5f
• 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
• [codex] Reuse Apps policy evaluation across MCP tool exposure (#27813)

  ## Summary
  
  - move `AppToolPolicyEvaluator` and the Apps config/requirements policy
  logic from `codex-core` into `codex-connectors`
  - resolve one immutable policy snapshot per exposure build and reuse it
  across every Codex Apps MCP tool
  - keep core as a thin adapter from MCP metadata to connector-owned
  policy input while preserving the call-time defense-in-depth check
  
  ## Why
  
  `build_mcp_tool_exposure` evaluates every Codex Apps tool on each
  sampling request. The old path rebuilt effective Apps configuration for
  every tool, and the policy implementation lived in the already-large
  core crate even though it is connector-specific.
  
  The connector-owned evaluator keeps the expensive config merge/decode
  out of the loop and gives core only the effective policy result it
  needs.
  
  ## Performance
  
  With the real 557-tool Apps corpus, `build_mcp_tool_exposure` measured
  3.74 ms and 3.33 ms after the extraction (3.54 ms mean). The original
  path measured 807 ms mean, so the final result retains the 99.6%
  reduction.
  
  ## Validation
  
  - `cargo check -p codex-connectors -p codex-core`
  - `just test -p codex-connectors` — 15 passed
  - `just test -p codex-core --lib connectors` — 35 passed
  - `just test -p codex-core --lib mcp_tool_exposure` — 5 passed
  - `just test -p codex-core --lib mcp_tool_call` — 72 passed
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `just fix -p codex-connectors`
  - `just fix -p codex-core`
  - `just fmt`

  Matthew Zeng · 2026-06-15 15:24:33 -07:00
  1fbaac1e50
• Add hidden Windows sandbox wrapper entrypoint (#28358)

  ## Why
  
  This is the second PR in the Windows fs-helper sandbox stack. The
  fs-helper path needs a Windows sandbox launcher that has the same
  argv-shaped contract as macOS `sandbox-exec` and `codex-linux-sandbox`,
  but this PR only introduces that hidden launcher. It does not route
  fs-helper through it yet.
  
  The hidden launcher still needs to be policy-complete before later
  direct-spawn callers use it. In particular, it has to carry the same
  Windows sandbox policy details that the existing spawn paths already
  understand: proxy enforcement, read/write root overrides, and
  deny-read/deny-write overrides.
  
  ## What Changed
  
  - Added the hidden `codex.exe --run-as-windows-sandbox` arg1 dispatch
  path.
  - Added `windows-sandbox-rs/src/wrapper.rs`, which parses the wrapper
  argv, launches the requested command through the shared Windows sandbox
  session runner from PR1, and forwards stdio.
  - Added `create_windows_sandbox_command_args_for_permission_profile()`
  so later direct-spawn callers can build the wrapper argv consistently.
  - Made the wrapper argv round-trip the full Windows sandbox policy
  surface it needs later: workspace roots, environment, permission
  profile, sandbox level, private desktop, proxy enforcement, read/write
  root overrides, and deny-read/deny-write overrides.
  - Carried `proxy_enforced` through the shared Windows session request so
  proxy-managed executions continue to use the offline/elevated sandbox
  identity.
  - Added wrapper argument round-trip coverage for the full policy fields.
  
  ## Verification
  
  - `just test -p codex-windows-sandbox windows_wrapper_args_round_trip`
  - `just test -p codex-arg0`
  - `just test -p codex-core exec::tests::windows_`
  - `just fix -p codex-windows-sandbox -p codex-core -p codex-cli`
  
  Local note: the full `just fmt` command still fails on this workstation
  in non-Rust formatter setup (`uv` cache access denied and missing
  `dotslash`/buildifier), but the Rust formatter phase completed.

  iceweasel-oai · 2026-06-15 21:30:32 +00:00
  fbbe7706d6
• [codex] Preserve plugin apps in connector listings (#27602)

  ## Context
  
  This is PR4 in the plugin auth-routing stack. The earlier PRs make
  plugin surface projection auth-aware and narrow App/MCP conflicts by App
  declaration name. This PR keeps connector listing paths aligned with
  that projected plugin App set.
  
  This means ChatGPT/SIWC users will still see plugin-provided Apps in
  connector listing surfaces like the Apps/connector picker, while API-key
  users will not see Apps they cannot use.
  
  ## Stack
  
  - PR1: #27652 seed plugin manager auth at construction.
  - PR2: #27459 route plugin surfaces by auth mode.
  - PR3: #27607 dedupe plugin MCP servers by App declaration name.
  - PR4: #27602 preserve plugin Apps in connector listings.
  - PR5: #27461 skip install-time plugin MCP OAuth for matching App
  routes.
  
  ## Summary
  
  - Have app-server compute effective plugin Apps from the existing
  PluginsManager and pass them into connector listing.
  - Keep plugin Apps visible in Apps/connector listing for ChatGPT/SIWC
  users.
  - Keep API-key-style auth from surfacing plugin Apps in connector
  listings.
  
  ## Validation
  
  ```bash
  cargo test -p codex-chatgpt connectors::tests
  cargo test -p codex-app-server list_apps_includes_plugin_apps_for_chatgpt_auth
  git diff --check
  ```

  felixxia-oai · 2026-06-15 13:50:08 +01:00
  cededa26c5
• Discover stdio MCP servers from selected executor plugins (#27870)

  ## Why
  
  **In short:** this PR discovers MCP registrations by reading a selected
  plugin's `.mcp.json` on its executor. #27884 then resolves those
  registrations in the shared catalog.
  
  `thread/start.selectedCapabilityRoots` can select a plugin root owned by
  an executor, and Codex can resolve that package through the executor
  filesystem. MCP declarations inside the selected plugin are still
  ignored.
  
  This PR adds the source-specific discovery layer on top of the
  selected-plugin catalog boundary in #27884:
  
  ```text
  selected capability root
          |
          v
  resolve the plugin through its executor filesystem
          |
          v
  read and normalize its MCP config through the same filesystem
          |
          v
  contribute stdio registrations bound to that environment ID
  ```
  
  The existing MCP launcher and connection manager remain unchanged. MCP
  config parsing is shared with local plugins through #27863.
  
  ## What changed
  
  - Added an executor plugin MCP provider in the MCP extension.
  - Retained only the exact filesystem capability used for package
  resolution and reused it for the selected plugin's MCP config, with no
  host-filesystem fallback or unrelated process/HTTP authority.
  - Read either the manifest-declared MCP config or the default
  `.mcp.json`; a missing default file means the plugin has no MCP servers.
  - Accepted stdio servers only for this first vertical. Executor-owned
  HTTP declarations are skipped with a warning until their placement
  semantics are defined.
  - Normalized stdio registrations with the owning environment's stable
  logical ID and plugin-root working directory.
  - Resolved environment-variable names on the owning executor and
  rejected explicit local forwarding for non-local plugins.
  - Froze discovered declarations once per active thread runtime, then
  applied current managed plugin and MCP requirements when contributing
  them.
  - Carried the selected root ID, display name, and selection order into
  the catalog contribution defined by #27884.
  
  ## Behavior and scope
  
  There is intentionally no production behavior change yet. This PR
  provides the executor provider and contribution boundary, but app-server
  does not install it in this change. Existing local plugin MCP loading is
  unchanged, and no MCP process is launched by this PR alone.
  
  ## Assumptions
  
  - The selected root ID is the plugin policy identity; the manifest
  display name is presentation metadata.
  - An environment ID is a stable logical authority. Reconnection or
  replacement under the same ID does not change ownership.
  - Selected plugin packages and their manifests are trusted inputs.
  - The selected package and MCP discovery snapshot remain frozen for the
  active thread runtime.
  
  ## Follow-up
  
  The next PR installs this contributor in app-server and adds an
  end-to-end test proving that a selected plugin MCP tool launches on its
  owning executor, can be called by the model, survives an explicit MCP
  refresh, and is invisible when its root was not selected.
  
  Resume, fork, environment removal or ID changes, dynamic catalog reload,
  and executor-owned HTTP MCP placement remain separate lifecycle
  decisions.
  
  ## Verification
  
  Focused tests cover executor-only filesystem reads, missing and
  malformed config, stdio filtering and normalization, managed
  requirements, package attribution, and selection order. CI owns
  execution of the test suite.

  jif · 2026-06-15 11:52:05 +02:00
  b3c423e475
• [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
• [codex] Pin bundled SQLite to fixed WAL-reset version (#27992)

  ## Summary
  
  Prevent dependency refreshes from silently downgrading Codex's bundled
  SQLite to a release affected by the WAL-reset corruption bug.
  
  SQLx 0.9 accepts a broad `libsqlite3-sys` range. An unrelated lock
  refresh therefore moved Codex from `libsqlite3-sys 0.37.0` back to
  `0.35.0`, changing the bundled SQLite runtime from 3.51.3 to 3.50.2.
  SQLite documents the affected versions and fix in [The WAL Reset
  Bug](https://www.sqlite.org/wal.html#the_wal_reset_bug) and the [SQLite
  3.51.3 changelog](https://www.sqlite.org/changes.html#version_3_51_3).

  Gabriel Peal · 2026-06-13 21:28:31 -07:00
  73c58011b3
• [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