1473 Commits

• chore(core) rm AskForApproval::OnFailure (#28418)

  ## Summary
  Deletes the OnFailure variant of the `AskForApproval` enum. This option
  has been deprecated since #11631.
  
  ## Testing
  - [x] Tests pass

  Dylan Hurd · 2026-06-23 12:13:54 -07:00
  2cf2a6a844
• core: use turn-owned world state for inline compaction (#29527)

  ## Why
  
  Follow-up to #29249 and its [compaction review
  thread](https://github.com/openai/codex/pull/29249#discussion_r3455055101).
  
  During a turn, environment readiness can change between sampling
  requests. Inline compaction must render the same model-visible
  `WorldState` used by the request it follows. Rebuilding that state
  during compaction can observe a newer environment, make replacement
  history disagree with what the model saw, and suppress the next
  environment update.
  
  ## What changed
  
  - Make `run_turn` own the current `Arc<WorldState>` and replace it only
  between sampling requests.
  - Build each state from an explicitly chosen environment snapshot, diff
  deferred-executor steps against the turn-owned state, and retain the
  latest state in `ContextManager` only for cross-turn and resume
  tracking.
  - Pass the exact turn-owned state into inline compaction and explicit
  new-context-window replacement.
  - Carry that state with
  `InitialContextInjection::BeforeLastUserMessage`, so replacement context
  and its stored baseline cannot come from different snapshots.
  - Remove obsolete state-recapture helpers and ambiguous TurnContext-only
  WorldState builders.
  - Add an integration test that moves an environment from starting to
  ready during a paused turn, triggers compaction, and verifies the next
  request receives the readiness update exactly once.
  
  ## Test plan
  
  - `just test -p codex-core
  deferred_executor_compaction_preserves_then_updates_environment_once`
  - `just test -p codex-core process_compacted_history`
  - `just test -p codex-core mid_turn_continuation_compaction`
  - `just test -p codex-core build_initial_context`
  - `just test -p codex-core
  ignores_session_prefix_messages_when_truncating`

  sayan-oai · 2026-06-23 10:33:19 -07:00
  d1d11cac05
• Shut down superseded MCP managers on refresh (#29608)

  ## Summary
  
  MCP refresh replaced the published connection manager without shutting
  down the manager it superseded. If another task retained that old
  manager, its stdio MCP processes stayed alive and accumulated across
  refreshes.
  
  Atomically swap in the refreshed manager, then explicitly shut down the
  exact manager returned by the swap. Add a process-level regression test
  that retains the old manager during refresh and verifies its stdio
  process exits while the replacement remains available.
  
  ## Context
  
  Explicit cleanup was lost when manager publication moved to `ArcSwap`.
  Dropping the old manager is not a reliable shutdown boundary because
  active callers can retain its `Arc` and underlying client process
  handles.

  jif · 2026-06-23 18:29:27 +01:00
  8751fd3fcb
• [core] debounce current-time reminders by elapsed time (#29659)

  ## Summary
  - rename `reminder_interval_model_requests` to
  `reminder_interval_seconds`
  - read the configured time provider before every model request and
  inject a reminder only after the configured number of seconds has
  elapsed
  - preserve immediate first delivery and forced delivery after compaction
  changes the context window
  
  ## Tests
  - `just test -p codex-core current_time_reminder`

  rka-oai · 2026-06-23 10:13:27 -07:00
  9fe689783d
• Share resumed rollout history (#28426)

  ## Summary
  
  Resuming a persisted thread currently deep-clones its complete rollout
  history several times. `InitialHistory` is retained for the app-server
  response, copied into thread persistence, and copied again by read-only
  accessors. These copies scale with the complete rollout rather than the
  bounded model context and add measurable latency for large sessions.
  
  This change stores resumed rollout history in `Arc<Vec<RolloutItem>>`.
  Rollout loading wraps the parsed vector once, while app-server response
  construction, session initialization, and thread persistence share it
  through inexpensive `Arc` clones. Read-only history access now returns a
  borrowed slice, and fork paths use `Arc::unwrap_or_clone` where they
  genuinely need mutable ownership. Rollout reconstruction also consumes
  its temporary context instead of cloning the reconstructed model
  history.
  
  The serialized representation remains unchanged. In an artificial 123 MB
  rollout benchmark, sharing resumed history reduced cold resume latency
  by roughly 9–10%. The affected crates compile with their test targets,
  all 80 thread-store tests pass, and the Bazel dependency lock remains
  valid.

  Charlie Marsh · 2026-06-23 10:23:25 -04:00
  330ae6a516
• Namespace multi-agent v2 tools under collaboration (#29067)

  ## Summary
  
  Multi-agent v2 tools now use the fixed `collaboration` namespace when
  namespace tools are available. This keeps the model-visible hint and the
  actual tool surface aligned around `functions.collaboration.*`, without
  exposing an unshipped namespace knob to users.
  
  The PR also removes the old `features.multi_agent_v2.tool_namespace`
  config/schema surface, updates the MAv2 test fixtures for namespaced
  calls, and fixes stale `TurnContext.features` references that were
  breaking `codex-core` builds.
  
  ## Changes
  
  - Expose MAv2 tools under `collaboration` instead of relying on a
  configurable namespace.
  - Remove `tool_namespace` from MAv2 TOML config, resolved config,
  validation, schema, and tests.
  - Update tool-planning and integration fixtures to assert or emit
  namespaced MAv2 tool calls.
  - Read feature state through `TurnContext.config.features` in the
  multi-agent mode context paths.
  
  ## Testing
  
  - `just write-config-schema`
  - `just test -p codex-features`

  jif · 2026-06-23 14:15:20 +02:00
  49614a0391
• Allow codex sandbox to consume MCP sandbox state (#29358)

  ## Summary
  
  - let `codex sandbox` accept the JSON value from
  `codex/sandbox-state-meta`
  - require the payload `permissionProfile` instead of falling back to
  ambient permissions
  - reuse the existing macOS, Linux, and Windows launch paths, treating
  external sandbox state conservatively as read-only
  - let opaque forwarders add runtime read roots and disable direct
  network access without decoding the payload
  
  Builds on #29113, which is now on `main`.
  
  ## Tests
  
  - `just test -p codex-cli debug_sandbox::tests`
  - `cargo build -p codex-rmcp-client --bin test_stdio_server`
  - `just test -p codex-core
  stdio_mcp_tool_call_includes_sandbox_state_meta`
  - `just test -p codex-mcp`
  - `just fmt`

  jif · 2026-06-23 10:17:52 +02:00
  d2484697b1
• [codex] Use input items for Responses Lite tools (#27946)

  When using Responses Lite, we should all use `additional_tools` and a
  developer item instead of the top level tools array & instructions
  field. This keeps things 1-to-1.
  
  Forced namespacing for _all_ tools will land in a following PR after
  some coordination & fixes in Responses API (around collisions & return
  items).
  
  The goal is to eventually expand the scope of this to _all_ requests
  from codex, but that will require larger coordination across providers &
  slower rollout.

  rka-oai · 2026-06-22 23:56:16 -07:00
  33cc928d33
• [codex] stylistic changes (#29068)

  ## Summary
  
  - express remote compaction result handling as an exhaustive match
  - preserve the special `TurnAborted` path without emitting a generic
  compaction error
  - rely on the standard `test_codex` provider setup in the compaction
  budget test
  
  Follow-up to review feedback on #28707.
  
  ## Testing
  
  - `just test -p codex-core
  compaction_budget_exhaustion_aborts_without_error_or_retry`
  - `just fmt`

  rka-oai · 2026-06-22 23:17:12 -07:00
  802c98cab4
• [codex] Expose service tier and reasoning effort in OTEL (#29155)

  ## Summary
  
  NVIDIA asked to measure Fast mode usage and reasoning effort from Codex
  CLI OTEL logs. Add the finalized `service_tier` and
  `model_reasoning_effort` to the existing `codex.sse_event`
  `response.completed` record.
  
  This intentionally reuses the existing completion event and leaves
  transport APIs and shared telemetry plumbing unchanged.
  
  ## Testing
  
  - `cargo build -p codex-cli --bin codex`
  - `just test -p codex-core responses_api_emits_api_request_event`
  - End-to-end with the built CLI and a local OTLP/HTTP collector:
  - Fast/high emitted `service_tier=priority` and
  `model_reasoning_effort=high` with token usage.
  - Standard/low omitted `service_tier` and emitted
  `model_reasoning_effort=low` with token usage.

  daniel-oai · 2026-06-22 20:44:48 -07:00
  e0ac5d3c15
• Propagate safety buffering treatment metadata (#29473)

  ## Summary
  
  - read the request-scoped safety-buffering treatment from HTTP response
  headers and per-turn WebSocket metadata through one shared header parser
  - combine that treatment with Responses API safety-buffering signals
  - propagate `showBufferingUi` and nullable `fasterModel` through the
  existing `model/safetyBuffering/updated` app-server notification
  - update the app-server documentation and generated JSON and TypeScript
  schemas
  
  The public implementation contains no model mapping or real model
  identifier. Tests and protocol examples use generic `current-model` and
  `faster-model` placeholders only.
  
  ## Dependencies
  
  - server-side treatment evaluation:
  https://github.com/openai/openai/pull/1060247
  - initial Responses API safety-buffering propagation:
  https://github.com/openai/codex/pull/29371
  - Codex App UI: https://github.com/openai/openai/pull/1057789
  
  ## Validation
  
  - Codex API tests: 129 passed
  - focused Codex core safety-buffering integration test passed
  - app-server protocol tests passed after regenerating schema fixtures
  - Clippy fix and repository formatting completed successfully
  
  The broader app-server run compiled all changed crates and completed
  with 1,269 passing tests. Its remaining failures were unrelated
  environment limitations: macOS sandbox application was denied, one
  expected test binary was unavailable, and several existing subprocess
  tests timed out as a result.

  Francis Chalissery · 2026-06-22 19:51:03 -07:00
  7c22d376e5
• mcp: accept foreign absolute cwd for remote stdio (#29493)

  ## Why
  
  Remote stdio MCP servers can run in an environment whose path convention
  differs from the Codex host. A Windows cwd such as
  `C:\Users\openai\share` is absolute for the executor but was rejected by
  a POSIX orchestrator.
  
  Built on #29501, now merged, which only clarifies the host-native
  `PathUri` constructor name.
  
  ## What changed
  
  - Deserialize MCP cwd values as `LegacyAppPathString` so config does not
  apply host path rules.
  - Interpret that spelling as host-native for local launches and convert
  it to `PathUri` at executor launch.
  - Skip host filesystem and command resolution checks for remote stdio in
  `codex doctor`.
  - Add host-independent config and executor-boundary coverage using the
  foreign path convention for each test platform.
  
  ## Validation
  
  - `just test -p codex-utils-path-uri -p codex-config -p codex-mcp -p
  codex-rmcp-client` (408 passed)
  - `just test -p codex-cli -p codex-rmcp-client` (372 passed)
  - `cargo check --workspace --tests`
  - `just test` (11,311 passed; 43 unrelated environment/timing failures)
  - `just fix -p codex-cli -p codex-config -p codex-core -p codex-mcp -p
  codex-mcp-extension -p codex-rmcp-client -p codex-tui`

  Adam Perry @ OpenAI · 2026-06-23 01:33:51 +00:00
  67009bc53f
• chore: warn when Code Mode lacks model metadata (#29490)
  Celia Chen · 2026-06-23 01:15:11 +00:00
  3310fc8ae5
• path-uri: clarify host-native path conversion (#29501)

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

  Adam Perry @ OpenAI · 2026-06-23 00:02:33 +00:00
  11fab432be
• [codex] Use tool search for MCP tools by default (#29486)

  ## Why
  
  MCP tools were only placed behind `tool_search` when a feature flag was
  enabled or when there were at least 100 tools. That made the model's
  tool flow depend on both rollout configuration and the number of
  installed tools.
  
  The searched-tool flow is now the intended behavior. Making it
  unconditional when the model and provider support it gives every
  supported setup the same behavior and lets us retire the feature flag
  safely.
  
  ## What changed
  
  - Defer all effective MCP tools when `tool_search` and namespaced tools
  are supported.
  - Keep exposing MCP tools directly when search cannot be used, so older
  or unsupported model/provider combinations still work.
  - Mark `tool_search_always_defer_mcp_tools` as removed and ignore old
  configured values.
  - Keep plugin filtering, app-only filtering, file handling, and MCP
  calls working through the searched-tool flow.
  
  ## Why many tests changed
  
  Many tests used to act as if the model could see MCP tools in its first
  request and call them immediately. That is no longer the real flow: the
  model first receives `tool_search`, searches for a tool, receives the
  matching MCP tool, and then calls it in the next request.
  
  The tests therefore needed an extra search step, and checks for tool
  names, descriptions, and input fields had to move from the first request
  to the search result. These are not separate product changes; they make
  the tests follow what the model will actually see after this change. The
  plugin tests still check which tools are allowed and where they came
  from, the file tests still check upload fields and behavior, and the MCP
  round-trip test still checks a successful call from start to finish.
  
  ## Tests
  
  - `just test -p codex-features`
  - Focused `codex-core` tests for MCP exposure and tool planning
  - `just test -p codex-core explicit_plugin_mentions`
  - `just test -p codex-core stdio_server_round_trip`
  - Focused `codex-core` tests for tool search, app-only tools, and MCP
  file uploads

  sayan-oai · 2026-06-22 16:45:23 -07:00
  c53b1dae09
• feat(core): store turn_id on ResponseItem metadata (#28360)

  ## Description
  
  This PR is a followup to https://github.com/openai/codex/pull/28355 and
  starts assigning `internal_chat_message_metadata_passthrough.turn_id` to
  durable Responses API items created during a turn.
  
  The goal is that those items keep the `turn_id` that introduced them
  when Codex resends stateless HTTP context, reconstructs history for
  resume/fork paths, or reuses websocket response state.
  
  ## What changed
  
  - Set `internal_chat_message_metadata_passthrough.turn_id` when missing
  as response items enter durable history, initial/replacement history,
  inter-agent communication history, and local compaction summaries.
  - Preserve existing item turn IDs instead of overwriting them during
  persistence, resume reconstruction, compaction, forked history, and
  websocket incremental reuse.
  - Keep `compaction_trigger` fieldless because it is a request control,
  not a durable response item.
  - Update focused history/request assertions and fixtures for stateless
  requests, websocket incrementals, compaction, thread injection, prompt
  debug, and related CI coverage.

  Owen Lin · 2026-06-22 16:45:14 -07:00
  4a82ecc3c9
• [codex] replace remote images with model-visible error text (#29417)

  ## What
  
  This PR will extend the existing centralized image-preparation path to
  replace HTTP(S) image inputs with a model visible error message. It
  won't "ruin" and break existing rollouts, but it will deprecate support
  for the pathway. App server clients should no longer use HTTP image urls
  if they'd like to upgrade.
  
  The HTTP image url pathway is currently resolved in the responsesapi. It
  is slow and not reccomended.
  
  ## Behavior
  
  - HTTP(S) image URL: replace with `input_text`
  - data URL: use the existing decode and resize path
  - other image URL schemes: leave unchanged
  
  This intentionally does not change app-server ingress. That validation
  remains a follow-up.
  
  ## Test plan
  
  - `just test -p codex-core -E
  'test(/image_preparation|prepares_image_failures_before_history_insertion|prepares_resumed_history_before_installing_it|responses_lite_prepares_images/)'`
  — 7 passed
  - `just fix -p codex-core`
  - `just fmt`

  rka-oai · 2026-06-22 16:41:00 -07:00
  7153affa0f
• core: wrap token budget window context (#29494)

  Token-budget initial context carries thread and context-window lineage
  that the model should treat as one structured context-window block.
  Wrapping it in `<context_window>` makes that boundary explicit while
  preserving the existing window id content.
  
  Before this change, the window identifiers were injected as an untagged
  developer text fragment:
  
  ```text
  Thread id <THREAD_ID>.
  First context window id: <FIRST_WINDOW_ID>
  Current context window id: <WINDOW_ID>
  Previous context window id: <PREVIOUS_WINDOW_ID>
  ```
  
  After this change, the same payload is wrapped as a context-window
  block:
  
  ```text
  <context_window>
  Thread id: <THREAD_ID>
  First context window id: <FIRST_WINDOW_ID>
  Current context window id: <WINDOW_ID>
  Previous context window id: <PREVIOUS_WINDOW_ID>
  </context_window>
  ```
  
  This adds shared `CONTEXT_WINDOW_*_TAG` protocol constants, updates
  `TokenBudgetContext` to render with those markers, treats the new
  wrapper as contextual developer content when mapping history, and
  refreshes the token-budget request-shape assertions and snapshot.
  
  Verification:
  - `just test -p codex-core token_budget`
  - `just test -p codex-core
  recognizes_context_window_as_contextual_developer_content`

  Michael Bolin · 2026-06-22 23:37:49 +00:00
  f1945de3b7
• [codex] configure rollout budget reminder thresholds (#29423)

  ## Summary
  
  Instead of:
  
      reminder_interval_tokens = 65_536
  
  allow users to configure explicit remaining-token reminder thresholds:
  
  reminder_at_remaining_tokens = [65_536, 32_768, 16_384, 8_192, 4_096,
  2_048, 1_024, 512]
  
  ## Validation
  
  - CARGO_INCREMENTAL=0 just test -p codex-core rollout_budget: 9 passed
  - just fix -p codex-core
  - just fmt

  rka-oai · 2026-06-22 13:25:48 -07:00
  bd5bd953fb
• PAC 2 - Add shared auth system proxy contract (#26707)

  ## Summary
  
  Stacked on #26706.
  
  Adds the shared auth/system-proxy contract that later platform resolver
  PRs plug into. This PR moves Codex-owned auth and startup HTTP clients
  through a common route-aware boundary, but does not yet add Windows or
  macOS system proxy resolution.
  
  The default path remains unchanged when `respect_system_proxy` is absent
  or disabled.
  
  ## Implementation
  
  - Adds `codex-client/src/outbound_proxy.rs` with the shared
  route-selection model:
    - `OutboundProxyConfig`;
    - `ClientRouteClass`;
    - `RouteFailureClass`;
    - `build_reqwest_client_for_route`.
  - Preserves the existing reqwest/default-client behavior when no route
  config is supplied.
  - Uses the fixed MVP routing policy when route config is supplied:
  platform system/PAC/WPAD discovery, then explicit env proxy variables,
  then direct connection.
  - Keeps platform-specific system discovery behind the shared client
  boundary. This PR provides the contract and fallback behavior; later
  resolver PRs plug in Windows and macOS discovery.
  - Adds `login::AuthRouteConfig` so auth call sites depend on a small
  policy type instead of platform resolver details.
  - Maps the resolved `Config.respect_system_proxy` boolean into
  `AuthRouteConfig` for auth-owned clients.
  - Wires the route config through browser login, device-code login,
  access-token login, login status, logout/revoke, token refresh, API-key
  exchange, app-server account login, TUI/app startup, cloud-config
  bootstrap, cloud tasks, plugin auth, and exec startup config loading.
  
  ## End-user behavior
  
  - No behavior changes by default.
  - When `respect_system_proxy = true`, auth-owned clients opt into the
  shared route-aware client path.
  - On platforms without a resolver implementation in this PR, system
  discovery is unavailable and the route-aware path falls back to explicit
  env proxy handling, then direct connection.
  - Custom CA handling remains separate from proxy route selection and
  still runs through the shared client builder.
  - No proxy URLs, PAC contents, or resolved platform details are exposed
  through the public config surface introduced here.
  
  ## Tests
  
  Adds or updates coverage for:
  
  - preserving default auth-client fallback behavior when no route config
  is provided;
  - injected environment-proxy fallback without mutating process
  environment;
  - existing login-server E2E flows using explicit `auth_route_config:
  None` to guard unchanged default behavior;
  - updated auth manager, login, logout, cloud-config, startup, and
  plugin-auth call sites passing route config explicitly.

  canvrno-oai · 2026-06-22 13:03:11 -07:00
  1659c4a629
• [codex] Start the guardian child session when parent session is started (#27982)

  ## Why
  
  The first auto-review currently creates its Guardian child session on
  demand, adding avoidable latency before the review can begin. Creating
  the ordinary Guardian child during parent-session initialization lets
  that child use the existing session startup WebSocket prewarm before the
  first escalation. This does not introduce a Guardian-specific prewarm
  mechanism.
  
  ## What changed
  
  - initialize the existing Guardian review-session manager owned by
  `Session` when a thread starts with auto-review enabled and an approval
  policy that routes to Guardian
  - use the standard Guardian child-session construction and the existing
  session startup WebSocket prewarm
  - preserve the existing reuse-key invalidation and lazy creation
  fallback when startup initialization fails or the effective review
  configuration changes
  - add an integration test that verifies normal root-session startup
  emits a Guardian `generate=false` prewarm request
  
  ## Benchmark
  
  I compared release builds against main. Each prompt first ran a
  non-escalated `sleep 3`, then requested an escalated marker command.
  
  | binary | count | avg Guardian duration | median Guardian duration |
  avg Guardian TTFT |
  |---|---:|---:|---:|---:|
  | origin-main | 10 | 4008.7 ms | 3949.5 ms | 3746.5 ms |
  | session-fix | 10 | 2865.0 ms | 2594.0 ms | 2492.7 ms |
  
  Guardian duration fell by 28.5% and Guardian TTFT fell by 33.5%. These
  measurements cover Guardian review latency; they do not measure parent
  thread-start latency.

  jgershen-oai · 2026-06-22 11:54:44 -07:00
  15f448d8b0
• core: rename metadata -> internal_chat_message_metadata_passthrough (#28968)

  ## Description
  This PR cuts Codex over from generic `ResponseItem.metadata` (introduced
  here: https://github.com/openai/codex/pull/28355) to
  `ResponseItem.internal_chat_message_metadata_passthrough`, which is the
  blessed path and has strongly-typed keys.
  
  For now we have to drop this MAv2 usage of `metadata`:
  https://github.com/openai/codex/pull/28561 until we figure out where
  that should live.

  Owen Lin · 2026-06-22 11:11:25 -07:00
  5b95745eae
• Report remote sandbox denials semantically (#29424)

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

  jif · 2026-06-22 19:33:28 +02:00
  9f06cf1a09
• remove flag for image preparation (#29429)

  ## What
  
  - make Fjord's centralized response-item image preparation unconditional
  for new and resumed history
  - have local user images and `view_image` outputs always defer decoding
  and resizing to that path
  - retain `resize_all_images` as an ignored, removed compatibility key
  for released clients
  - delete the flag-off producer paths and obsolete policy-specific tests
  
  ## Why
  
  Centralized preparation is now the intended image path. Keeping the
  runtime feature checks also kept two image-processing implementations
  alive and allowed client config to select the legacy behavior.
  
  This is a clean replacement for #28975, rebuilt from the latest `main`.
  
  ## How
  
  `prepare_response_items` now runs whenever items enter history and
  whenever persisted history is reconstructed. Producers emit deferred
  image data, so malformed images become the existing model-visible
  placeholder instead of failing the session at the producer.
  
  ## Test plan
  
  - `just fmt`
  - `just fix -p codex-core -p codex-features`
  - `just test -p codex-features` — 52 passed
  - focused affected `codex-core` set — 20 passed
  - `just test -p codex-core handle_accepts_explicit_high_detail` — 1
  passed
  - full `just test -p codex-core` attempt — 2,723 passed; 88 unrelated
  environment failures from read-only `~/.codex` SQLite state and
  unavailable integration helper binaries

  rka-oai · 2026-06-22 10:05:11 -07:00
  e79d72d75d
• core: refresh environment context before sampling (#29073)

  ## Why
  
  Nonblocking environment snapshots allow a turn to reach the model while
  a remote environment is still starting. The initial context can describe
  that environment as still loading, but nothing currently refreshes the
  model-visible environment context when startup finishes during the same
  turn.
  
  This adds the first request-scoped reconciliation slice on top of
  #28683. It is gated by `DeferredExecutor` and intentionally updates only
  model-visible environment context; tools and other environment-derived
  state will migrate separately.
  
  ## What
  
  - Add a minimal `StepContext` containing the environment snapshot
  captured before each sampling request.
  - Render attached environments with their resolved shell and starting
  environments with `still loading`.
  - Track the latest environment state recorded in model history and
  append a bounded update only when it changes.
  - Seed that baseline from full initial context so ready-at-start
  environments are not duplicated.
  - Clear the in-memory baseline when history is rewritten so replacement
  history can be refreshed safely.
  
  ## Testing
  
  - `just test -p codex-core deferred_executor`
  - `just test -p codex-core
  environment_context_baseline_deduplicates_until_history_is_replaced`
  
  The integration coverage verifies that a pending environment reaches the
  first request, the ready state reaches the next request, later requests
  do not duplicate it, and ready-at-start environments remain
  single-injected.
  
  <details>
  <summary>Live verification</summary>
  
  - Connected to a real remote executor with startup deliberately delayed
  and forced three sampling requests in one turn.
  - Inspected the raw model inputs: request 1 showed the remote
  environment as `still loading`, request 2 appended its ready shell and
  cwd, and request 3 contained no duplicate ready update.
  - With the feature disabled, startup waited for the delayed executor and
  the first request contained only the ready environment.
  - With a synchronously ready environment and the feature enabled, the
  first request contained one environment context with no duplicate.
  - Executed `pwd` and read a marker file through the remote process
  runner; the command exited successfully and returned the remote cwd and
  marker contents.
  
  </details>

  sayan-oai · 2026-06-22 08:47:43 -07:00
  22886f21de
• Simplify multi-agent mode controls (#29324)

  ## Why
  
  Multi-agent delegation policy was split across `multiAgentMode`,
  `features.multi_agent_mode`, and `usage_hint_enabled`. These controls
  could disagree: a requested mode could be downgraded by the feature
  flag, and disabling usage hints also disabled mode instructions.
  
  Some clients also need multi-agent tools without adding
  delegation-policy text to model context. The previous two-mode API could
  not express that directly.
  
  ## What changed
  
  `multiAgentMode` is now the only live delegation-policy control:
  
  | Mode | Behavior |
  | --- | --- |
  | `none` | Keep multi-agent tools available without adding mode
  instructions. |
  | `explicitRequestOnly` | Only delegate after an explicit user request.
  |
  | `proactive` | Delegate when parallel work materially improves speed or
  quality. |
  
  - new threads default to `explicitRequestOnly`; omitting the mode on
  later turns keeps the current value
  - thread start, resume, fork, and settings responses always report the
  concrete current mode instead of `null`
  - mode selection remains sticky across turns and resume
  - usage-hint text no longer controls whether mode instructions apply
  - `features.multi_agent_mode` and `usage_hint_enabled` remain accepted
  as ignored compatibility settings so existing configs continue to load
  - app-server documentation and generated schemas describe the three-mode
  API
  
  ## Tests
  
  - `just test -p codex-core multi_agent_mode`
  - `just test -p codex-core multi_agent_v2_config_from_feature_table`
  - `just test -p codex-core spawn_agent_description`
  - `just test -p codex-features`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server multi_agent_mode`

  jif · 2026-06-22 10:05:36 +02:00
  c03742ca0a
• Persist session IDs across thread resume (#29327)

  ## Summary
  
  A cold-resumed subagent kept its durable thread ID but could receive a
  new session ID, splitting one agent tree across multiple sessions after
  a restart.
  
  Persist the root session ID in every rollout `SessionMeta`, carry it
  through thread creation, and restore it before initializing the resumed
  `Session` and `AgentControl`.
  
  ## Behavior
  
  For a nested agent tree:
  
  ```text
  root session R
    parent thread P
      child thread C
  ```
  
  The child rollout stores:
  
  ```text
  session_id:       R
  parent_thread_id: P
  id:               C
  ```
  
  After a cold resume, the child still belongs to root session `R` while
  its immediate parent remains `P`. The integration coverage uses distinct
  values for all three IDs so it catches restoring the session from
  `parent_thread_id`.
  
  ## Legacy rollouts
  
  Previous rollouts have `id` but no `session_id`. `SessionMetaLine`
  deserialization treats a missing `session_id` as `id`, keeping those
  files readable, listable, and resumable. When a legacy subagent is
  resumed through its root, that synthesized child ID no longer overrides
  the inherited root-scoped `AgentControl`. New rollouts always persist
  the explicit root session ID.

  jif · 2026-06-22 09:36:08 +02:00
  6d15bb3d17
• Propagate safety buffering events to app-server clients (#29371)

  Responses API safety buffering metadata currently stops at the transport
  boundary, so app-server clients cannot render the in-progress safety
  review state.
  
  This change:
  - decodes and deduplicates `safety_buffering` metadata from Responses
  API SSE and WebSocket events without suppressing the original response
  event
  - emits a typed core event containing the requested model plus backend
  use cases and reasons
  - forwards that event as `turn/safetyBuffering/updated` through
  app-server v2 and updates generated protocol schemas
  - keeps the side-channel event out of persisted rollouts and turn timing
  
  This supports the Codex Apps buffering UX and depends on the Responses
  API backend work in https://github.com/openai/openai/pull/1044569 and
  https://github.com/openai/openai/pull/1044571.
  
  Validation:
  - focused `codex-core` safety-buffering integration test passes
  - `cargo check -p codex-core -p codex-app-server -p
  codex-app-server-protocol`
  - `just fix -p codex-api -p codex-protocol -p codex-core -p
  codex-app-server-protocol -p codex-app-server -p codex-rollout -p
  codex-rollout-trace -p codex-otel`
  - `just fmt`
  - broad package test run: 4,430/4,492 passed; 62 unrelated
  local-environment/concurrency failures involved unavailable test
  binaries, MCP subprocess setup, and app-server timeouts

  Francis Chalissery · 2026-06-22 03:39:14 +00:00
  566f7bf631
• [codex] Add internal auto-compaction opt-out (#28260)

  ## Summary
  
  - add a default-on `auto_compaction` feature flag as an internal escape
  hatch
  - skip pre-turn, model-switch/hash, and mid-turn automatic compaction
  when the flag is disabled
  - preserve manual `/compact` behavior and surface the existing
  context-window error when the provider runs out of room
  - add integration coverage for disabled pre-turn and mid-turn compaction
  
  ## Motivation
  
  Long-running SPO optimization rollouts need the option to preserve their
  full context and fail on context exhaustion instead of entering another
  compaction window. This deliberately uses the existing feature-flag
  mechanism rather than adding a dedicated public config or app-server
  API.
  
  Disable it with:
  
  ```sh
  codex --disable auto_compaction
  ```
  
  ## Testing
  
  - `just test -p codex-features` — 51 passed
  - `just test -p codex-core auto_compaction_feature_disabled` — 2 passed
  - `just fix -p codex-core -p codex-features`
  - `just write-config-schema`
  - `just test -p codex-core` — the new compaction tests passed; the
  overall local run had 54 unrelated environment failures, primarily
  missing first-party test binaries and shell-snapshot timeouts

  rhan-oai · 2026-06-21 20:11:50 -07:00
  b21f0e7a98
• [codex] simplify token budget context (#29295)

  ## Why
  
  The token-budget feature currently adds remaining-token messages
  whenever usage crosses the 25%, 50%, and 75% thresholds. Those periodic
  inserts create prompt churn without requiring action, while the
  near-compaction reminder and explicit `get_context_remaining` tool
  already cover actionable and on-demand budget information.
  
  The context-window lineage block is also easier to scan as plain labeled
  text than as a `<token_budget>`-wrapped fragment.
  
  ## What changed
  
  - Stop recording automatic remaining-token messages at percentage
  thresholds.
  - Render context-window lineage in `First`, `Current`, `Previous` order
  with colon-separated labels.
  - Omit the `Previous` line for the first context window.
  - Remove `<token_budget>` wrappers from newly rendered lineage,
  near-compaction reminders, and `get_context_remaining` output.
  - Keep recognizing legacy wrapped fragments so existing rollouts remain
  compatible.
  - Remove the post-sampling token snapshot that was only needed by the
  periodic threshold path.
  
  ## Testing
  
  - `just test -p codex-core token_budget` (11 tests passed)

  pakrym-oai · 2026-06-20 21:50:09 -07:00
  aaf737fa59
• [codex] add configurable token budget compaction reminder (#29255)

  ## Why
  
  The token-budget feature reports coarse remaining-context milestones,
  but it does not give the model a configurable wrap-up prompt before
  automatic compaction. A strict threshold-crossing check can also miss
  resumed or reconfigured windows that are already inside the threshold.
  
  ## What changed
  
  - Add structured `[features.token_budget]` configuration for an absolute
  `reminder_threshold_tokens` and bounded `reminder_message_template`;
  `{n_remaining}` is expanded when the reminder is delivered.
  - Compute remaining tokens against the next effective auto-compaction
  boundary, including scoped `body_after_prefix` accounting and the full
  context-window limit.
  - Make reminder delivery level-triggered before and after sampling, with
  one-shot state owned by `AutoCompactWindow` and re-armed on compaction,
  `new_context`, restore, or history replacement.
  - Leave the existing initial full-window token-budget context, 25/50/75%
  notices, and token-budget tools unchanged.
  - Persist the resolved feature configuration in the session config lock
  and regenerate the config schema.
  
  ## Validation
  
  - `just test -p codex-core token_budget`
  - `just test -p codex-core
  token_budget_reminder_emits_after_crossing_compaction_threshold`
  - `just test -p codex-core auto_compact_window`
  - `just test -p codex-core
  lock_contains_prompts_and_materializes_features`
  - `just test -p codex-features`
  - `just test -p codex-config`

  pakrym-oai · 2026-06-20 19:13:42 -07:00
  6df037d47f
• [codex] prototype mcp_history thread hint injection (#29259)

  ## Why
  
  Prototype whether the harness can invoke the `mcp_history` MCP while
  constructing full initial context and expose its thread hint to the
  model without requiring a model-issued tool call.
  
  The prototype builds on the context-window lineage added by #29256 and
  is now based directly on `main`.
  
  ## What changed
  
  - Call `mcp_history/thread_hint` with no arguments while building the
  full `<token_budget>` context.
  - Pass the current `threadId` through MCP request metadata, matching the
  normal MCP tool-call path.
  - Serialize only the unstructured `content` result and append it inside
  `<token_budget>` when the call succeeds.
  - Omit the additional context when the MCP call or content serialization
  fails.
  
  ## Prototype limitations
  
  - The direct call bypasses the normal model-initiated MCP approval,
  lifecycle-event, telemetry, and result-sanitization path.
  - The call has no prototype-specific timeout, result-size cap, or
  per-window cache.
  - MCP latency is added to full-context construction, including
  applicable compaction paths.
  
  ## Validation
  
  - `just test -p codex-core token_budget`

  pakrym-oai · 2026-06-20 18:02:02 -07:00
  b6d6be2a84
• core: add context window lineage IDs (#29256)

  ## Why
  
  The rendered `<token_budget>` fragment identifies the thread and current
  context window, but it does not expose enough lineage to identify the
  first window in the thread or the immediately preceding window. Those
  IDs also need to remain stable across compaction, resume, and rollback.
  
  ## What changed
  
  - Track first, previous, and current UUIDv7 context-window IDs in
  auto-compaction state.
  - Render `thread_id`, `first_window_id`, `previous_window_id`, and the
  current window ID in the full `<token_budget>` fragment.
  - Persist the first and previous window IDs in compacted rollout
  checkpoints and restore them during rollout reconstruction.
  - Preserve compatibility with older compacted records that do not
  contain the new optional fields.
  - Update focused state, rendering, reconstruction, rollback, and
  serialization coverage.
  
  ## Validation
  
  - `just test -p codex-core token_budget`
  - `just test -p codex-protocol compacted_item::tests`
  - `just test -p codex-core tracks_prefill_and_window_boundaries`
  - `just test -p codex-core
  reconstruct_history_uses_replacement_history_verbatim`
  - `just test -p codex-core
  thread_rollback_restores_cleared_reference_context_item_after_compaction`

  pakrym-oai · 2026-06-20 13:15:49 -07:00
  d1209bddfc
• Add config toggles for orchestrator skills and MCP (#28942)

  ## Why
  
  Orchestrator-provided skills and Codex Apps MCP tools add model-visible
  instructions, resources, and tools beyond the local workspace. Hosts
  need config-level switches to disable those orchestrator-owned surfaces
  independently, without disabling regular skills or regular MCP servers.
  
  ## What changed
  
  - Adds `[orchestrator.skills].enabled` and `[orchestrator.mcp].enabled`
  config entries, both defaulting to `true`.
  - Includes the new settings in `config.schema.json` and in the config
  lock so resolved thread configuration preserves the same orchestrator
  exposure decisions.
  - Threads `orchestrator.skills.enabled` through the app-server skills
  extension so disabled orchestrator skills do not expose the `skills`
  namespace or inject orchestrator skill context.
  - Gates Codex Apps MCP exposure, app instructions, and app auth
  eligibility on `orchestrator.mcp.enabled` while leaving non-Codex-Apps
  MCP tools available.
  - Updates the thread-manager sample config to disable both
  orchestrator-owned surfaces.
  
  ## Verification
  
  - Added config parsing, loading, defaulting, and schema coverage for the
  new settings.
  - Added MCP exposure coverage that `orchestrator.mcp.enabled = false`
  removes Codex Apps tools while preserving regular MCP tools.
  - Added app-server coverage that `orchestrator.skills.enabled = false`
  prevents orchestrator skill tools, prompts, and resource reads from
  reaching the model turn.

  jif · 2026-06-19 14:42:26 +02:00
  81b000421d
• Add indexed web search mode (#28489)

  ## Summary
  
  - Add `web_search = "indexed"` alongside `disabled`, `cached`, and
  `live`.
  - Use that same resolved mode for both hosted and standalone web search.
  - For hosted search, send `index_gated_web_access: true` with external
  web access enabled only when `indexed` is selected.
  - For standalone search, preserve the existing boolean wire values for
  existing modes (`cached` maps to `false` and `live` to `true`) and send
  `"indexed"` only for `indexed`; `disabled` keeps the tool unavailable.
  - Carry the mode through managed configuration requirements and
  generated schemas.
  
  ## Why
  
  Indexed search provides a middle ground between cached-only search and
  unrestricted live page fetching. Search queries can remain live while
  direct page fetches are limited to URLs admitted by the server.
  
  The existing `web_search` setting remains the single source of truth, so
  hosted and standalone executors cannot drift into different access
  modes. Without an explicit `indexed` selection, the existing
  model-visible tool and request shapes are unchanged.
  
  ```toml
  web_search = "indexed"
  
  [features]
  standalone_web_search = true
  ```
  
  ## Validation
  
  - `just fmt`
  - `just test -p codex-api` (`126 passed`)
  - `just test -p codex-web-search-extension` (`7 passed`)
  - `just test -p codex-core
  code_mode_can_call_indexed_standalone_web_search` (`1 passed`)
  - Focused configuration, hosted request, standalone request, and
  managed-requirement coverage is included in the PR; remaining suites run
  in CI.
  
  The full workspace test suite was not run locally.

  Winston Howes · 2026-06-19 05:35:57 -07:00
  3a2712ea14
• Scope network approvals by environment (#28899)

  Stacked on #28766.
  
  ## Why
  
  Network approvals are environment-scoped: allowing a host in one
  execution environment should not allow the same host in another
  environment.
  
  #28766 adds the inert IDs and constructor plumbing. This PR applies the
  behavior on top.
  
  ## What changed
  
  - Route managed network traffic through per-environment HTTP and SOCKS
  proxy listeners.
  - Stamp HTTP, HTTPS CONNECT, SOCKS TCP, and SOCKS UDP policy requests
  with the source environment at the proxy boundary.
  - Carry the selected execution environment through shell, unified exec,
  zsh-fork, and sandbox transform paths.
  - Include the environment in pending, approved-for-session, and
  denied-for-session network approval cache keys.
  - Include the environment in approval IDs and approval prompts.
  - Preserve legacy fallback for unattributed requests, but deny when
  active-call attribution is ambiguous.
  - Fail closed if an environment-specific proxy endpoint cannot be
  prepared.
  
  ## Validation
  
  - just fmt
  - CI will run tests and clippy

  jif · 2026-06-19 13:49:45 +02:00
  bd5d31b250
• [codex] abort turns when rollout budgets expire (token budget 3/3) (#28707)

  ## Stack
  
  Depends on #28494.
  
  ## Description
  
  This PR propagates shared rollout-budget exhaustion through the existing
  `CodexErr::TurnAborted` task result.
  
  Each thread records its model usage against the same ledger. Once the
  ledger is exhausted, that usage update and all later usage updates
  return `TurnAborted`. The task wrapper emits the normal aborted-turn
  event and lifecycle instead of completing the turn.
  
  This is intentionally a soft boundary: there is no cross-thread
  `Op::Interrupt` fanout. An in-flight thread can finish its current
  response before it observes the exhausted ledger, but every thread
  aborts at its next usage-accounting boundary.
  
  ## Tests
  
  The integration coverage verifies that:
  
  - the response that exhausts the budget aborts its turn;
  - a later response also aborts because the shared ledger remains
  exhausted; and
  - sub-agent usage draws from the same shared ledger; and
  - local and remote-v2 compaction abort without retrying or emitting a
  generic error.
  
  Local checks:
  
  - `just test -p codex-core
  exhausted_budget_aborts_current_and_later_turns`
  - `just test -p codex-core subagent_usage_draws_from_the_shared_budget`
  - `just test -p codex-core
  abort_regular_task_emits_marker_before_turn_aborted`
  - `just test -p codex-core
  compaction_budget_exhaustion_aborts_without_error_or_retry`
  - `just fix -p codex-core`
  - `just fmt`
  - `git diff --check`
  
  The full workspace test suite was not run locally.

  rka-oai · 2026-06-19 02:00:01 -07:00
  dac588f413
• Expose thread-level multi-agent mode (#28792)

  ## Why
  
  Once multi-agent mode can be selected per turn, clients also need to
  choose the initial selection when creating a thread and observe that
  selection through lifecycle and settings APIs.
  
  The selected value is intentionally distinct from the effective
  model-visible value: no client selection is represented as `null`, even
  though an eligible multi-agent v2 turn derives `explicitRequestOnly` as
  its effective default.
  
  ## What changed
  
  - Add the optional experimental `thread/start.multiAgentMode` parameter
  and pass it through thread creation.
  - Preserve an omitted initial value as an unset selection rather than
  eagerly storing `explicitRequestOnly`.
  - Apply an explicit `thread/start` selection to the first turn through
  the session configuration established at thread creation.
  - Restore the latest persisted effective mode as the selected baseline
  on cold resume when rollout history contains one.
  - Inherit the optional selected mode from a loaded parent when creating
  related runtime threads.
  - Return the current selected `multiAgentMode` from `thread/start`,
  `thread/resume`, `thread/fork`, and thread settings, using `null` when
  no mode is selected.
  - Keep lifecycle reporting independent from model capability and feature
  eligibility; core turn construction remains responsible for calculating
  and persisting the effective mode.
  
  ## Not covered
  
  - Clearing an existing loaded-session selection back to unset through
  `turn/start`; omitted or `null` currently retains the session's
  selection.
  - A TUI control, slash command, or `config.toml` preference.
  
  ## Verification
  
  - `CARGO_INCREMENTAL=0 just test -p codex-app-server-protocol`
  - `CARGO_INCREMENTAL=0 just test -p codex-app-server multi_agent_mode`
  
  The focused app-server coverage verifies explicit `thread/start`
  initialization, first-turn prompting, nullable reporting for an omitted
  selection, and retention of selections that are not currently
  runtime-eligible.
  
  ## Stack
  
  Stacked on #28685. This PR contains only the thread initialization and
  lifecycle/settings API layer.

  Shijie Rao · 2026-06-19 10:50:44 +02:00
  7abfcf220b
• Add per-turn multi-agent mode (#28685)

  ## Why
  
  Multi-agent v2 currently carries an explicit-request-only delegation
  rule in its static usage hint. That provides a safe default, but it
  prevents clients from selecting proactive delegation per turn without
  changing static guidance or rewriting prior model context.
  
  This change makes delegation mode a session selection that can be
  updated through `turn/start`, while deriving the effective model-visible
  mode separately for each turn. Eligible multi-agent v2 turns remain
  explicit-request-only unless proactive mode is both selected and
  enabled.
  
  ## What changed
  
  - Add the experimental `turn/start.multiAgentMode` parameter with
  `explicitRequestOnly` and `proactive` values. Omission retains the
  loaded session's current optional selection.
  - Add the default-off `features.multi_agent_mode` feature gate. Eligible
  multi-agent v2 turns use the selected mode when enabled; an unset
  selection or disabled gate resolves to `explicitRequestOnly`.
  - Treat mode prompting as inapplicable for multi-agent v1 and other
  unsupported session configurations, producing no multi-agent mode
  developer message rather than rejecting the turn.
  - Move the explicit-request-only rule out of the static v2 usage hint
  and into a bounded, tagged developer context fragment.
  - Emit the effective mode in initial context and only when that
  effective mode changes on later turns.
  - Persist the effective mode in `TurnContextItem` as the durable
  baseline for resume and context-update comparisons.
  
  Historical rollout items are not rewritten. Later mode developer
  messages establish the current rule incrementally.
  
  ## Not covered
  
  - Initial selection through `thread/start` and selected-mode reporting
  from thread lifecycle/settings APIs; those are isolated in the stacked
  #28792.
  - A TUI control or slash command for selecting the mode.
  - Persisting a preferred mode to `config.toml`; selection remains
  session/turn scoped.
  - Changes to multi-agent concurrency limits, tool availability, or model
  catalog capability declarations.
  - Rewriting historical rollout prompt items. Cold resume restores the
  latest persisted effective mode when available while leaving historical
  developer messages intact.
  
  ## Verification
  
  - `CARGO_INCREMENTAL=0 just test -p codex-core multi_agent_mode`
  - Focused app-server coverage verifies that `turn/start.multiAgentMode`
  produces proactive developer instructions for an eligible v2 turn.
  
  ## Stack
  
  Followed by #28792, which adds `thread/start` initialization and
  lifecycle/settings observability.

  Shijie Rao · 2026-06-18 22:47:51 -07:00
  fc8c6b7384
• [2/3] core: track starting environments in snapshots (#28683)

  ## Why
  
  Remote environments may still be resolving when Codex creates a session
  or turn. Waiting for the existing all-or-nothing environment snapshot
  can hold startup until the selected environment is usable.
  
  Behind the default-off `deferred_executor` feature, let callers take a
  useful snapshot immediately: completed environments remain available
  normally, while unfinished environments are reported without blocking
  startup. With the feature disabled, snapshots preserve the existing
  blocking behavior.
  
  Depends on #28674.
  
  ## What changed
  
  - Store one ordered list of selected environments in
  `ThreadEnvironments`. Each selection owns one shared resolution that
  produces its complete `TurnEnvironment`.
  - Start new resolutions in the background with `remote_handle()`,
  allowing snapshots and the future wait tool to share the same result
  while cancellation follows the retained handles.
  - Make `snapshot()` a read-only operation: nonblocking snapshots collect
  completed resolutions and retain handles for unfinished ones, while
  blocking snapshots await every resolution.
  - Replace completed failed resolutions from the current manager entry
  and log when failed environments are omitted.
  - Return attached and starting environments as a point-in-time view, and
  count starting environments when deciding whether a snapshot is
  local-only.
  - Keep existing consumers attached-only. `to_selections()` derives from
  attached environments, so child threads do not inherit an environment
  that is still starting.
  
  ## Test plan
  
  - `just test -p codex-core environment_selection`
  - `just test -p codex-core
  deferred_executor_reaches_model_before_remote_environment_is_ready`
  
  ## Landing note
  
  Keep `deferred_executor` disabled for slow-starting executors until
  configurable `environment/add` connection timeouts and caller support
  land. When enabled, an environment that attaches after session startup
  may remain absent from environment-derived model context, tools,
  instructions, skills, and related state until follow-up refresh work
  lands.

  sayan-oai · 2026-06-19 05:06:34 +00:00
  45a133bae0
• core: assign item IDs to compacted replacement history (#29012)

  ## Why
  
  Remote v2 compaction can return replacement-history items without IDs.
  Because replacement history is installed directly, those items bypass
  normal history preparation and remain ID-less in later Responses
  requests even when the `item_ids` feature is enabled.
  
  ## What changed
  
  - Pass the active `TurnContext` into `replace_compacted_history`.
  - When `item_ids` is enabled, assign missing IDs before installing and
  persisting replacement history.
  - Rebuild `CompactedItem` from the prepared history so live and
  persisted replacement histories match.
  - Add integration coverage requiring IDs on every ID-capable input item
  in the initial, remote v2 compaction, and post-compaction requests.
  
  ## Test plan
  
  - `just test -p codex-core response_item_ids`
  - `just test -p codex-core websocket_v2_test_codex_shell_chain`
  - `just test -p codex-core remote_compaction_parity_pre_turn_auto`
  - `just test -p codex-app-server
  thread_inject_items_adds_raw_response_items_to_thread_history`

  pakrym-oai · 2026-06-18 18:49:57 -07:00
  70a6aa2634
• [codex] add clock current-time tool (#29011)

  ## Summary
  - expose `clock.curr_time` when current-time reminders are enabled
  - query the session's configured time provider with the calling thread
  id
  - return the existing UTC reminder text for direct model calls
  - return `{ "current_time": "YYYY-MM-DD HH:MM:SS UTC" }` in Code Mode
  
  Clock lookup failures remain fatal, matching pre-inference reminder
  behavior.
  
  ## Testing
  - `just test -p codex-core current_time_tool_returns_the_latest_time`
  - `just test -p codex-core
  code_mode_current_time_returns_structured_result`
  - `just fix -p codex-core`

  rka-oai · 2026-06-19 01:46:57 +00:00
  73251b2f00
• [codex] Assign response item IDs when recording history (#28814)

  ## Why
  
  Client-created response items enter history without IDs, so their
  identity is lost across rollout persistence and resume. IDs should be
  assigned once at the history-recording boundary, while IDs returned by
  the server must remain unchanged.
  
  The Responses API validates item IDs using type-specific prefixes.
  Locally generated IDs therefore use the matching prefix plus a
  hyphenated UUIDv7, keeping them valid while distinguishable from
  server-generated IDs. Because this changes persisted history and
  provider request shapes, the behavior is opt-in behind the
  under-development `item_ids` feature. Compaction triggers remain request
  controls whose API shape does not accept an ID.
  
  ## What changed
  
  - Register the disabled-by-default `item_ids` feature and expose it in
  `config.schema.json`.
  - Make supported optional `ResponseItem` IDs serializable and expose
  them in the generated app-server schemas.
  - When `item_ids` is enabled, assign an ID during conversation-history
  preparation if an item has no ID.
  - Generate type-prefixed, hyphenated UUIDv7 IDs using the Responses API
  item conventions.
  - Preserve existing server IDs without rewriting them.
  - Persist assigned IDs in rollouts and include them in subsequent
  Responses requests.
  - Remove the unsupported ID field from `CompactionTrigger` and document
  why it has no ID.
  - Add integration coverage for enabled ID persistence, preservation of
  server IDs, and omission of generated IDs while the feature is disabled.
  
  `prepare_conversation_items_for_history` is the single response-item ID
  allocation boundary.
  
  ## Test plan
  
  - `just test -p codex-features`
  - `just test -p codex-core
  response_item_ids_persist_across_resume_and_preserve_server_ids`
  - `just test -p codex-core
  non_openai_responses_requests_omit_item_turn_metadata`
  - `just test -p codex-core
  resize_all_images_prepares_failures_before_history_insertion`
  - `just test -p codex-protocol`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-api azure_default_store_attaches_ids_and_headers`

  pakrym-oai · 2026-06-18 17:30:55 -07:00
  f00f93d8c0
• Always use AVAS for realtime WebRTC calls (#28856)

  ## Summary
  
  - Remove the realtime `architecture` selector from core protocol,
  app-server protocol, config parsing, generated schemas, and callers.
  - Always create WebRTC realtime calls with the AVAS query params:
  `intent=quicksilver&architecture=avas`.
  - Keep direct websocket realtime behavior on the existing config/default
  path, while WebRTC starts without an explicit version now default to
  realtime v1 because AVAS requires v1.
  
  ## Notes
  
  - WebRTC realtime now means AVAS. If a caller explicitly asks to start
  WebRTC with realtime v2, Codex rejects that request because the AVAS
  WebRTC path only supports realtime v1. Websocket realtime is separate
  and can still use realtime v2.
  - The old `[realtime] architecture = "realtimeapi" | "avas"` config knob
  is removed. Local configs that still set it will need to delete that
  line.
  - Some app-server tests that were only trying to exercise realtime v2
  protocol behavior now use websocket transport, because WebRTC is
  intentionally locked to AVAS/v1. Separate WebRTC tests cover the AVAS
  query params, v1 startup, SDP flow, and sideband join.
  
  ## Validation
  
  - Merged fresh `origin/main` at `83e6a786a2`.
  - `just fmt`
  - `just write-config-schema`
  - `just write-app-server-schema`
  - `git diff --check`
  - `just test -p codex-api -p codex-core -p codex-app-server-protocol -p
  codex-app-server realtime` (176 passed)
  - `just test -p codex-protocol -p codex-config` (413 passed)

  Peter Bakkum · 2026-06-18 19:11:21 -05:00
  8e7c213f8f
• [plugins] Refresh plugin and tool caches after remote install (#28951)

  Summary
  - Refresh the installed remote-plugin snapshot and Codex Apps tools
  after completing a remote JIT install.
  - Gate `completed: true` on every expected `app_connector_id` appearing
  after the uncached `tools/list` refresh, while continuing to skip local
  bundle verification for server-side installs.
  - Keep the cached recommendations response and filter refreshed
  installed remote IDs locally, so this does not add another
  recommendations fetch.
  - Add regression coverage for tools appearing after the hard refresh and
  remaining absent after the refresh. The resumed model request sees the
  refreshed tool router when installation completes.
  
  Root Cause
  - Remote suggestions from `openai-curated-remote` returned `true` before
  taking the existing connector refresh path, leaving the resumed turn
  with the pre-install Apps tool catalog.
  
  Validation
  - `just test -p codex-core request_plugin_install`
  - `just test -p codex-core-plugins
  recommended_plugin_candidates_filter_installed_and_disabled_plugins`
  - `just test -p codex-core-plugins`
  - `just fix -p codex-core-plugins`
  - `just fix -p codex-core`
  - `just fmt`
  - `just test -p codex-core` was not fully clean locally: 2,729 passed,
  26 failed, and 16 skipped. The failures were dominated by local
  Seatbelt/network/timing issues, including plugin-install timeouts under
  full-suite contention; the focused plugin-install runs pass.

  Alex Daley · 2026-06-18 20:08:04 -04:00
  7e37354a58
• core: add UUIDv7 context window IDs (#28953)

  ## Why
  
  The token-budget context currently identifies a context window by its
  thread-local sequence number. A UUIDv7 gives the model a stable opaque
  identity that remains fixed for a window and rotates when compaction or
  `new_context` starts the next one.
  
  ## What changed
  
  - Preserve the existing monotonic value as `window_number` and add a
  UUIDv7 `window_id` to `CompactedItem`.
  - Generate and rotate the UUID with auto-compaction window state,
  persist it alongside the number, and reconstruct it on resume and
  rollback.
  - Accept legacy compacted rollout records where the numeric `window_id`
  represented the window number.
  - Use the UUID only in token-budget context; existing request headers
  and metadata continue using `thread_id:window_number`.
  
  ## Testing
  
  - `just test -p codex-protocol compacted_item::tests`
  - `just test -p codex-core token_budget`

  pakrym-oai · 2026-06-18 17:00:49 -07:00
  5c12034e42
• core: keep remote exec on reported shell (#28983)

  ## Why
  
  We need to avoid resolving shells on the app-server's host for remote
  environments. We might make it possible to do fancier shell resolution
  from remote envs but for now just require the model to produce a shell
  that matches the environment's default.
  
  This gets my e2e demo working for shell commands after #28854 moved
  shell resolution to PathUri and caused remote envs to hit the fallback
  shell when the shell wasn't available on the host.
  
  ## What
  
  Remote `exec_command` calls now accept only the environment's reported
  default shell name or exact path, and execute with that reported path.
  Other explicit shells return a concise error. A Wine-backed integration
  test covers explicit PowerShell execution in the Windows cwd.

  Adam Perry @ OpenAI · 2026-06-18 23:39:21 +00:00
  346d2c163f
• [codex] Remove child AGENTS.md prompt experiment (#28993)

  ## Why
  
  `child_agents_md` is a disabled, under-development experiment that adds
  a second model-visible explanation of hierarchical `AGENTS.md` behavior.
  Keeping it leaves unused prompt, configuration, documentation, and test
  surface.
  
  ## What changed
  
  - remove the `ChildAgentsMd` feature and `child_agents_md` config schema
  entry
  - remove the hierarchical prompt asset, export, and instruction
  injection
  - remove feature-specific tests and documentation
  - keep the generic unstable-feature warning coverage using
  `apply_patch_streaming_events`
  
  Normal project `AGENTS.md` discovery and composition are unchanged.
  
  ## Testing
  
  - `just test -p codex-features`
  - `just test -p codex-prompts`
  - `just test -p codex-core agents_md`
  - `just test -p codex-core unstable_features_warning`

  pakrym-oai · 2026-06-18 16:13:07 -07:00
  bb72e151e5
• core: load AGENTS.md from foreign environments (#28958)

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

  Adam Perry @ OpenAI · 2026-06-18 15:06:23 -07:00
  dce673905a
• Emit Trusted MCP App Identity on Tool-Call Items (#27132)

  ## Summary
  
  - Add optional `appContext` to app-server MCP tool-call items with
  trusted `connectorId`, `linkId`, and `mcpAppResourceUri` metadata.
  - Preserve that context across tool-call events, persisted history,
  reconnects, and thread resume.
  - Keep the deprecated top-level `mcpAppResourceUri` temporarily for
  client migration.
  
  The consumer contract is `{ appContext: { connectorId, linkId,
  mcpAppResourceUri }, tool }`.
  
  ## Validation
  
  - Full GitHub Actions suite passes, including CLA, Bazel tests, clippy,
  release builds, and argument-comment lint.
  
  ---------
  
  Co-authored-by: martinauyeung-oai <280153141+martinauyeung-oai@users.noreply.github.com>

  martinauyeung-oai · 2026-06-18 14:02:54 -07:00
  765309d5a6