249 Commits

• Pin MCP runtimes to model steps (#30101)

  ## Why
  
  An MCP refresh can replace the session's current manager while a model
  step is still running. The step must execute calls through the same
  manager whose tools it advertised.
  
  ## Boundary
  
  ```text
  current session MCP runtime
            |
            | capture once for this model step
            v
  StepContext.mcp
    - exact MCP config
    - exact connection manager
    - exact runtime environment context
  ```
  
  ```rust
  pub struct McpRuntimeSnapshot {
      config: Arc<McpConfig>,
      manager: Arc<McpConnectionManager>,
      runtime_context: McpRuntimeContext,
  }
  ```
  
  ## Example
  
  ```text
  step A captures runtime A and advertises A's tools
  refresh publishes runtime B
  step A tool call -> runtime A
  next step        -> runtime B
  ```
  
  Capturing the snapshot is only an `Arc` clone. It does not restart MCPs
  or make an RPC.
  
  ## What changes
  
  - Captures one MCP runtime in `StepContext`.
  - Uses it for tool planning, tool calls, resources, approvals, connector
  attribution, and elicitation.
  - Publishes replacement runtimes atomically.
  - Lets an old runtime live only while an in-flight step or request still
  holds its `Arc`.
  
  Most of this diff is mechanical routing from the session-global manager
  to `step_context.mcp`; it does not introduce selected-plugin discovery
  yet.
  
  ## What does not change
  
  - No plugin or extension migration.
  - No new MCP cache policy.
  - No environment file watching.
  - No client sharing between separate managers.
  
  ## Stack
  
  1. Extension-owned World State sections.
  2. Project executor skills through World State.
  3. **This PR:** 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-26 00:53:07 +01:00
  ee9e0f6387
• Persist selected capability roots and resolve availability per model step (#29856)

  ## Why
  
  `selectedCapabilityRoots` is durable thread intent: “use this capability
  root from environment `worker`.”
  
  The important product assumption is:
  
  > One environment ID always names the same logical executor and stable
  contents.
  
  `worker` does not silently change from executor A to an unrelated
  executor B. The process-local connection handle for `worker` can still
  be replaced while Codex is running, though, for example when
  `environment/add` registers a fresh handle for the same logical
  environment.
  
  The thread should persist only the stable selection. Each model step
  should pair that selection with the exact ready handle captured for that
  step.
  
  ## The boundary
  
  ```text
  persisted thread intent
    plugin@1 -> environment "worker"
                  |
                  | capture the current step
                  v
  model-step view
    unavailable, or
    plugin@1 + worker's exact captured ready handle
  ```
  
  The environment ID is the stable identity and cache key. The
  `Arc<Environment>` is only a process-local handle retained so consumers
  of one model step use the same captured environment. It is never
  persisted and it does not imply different environment contents.
  
  ## What changes
  
  ### Persist the stable selection
  
  Selected roots are written into `SessionMeta` and restored with the
  thread. Forked subagents inherit the same selections, including
  bounded-history forks.
  
  Only stable data is persisted: root ID, environment ID, and root path.
  
  ### Capture readiness together with the exact handle
  
  The environment snapshot records:
  
  ```rust
  environment_id -> Some(Arc<Environment>) // ready in this step
  environment_id -> None                   // still starting in this step
  ```
  
  This prevents readiness and execution from coming from different
  registry snapshots.
  
  For example:
  
  ```text
  step snapshot: worker -> handle A, ready
  environment/add: worker -> fresh handle B for the same logical environment
  current step: plugin@1 still uses captured handle A
  ```
  
  Without carrying handle A in the snapshot, the resolver could combine “A
  was ready” with handle B and treat B as ready before it had finished
  starting.
  
  This does not change cache invalidation. Stable capability metadata
  remains identified by environment ID and capability root. Replacing a
  process-local handle under the same stable environment ID does not
  invalidate or rediscover that metadata.
  
  ### Resolve availability per model step
  
  - A ready captured environment produces resolved roots using its
  captured handle.
  - A starting, missing, or failed environment is omitted from that step.
  - A selected lazy environment that is outside the turn's captured
  environment set is asked to start, and a later step can observe it as
  ready.
  - No capability files are scanned here.
  
  Transient transport disconnects remain the remote client's reconnect
  concern. This PR models initial attachment/readiness; it does not add
  live socket-connectivity state.
  
  ## Example
  
  ```text
  thread selection: plugin@1 -> environment "worker"
  
  step 1: worker is starting -> plugin@1 unavailable
  step 2: worker is ready    -> plugin@1 resolves through worker's captured handle
  step 3: fresh local handle -> current step remains pinned; a later step captures its own view
  ```
  
  Temporary unavailability does not discard the durable selection. Later
  PRs can retain stable metadata caches while projecting only currently
  available capabilities into model-visible World State.
  
  ## Compatibility
  
  The app-server request shape does not change. Older rollouts without
  `selected_capability_roots` deserialize to an empty list.
  
  ## Stack
  
  1. **This PR:** persist stable selected roots and resolve them through
  an exact model-step handle.
  2. #29960: cache stable skill metadata and project available skills into
  World State.
  3. #29946: cache stable plugin declarations and manage the separate live
  MCP runtime.

  jif · 2026-06-25 17:49:43 +00:00
  8f02973d25
• core: make AGENTS.md react to environment changes (#29810)

  ## Why
  
  With deferred executors, a turn can begin before a remote environment
  attaches. AGENTS.md discovery previously ran only during session setup,
  so instructions from a later environment never reached the model or the
  session instruction sources.
  
  WorldState persistence has now landed, so this uses the durable
  model-visible baseline directly instead of carrying a temporary
  resume/fork compatibility path.
  
  ## What
  
  - Add an `AgentsMdManager` in `SessionServices` to own host
  instructions, loaded state, and refresh caching.
  - When `DeferredExecutor` is enabled, refresh AGENTS.md when attached
  environment selections change and freeze the result in the corresponding
  `StepContext`.
  - Represent AGENTS.md as a persisted WorldState section for every
  session, with bounded initial, replacement, and removal updates.
  - Remove duplicate AGENTS.md state and rendering from
  `SessionConfiguration` and `TurnContext`.
  - Build initial context, per-request updates, and compaction context
  from the same step-scoped value.
  - On resume and fork, compare current instructions with the restored
  WorldState baseline and inject a replacement exactly once when they
  differ.
  
  Builds on #29833, #29835, and #29837.
  
  ## Tests
  
  - Covers a remote environment becoming ready mid-turn, with AGENTS.md
  appearing on the next request exactly once and updating canonical
  instruction sources.
  - Covers full, unchanged, replaced, and removed AGENTS.md WorldState
  rendering.
  - Covers changed instructions across cold resume and fork without
  duplicate reinjection.
  - Covers remote-v2 compaction retaining creation-time instructions in
  the live session and cold resume appending one replacement when the
  source changed.
  - Ran focused `codex-core` AGENTS.md, WorldState, and context-update
  test suites.

  sayan-oai · 2026-06-24 22:57:42 -07:00
  f2f80ef442
• feat: use run agent task auth for inference (#19051)

  ## Stack
  
  This is PR 3 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 moves Agent Identity usage into provider auth resolution. That
  keeps `AgentAssertion` auth tied to first-party OpenAI provider requests
  instead of applying a late session-wide override that could affect
  local, custom, Bedrock, API-key, or external-bearer providers.
  
  What changed:
  
  - adds a small `ProviderAuthScope` struct carrying the run auth policy
  and session source needed by provider-scoped auth resolution
  - lets `Session` opt the existing `ModelClient` into `ChatGptAuth`
  policy when `use_agent_identity` is enabled, without adding a second
  model-client constructor
  - resolves Agent Identity only for first-party OpenAI provider auth
  paths
  - uses the persisted run task id from the `AgentIdentityAuth` record to
  build `AgentAssertion` auth for Responses requests
  - routes shared request setup through scoped provider auth so unary
  compact requests use the same run-task assertion path as inference turns
  - keeps local/custom/Bedrock/env-key/external-bearer provider auth
  unchanged
  - lets missing run-task state surface through the existing model-request
  error path instead of silently falling back to bearer auth
  
  This PR intentionally does not create thread-scoped, target-scoped, or
  background-scoped task identities. The run task is the only task Codex
  registers in this POC shape.
  
  ## Testing
  
  - `just test -p codex-model-provider`
  - `just test -p codex-core client::tests::provider_auth_scope_uses`
  - `just test -p codex-core remote_compact_uses_agent_identity_assertion`

  Adrian · 2026-06-24 22:31:41 -07:00
  51864b0b4b
• [codex] Add Ultra reasoning effort (#29899)

  ## Why
  
  Ultra should be one user-facing reasoning selection for work that
  benefits from both maximum reasoning and proactive multi-agent
  delegation. Without it, clients must coordinate maximum reasoning with
  the experimental `multiAgentMode` setting, even though the inference
  backend still expects its existing `max` effort value.
  
  This change makes reasoning effort the source of truth: clients select
  `ultra`, core derives proactive multi-agent behavior when the turn is
  eligible for multi-agent V2, and inference requests continue to use the
  backend-compatible `max` value.
  
  ## What changed
  
  - Add `ultra` as a first-class reasoning effort and preserve
  model-catalog ordering when exposing it to clients.
  - Convert `ultra` to `max` at the inference request boundary, including
  Responses HTTP/WebSocket requests, startup prewarm, compaction, and
  memory summarization.
  - Derive effective multi-agent mode per turn from effective reasoning
  effort:
    - eligible multi-agent V2 + `ultra` → `proactive`
    - eligible multi-agent V2 + any other effort → `explicitRequestOnly`
  - V1 or otherwise ineligible sessions → no multi-agent mode instruction
  - Keep the derived effective mode in turn context history so successive
  turns can emit a developer-message update only when the effective mode
  changes.
  - Remove selected multi-agent mode from core session configuration, turn
  construction, thread settings, resume/fork restoration, and subagent
  spawn plumbing. Subagents inherit reasoning effort and derive their own
  effective mode.
  - Retain the experimental app-server `multiAgentMode` fields for wire
  compatibility while marking them deprecated. Request values are accepted
  but ignored; compatibility response fields report `explicitRequestOnly`.
  - Display Ultra in the TUI using the order supplied by `model/list`.
  
  ## Validation
  
  - `just test -p codex-core ultra_reasoning_uses_max_for_requests`
  - `just test -p codex-tui model_reasoning_selection_popup`

  Shijie Rao · 2026-06-24 20:13:52 -07:00
  df1199fddb
• [2/3] core: persist world state in rollouts (#29835)

  ## Why
  
  `WorldState` currently remembers its model-visible diff baseline only in
  memory. That leaves no durable source for restoring the exact baseline
  after resume, fork, rollback, or compaction.
  
  This is the second PR in the WorldState persistence stack, built on
  #29833 and following #29249. It records durable state transitions; the
  next PR will replay them during rollout reconstruction.
  
  ## What
  
  - Add a `world_state` rollout item containing either a full snapshot or
  an RFC 7386 JSON Merge Patch.
  - Persist a full snapshot after initial context and after compaction
  establishes a new context window.
  - Persist non-empty patches when later sampling steps or turns advance
  the WorldState baseline.
  - Write model-visible history before its matching WorldState record, so
  an interrupted write can only cause a safe repeated update on replay.
  - Preserve WorldState records for full-history forks while excluding
  them from thread previews, metadata, and app-server history
  materialization.
  
  Older binaries read rollout lines independently, so they skip the
  unknown `world_state` records while retaining the rest of the thread.
  
  ## Testing
  
  - `just test -p codex-core
  snapshot_merge_patch_changes_and_removes_nested_values`
  - `just test -p codex-core
  world_state_baseline_deduplicates_until_history_is_replaced`
  - `just test -p codex-core
  deferred_executor_compaction_preserves_then_updates_environment_once`
  - `just test -p codex-protocol`
  - `just test -p codex-rollout`
  - `just test -p codex-state`
  - `just test -p codex-thread-store`
  - `just test -p codex-app-server-protocol`

  sayan-oai · 2026-06-24 20:13:49 -07:00
  fa036d39aa
• [1/3] core: make world state snapshots serializable (#29833)

  ## Why
  
  `WorldState` currently keeps its diff baseline as live Rust objects
  keyed by process-local `TypeId`. That baseline cannot be written to a
  rollout or restored after resume, so Codex reconstructs an approximation
  from `TurnContextItem`.
  
  This is the first change in the WorldState persistence stack. It gives
  every section a stable persisted identity and a compact serializable
  comparison snapshot without changing rollout behavior yet.
  
  ## What changed
  
  - Require each `WorldStateSection` to define a stable ID and
  serializable snapshot type.
  - Reject duplicate section IDs when constructing `WorldState`.
  - Persist a dedicated environment comparison snapshot using
  model-visible strings instead of runtime path types.
  - Store only `WorldStateSnapshot` in `ContextManager`, removing the
  parallel live-object baseline.
  - Render diffs by restoring each section's typed snapshot; invalid
  snapshots fall back to a full section render.
  - Omit null object fields for future RFC 7386 patches while preserving
  null values inside arrays.
  
  Follow-up PRs will record full snapshots and merge patches, then restore
  the baseline during resume, fork, and rollback.
  
  ## Test plan
  
  - WorldState snapshot tests cover stable IDs, duplicate rejection, null
  omission, and array preservation.
  - Environment tests cover persistence-safe snapshot values and existing
  diff rendering.
  - ContextManager baseline deduplication and session context-update
  persistence tests.
  
  Related: #29249

  sayan-oai · 2026-06-24 19:26:55 -07:00
  3e51b46eba
• 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
• [apps] Thread structured icon assets through app list (#29889)

  ## Summary
  
  - Add `iconAssets` and `iconDarkAssets` to the app-list protocol.
  - Preserve structured icons through directory merging and the connector,
  app-
    server, and TUI boundaries.
  - Keep legacy logo URLs unchanged as compatibility fallbacks.
  - Update generated protocol schemas and TypeScript types.

  Drew · 2026-06-24 13:25:44 -07:00
  a33ad93996
• Persist agent messages as response items (#29829)

  ## Why
  
  Inter-agent messages are recorded in live history as
  `ResponseItem::AgentMessage`, but rollouts stored
  `InterAgentCommunication` and rebuilt the response item during resume.
  This made the rollout differ from the actual Responses history.
  
  ## What changed
  
  - store the prepared `agent_message` response item directly
  - keep `trigger_turn` in a small local metadata record for fork
  truncation
  - keep reading older `inter_agent_communication` rollout items

  jif · 2026-06-24 15:43:10 +01:00
  b4f0f3eff1
• 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
• [codex] Assign response item IDs in forked history (#29767)

  ## Why
  
  Fork-specific response items, including the subagent usage hint, are
  appended directly to `InitialHistory::Forked`. This bypasses the normal
  history insertion path that assigns missing response item IDs when
  `Feature::ItemIds` is enabled, so the child could reconstruct and
  persist those items without IDs.
  
  ## What changed
  
  - When `Feature::ItemIds` is enabled, assign missing IDs to top-level
  `ResponseItem`s while materializing `InitialHistory::Forked`, before
  both reconstruction and persistence.
  - Preserve existing IDs and use the same owned rollout items for live
  history and persistence.
  - Extract the existing single-item ID allocation logic for reuse by the
  fork path.
  - Add coverage that verifies a fork-only developer message receives the
  same ID in live and persisted history with the feature enabled.
  
  Normal history recording, compacted-history replacement, and fork
  handling all continue to honor `Feature::ItemIds`. External-agent
  imports, normal resume, and nested legacy compaction checkpoints are
  unchanged.
  
  ## Testing
  
  - `just test -p codex-core
  record_initial_history_reconstructs_forked_transcript`
  - `just test -p codex-core
  record_initial_history_assigns_and_persists_id_for_forked_response_item`

  pakrym-oai · 2026-06-24 03:03:19 +00:00
  806a4b66c9
• [codex] Reuse compacted history replacement for new context windows (#29762)

  ## Why
  
  `start_new_context_window` independently replaced in-memory history and
  persisted a compacted checkpoint instead of using the shared
  compacted-history path. That bypassed the centralized missing-item-ID
  assignment when `item_ids` is enabled, so fresh context messages could
  enter the new context window and its persisted replacement history
  without IDs.
  
  This follows up on the token-budget compaction reset flow introduced in
  [#29743](https://github.com/openai/codex/pull/29743).
  
  ## What changed
  
  - Delegate new context-window installation to
  `replace_compacted_history`.
  - Reuse its ID assignment, in-memory replacement, world-state baseline,
  checkpoint persistence, turn-context persistence, and session-start
  bookkeeping.
  - Add focused coverage that verifies generated IDs are present in live
  history and preserved in the persisted replacement history.
  
  ## Testing
  
  - `just test -p codex-core
  start_new_context_window_assigns_and_persists_item_ids`
  - `just test -p codex-core
  new_context_tool_starts_new_window_before_follow_up`

  pakrym-oai · 2026-06-23 18:53:35 -07:00
  176af2b510
• chore: assign amsg_ IDs to agent messages (#29750)

  ## Why
  
  The `ItemIds` path fills in missing IDs before response items are
  persisted and emitted as raw item events. `ResponseItem::AgentMessage`
  is part of that same response-item stream, but it was skipped by the
  missing-ID repair path, leaving agent messages without stable item IDs
  while messages and tool items received generated IDs.
  
  Agent messages recorded through `InterAgentCommunication` also need the
  generated ID to survive rollout persistence and resume. Otherwise
  clients can observe an `amsg_` ID for the live raw response item, then
  see that same persisted agent message lose its item ID after restart.
  
  ## What changed
  
  - Assign missing `ResponseItem::AgentMessage` IDs with the `amsg_`
  prefix.
  - Persist the generated item ID on `InterAgentCommunication` and replay
  it back into the reconstructed `ResponseItem::AgentMessage` on resume.
  - Keep the persisted ID out of the model-visible inter-agent message
  envelope.
  - Keep `CompactionTrigger` and `Other` skipped because they do not get
  generated item IDs.
  - Update session/protocol tests for agent-message ID assignment and
  resume preservation.
  
  ## Manual Testing
  
  Run the local dev build using `just c --enable item_ids` to ensure this
  code is exercised:
  
  
  https://github.com/openai/codex/blob/322e33512b2d38d38d705e2ef692a8aca50decac/codex-rs/core/src/session/mod.rs#L2713-L2715
  
  In the `.jsonl` file, I saw entries like:
  
  ```json
  {
    "timestamp": "2026-06-24T00:44:03.098Z",
    "type": "inter_agent_communication",
    "payload": {
      "id": "amsg_019ef715-849a-7a50-becc-ce63c6a9c994",
  ```
  
  ## Test plan
  
  - `just test -p codex-core
  record_inter_agent_communication_preserves_item_id_in_rollout_and_resume`
  - `just test -p codex-core
  record_inter_agent_communication_sets_turn_id_in_rollout_and_resume`
  - `just test -p codex-protocol
  inter_agent_communication_response_input_item_preserves_commentary_phase`

  Michael Bolin · 2026-06-23 17:57:03 -07:00
  97dce078c5
• 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
• core: persist initial context window metadata (#29519)

  ## Why
  
  PR #29494 made context-window IDs visible to the model by wrapping the
  token-budget window payload in `<context_window>`, but rollout JSONL
  consumers still could not see the initial window identity by tailing the
  session file. Compacted rollout items carry window IDs only after
  compaction has happened, so a session with no compaction had no durable
  JSONL record for window 0.
  
  This change gives tailing consumers a stable initial-window record at
  session creation time.
  
  ## What Changed
  
  - Added `session_meta.context_window.window_id` for the initial
  context-window identity.
  - `CreateThreadParams` now requires `initial_window_id: String`, so
  thread-store callers cannot accidentally create new threads without
  window-0 metadata.
  - Live thread creation derives the persisted initial window ID from the
  same `AutoCompactWindowIds` used to initialize `SessionState`, keeping
  runtime state and JSONL metadata aligned.
  - Rollout reconstruction uses `session_meta.context_window.window_id` as
  the initial-window fallback and derives `window_number = 0`,
  `first_window_id = window_id`, and `previous_window_id = None`
  internally.
  - Fork reconstruction intentionally uses the same rollout reconstruction
  path; consumers that need to distinguish copied initial-window metadata
  can use the rollout `thread_id`.
  - Legacy compactions without `window_number` still use compaction-count
  fallback accounting instead of being reset to window 0 by the
  initial-window fallback.
  - Compacted rollout metadata still takes precedence once compaction
  records exist, preserving the richer chain fields there.
  
  ## JSONL Shape
  
  Real rollout JSONL is one object per line. This example is expanded for
  readability, but shows the new initial `session_meta.context_window`
  record followed by the existing compacted rollout item shape that also
  carries window IDs:
  
  ```jsonl
  {
    "timestamp": "2026-06-22T12:00:00.000Z",
    "type": "session_meta",
    "payload": {
      "session_id": "<THREAD_ID>",
      "id": "<THREAD_ID>",
      "timestamp": "2026-06-22T12:00:00.000Z",
      "cwd": "/repo",
      "originator": "codex",
      "cli_version": "0.0.0",
      "source": "cli",
      "model_provider": "<MODEL_PROVIDER>",
      "context_window": {
        "window_id": "<INITIAL_WINDOW_ID>"
      }
    }
  }
  ...
  {
    "timestamp": "2026-06-22T12:34:56.000Z",
    "type": "compacted",
    "payload": {
      "message": "<COMPACTION_SUMMARY>",
      "replacement_history": [
        "..."
      ],
      "window_number": 1,
      "first_window_id": "<INITIAL_WINDOW_ID>",
      "previous_window_id": "<INITIAL_WINDOW_ID>",
      "window_id": "<NEXT_WINDOW_ID>"
    }
  }
  ```
  
  The nested `context_window` object is intentional: it gives rollout
  consumers a stable namespace for context-window metadata while only
  writing the non-derivable initial `window_id`. For the initial window,
  `window_number`, `first_window_id`, and `previous_window_id` are derived
  internally instead of being written to the rollout.
  
  ## Verification
  
  - `just test -p codex-protocol`
  - `just test -p codex-rollout
  recorder_materializes_on_flush_with_pending_items`
  - `just test -p codex-core reconstruct_history`
  - `just test -p codex-core
  record_initial_history_reconstructs_forked_transcript`
  - `just test -p codex-thread-store`
  - `just test -p codex-state`
  - `just test -p codex-app-server
  thread_read_returns_summary_without_turns`
  - `just test -p codex-rollout persistence_metrics`

  Michael Bolin · 2026-06-23 21:50:50 +00:00
  01f89c8c59
• core: use current step environments for tools (#29547)

  ## Why
  
  With deferred executors, an environment can become ready between two
  sampling requests in the same turn. The model-visible environment
  update, advertised tools, and eventual tool execution must all describe
  the same request-time view.
  
  Otherwise, a request built while only environment B is ready can
  advertise a tool without an `environment_id`; if higher-priority
  environment A becomes ready before execution, that call could silently
  run in A instead.
  
  This PR is stacked on #29527.
  
  ## Design
  
  `run_turn` captures one `Arc<StepContext>` at each sampling-request
  boundary. That step owns the request's `TurnContext` and environment
  snapshot.
  
  - World-state environment updates and tool planning borrow that same
  step.
  - `ToolCallRuntime` retains the `Arc` while asynchronous tool calls
  execute.
  - `ToolInvocation` carries the step to handlers; its temporary `turn`
  compatibility field is derived from the same object.
  - `ToolRouter` does not retain `StepContext`; it only uses it while
  constructing the request's tool set.
  - With `DeferredExecutor` disabled, step capture keeps using the
  environments frozen at turn start.
  
  Simply: every sampling request gets one consistent picture of its
  environments, from what the model sees through where its tool calls run.
  
  ## What changed
  
  - Build environment-dependent tool specs from the current request's
  `StepContext`.
  - Use that same step for unified exec, legacy shell, `apply_patch`,
  `view_image`, and `request_permissions` execution.
  - Hide environment-backed tools, including `request_permissions`, while
  no environment is attached.
  - Resolve legacy shell paths and metadata from the selected step
  environment instead of the stale turn-start environment.
  - Capture explicit steps at non-turn-loop boundaries such as compaction,
  prompt debug, and startup prewarm.
  - Reconcile prompt-debug history from the same step used to build its
  tools.
  
  ## Follow-up
  
  - Bind yielded code-mode cells to the tool runtime that created them, so
  nested calls made after yielding continue to use the originating
  request's `StepContext`.
  
  ## Test plan
  
  - `just test -p codex-core
  deferred_executor_updates_context_and_tools_after_startup`
  - `just test -p codex-core
  environment_count_controls_environment_backed_tools`
  - `just test -p codex-core
  build_prompt_input_includes_context_and_user_message`

  sayan-oai · 2026-06-23 20:21:13 +00:00
  4cc6a4bab5
• 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
• 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
• [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
• 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
• [codex] migrate environment context to model world state (#29249)

  ## Why
  
  Environment context is model-visible state, but it is currently
  assembled from transient turn values and diffed through
  environment-specific paths. That makes initial injection, turn-to-turn
  updates, and changes that happen within a turn use different baselines.
  
  This PR introduces the smallest useful model world-state slice:
  environments only, with one in-memory baseline and one renderer for full
  state and diffs.
  
  ## What changed
  
  - Add a typed `WorldState` container whose sections render fragments
  relative to an optional previous value. Full rendering uses the same
  diff path with no previous state.
  - Replace the parallel `EnvironmentContext` representation with an
  `EnvironmentsState` section keyed by environment ID and rendered in
  deterministic order.
  - Preserve the legacy single-environment output while supporting
  multiple environments, starting environments, unavailable tombstones,
  and changes to persisted turn-context values.
  - Store the latest complete `WorldState` on `ContextManager` and use it
  for both turn-boundary and mid-turn environment diffs.
  - Build initial and post-compaction context from the same world-state
  builder, then retain the rendered state as the next baseline.
  - Seed the in-memory baseline from the latest `TurnContextItem` when
  resuming an existing rollout; the world state itself is not serialized.
  - Keep non-world settings updates on their existing path and merge
  rendered world-state fragments at the session consumer.
  
  ## Known limitation
  
  A legacy `TurnContextItem` only reconstructs the primary environment as
  `local`; it cannot faithfully recover a remote-primary environment ID
  after resume. Live state uses the exact environment IDs once a complete
  baseline is established.
  
  ## Test plan
  
  - `just test -p codex-core world_state`
  - `just test -p codex-core record_context_updates`
  - `just test -p codex-core deferred_executor_`
  - `just test -p codex-core build_initial_context`
  - `just test -p codex-core rollout_reconstruction`
  - `just test -p codex-core
  process_compacted_history_reinjects_full_initial_context`

  pakrym-oai · 2026-06-22 16:07:27 -07:00
  3b32d861c5
• 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
• 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
• 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
• 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
• [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
• 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] 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
• 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
• [codex] Reuse parsed plugin skills during session startup (#28844)

  ## Summary
  
  - Preserve raw plugin skill-root snapshots in the matching loaded-plugin
  cache entry, keyed by the effective plugin root identity including
  namespace.
  - Pass those snapshots through `SkillsLoadInput` as an optional preload,
  so session startup reuses plugin parsing while ordinary skill loads pass
  `None`.
  - Keep plugin skill loading cohesive: the existing loaders accept the
  optional snapshots directly, and uncached or marketplace-detail paths do
  not create a cache.
  
  ## Why
  
  Plugin discovery already parses plugin skills to determine available
  capabilities. Cold session startup then scanned and parsed the same
  roots again while building the skills snapshot.
  
  This solves the same duplicate-work problem as #28623 while keeping
  ownership narrow: `PluginsManager` creates and owns
  `PluginSkillSnapshots` only for its loaded-plugin cache entry;
  `SkillsService` consumes an optional clone. Entry replacement or
  clearing naturally drops the snapshots, with no separate generation,
  capacity policy, or watcher coupling.
  
  ## Validation
  
  - `cargo clippy -p codex-core-skills --all-targets -- -D warnings`
  - `just test -p codex-core-plugins
  skills_service_reuses_skills_parsed_during_plugin_load`
  - `just test -p codex-core-skills
  namespaces_plugin_skills_using_provided_namespace`
  - `just fmt`

  xl-openai · 2026-06-18 16:45:58 -07:00
  e83b7841b0
• current time reminders impl for system clock (varlatency 2/n) (#28824)

  Stacked on #28822.
  
  ## Summary
  
  - add a host-injectable current-time provider with a built-in system
  implementation
  - record UTC developer reminders in history immediately before due model
  requests
  - keep cadence state per session and force a refresh after compaction
  
  This does NOT include the app server client <-> server clock logic. This
  PR is only for the reminder message & system clock that will be used in
  prod.
  
  ## Testing
  
  - `just test -p codex-core varlatency_`
  - `just clippy -p codex-core -p codex-app-server -p codex-mcp-server -p
  codex-thread-manager-sample`
  - `just fmt`

  rka-oai · 2026-06-18 19:18:42 +00:00
  752ed90d78
• Support openai/form extended form elicitations (#27500)

  # Summary
  Allow App Server clients to opt into `openai/form` MCP elicitations.

  Gabriel Peal · 2026-06-18 11:54:49 -07:00
  21a599fa56
• Add turn-scoped context contributions (#28911)

  ## Summary
  - keep context injection on a single ContextContributor trait
  - split context injection into thread-scoped and turn-scoped
  contribution methods
  - wire turn-scoped fragments into initial context assembly so extensions
  can contribute context from turn-local state

  jif · 2026-06-18 19:40:28 +02:00
  9684ec25be
• [codex] Add optional IDs to response items (#28812)

  ## Why
  
  `ResponseItem` variants do not have a consistent internal ID shape: some
  variants carry required IDs, some carry optional IDs, and some cannot
  represent an ID at all. The existing fields also use inconsistent serde,
  TypeScript, and JSON-schema annotations. A single enum-level access path
  is needed before history recording can assign and retain IDs.
  
  This PR establishes that internal model only. It intentionally does not
  generate or serialize IDs; allocation and wire persistence are isolated
  in the stacked follow-up.
  
  ## What changed
  
  - Give every concrete `ResponseItem` variant an `Option<String>` ID
  field.
  - Apply the same internal-only annotations to every ID field:
  `#[serde(default, skip_serializing)]`, `#[ts(skip)]`, and
  `#[schemars(skip)]`.
  - Add `ResponseItem::id()` and `ResponseItem::set_id()` as the shared
  accessors.
  - Preserve IDs when history items are rewritten for truncation.
  - Adapt consumers that previously assumed reasoning and image-generation
  IDs were required.
  - Regenerate app-server schemas so the hidden fields are represented
  consistently.
  
  The serde catch-all `ResponseItem::Other` remains ID-less because it
  must remain a unit variant.
  
  ## Test plan
  
  - `cargo check --tests -p codex-core -p codex-api -p codex-rollout-trace
  -p codex-image-generation-extension`
  - `just test -p codex-protocol`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-api -p codex-rollout-trace -p
  codex-image-generation-extension`
  - `just test -p codex-core event_mapping`

  pakrym-oai · 2026-06-17 18:27:43 -07:00
  dbd2857f4b
• Replace SkillsManager with SkillsService (#28705)

  ## Why
  
  Host skill discovery was still exposed as a manager even though it is a
  process-owned service shared by sessions, the app-server catalog, and
  file-watcher invalidation. The skills extension also consumed an ad hoc
  loaded-skills wrapper instead of a named immutable snapshot.
  
  ## What changed
  
  - replace `SkillsManager` with concrete `SkillsService`
  - make the service cache and return immutable `HostSkillsSnapshot`
  values
  - migrate the skills extension host provider to the snapshot boundary
  - migrate app-server catalog, watcher, and invalidation paths to the
  service
  
  This keeps the service limited to host discovery, caching, roots, and
  invalidation. Catalog rendering and invocation remain extension
  responsibilities for the next stacked change.

  jif · 2026-06-17 17:01:06 +02:00
  0318381762
• Add join key for MAv2 inter-agent messages (#28561)

  ## Summary
  This keeps inter-agent communication on the existing raw response item
  path and adds a join key for MAv2 tool calls.
  
  MAv2 `spawn_agent`, `send_message`, and `followup_task` now stamp the
  originating tool call id into `ResponseItemMetadata.source_call_id` on
  the raw `ResponseItem::AgentMessage`. App-server clients can join that
  raw item back to the existing tool/activity event by call id, while
  using the raw agent message's existing sender, receiver, and content
  fields.
  
  No new app-server `ThreadItem` or notification type is added.
  
  ## Tests
  - `just fmt`
  - `just write-app-server-schema`
  - `just test -p codex-protocol`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-core
  multi_agent_v2_spawn_returns_path_and_send_message_accepts_relative_path`
  - `just test -p codex-core
  multi_agent_v2_followup_task_completion_notifies_parent_on_every_turn`
  - `just fix -p codex-protocol`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-core`

  jif · 2026-06-17 14:48:56 +02:00
  45f603302c
• core: remove redundant TurnContext and Prompt fields (#28638)

  ## Why
  
  `TurnContext` had accumulated dead fields and cached projections of
  values already owned by its per-turn `Config` or `ModelInfo`. Keeping
  both copies made ownership unclear and allowed artificial split-brain
  states, such as a compatibility hash differing from the model metadata
  it came from.
  
  `Prompt` similarly carried a write-only personality after personality
  selection had already been materialized into its base instructions.
  
  This makes the canonical owner explicit: configuration-backed values
  come from `config`, model-derived values come from `model_info`, and
  prompts contain only data consumed by request construction.
  
  ## What changed
  
  - Remove the unused `ghost_snapshot`, `codex_self_exe`, and
  `thread_source` fields.
  - Remove duplicate `comp_hash`, `truncation_policy`, `features`,
  `shell_environment_policy`, `codex_linux_sandbox_exe`, `compact_prompt`,
  and `tool_mode` fields.
  - Read those values directly from `TurnContext::config` or
  `TurnContext::model_info` at their consumers.
  - Remove the write-only `Prompt::personality` field and its constructor
  assignments.
  - Preserve review-turn inheritance of the parent turn's shell policy,
  Linux sandbox executable, and compact prompt through the review config.
  
  ## Testing
  
  - `cargo check -p codex-core --tests`

  pakrym-oai · 2026-06-16 22:17:24 -07:00
  172b2218a5
• [codex] core: restore absolute turn context cwd (#28629)

  ## Why
  
  #28152 jumped the gun on moving the rollout format to store URIs, and
  would likely break compat with some features that don't go through the
  same types as the core logic.
  
  ## What
  
  Make `TurnContextItem.cwd` an `AbsolutePathBuf` again, remove test added
  for `PathUri` serialization in rollouts. Also drops a bunch of error
  paths that are no longer needed.

  Adam Perry @ OpenAI · 2026-06-16 19:05:26 -07:00
  3d02c443bc
• core: render remote environment cwd natively (#28152)

  ## Why
  
  Model-visible `<environment_context>` should match the environment of
  the executor, not of the app server.
  
  Stacked on #28146.
  
  ## What
  
  - Keep selected environment cwd values as `PathUri` while building
  environment context.
  - Render cwd text using the path convention represented by the URI, with
  the canonical URI as a fallback.
  - Preserve compatibility with legacy `TurnContextItem.cwd` values when
  reconstructing and diffing context.
  - Extend the Wine-backed remote Windows test to assert that the model
  sees `powershell` and `C:\windows`.

  Adam Perry @ OpenAI · 2026-06-16 16:17:47 -07:00
  4c79527e31
• [codex] [2/4] Generalize plugin suggestion presentation (#28400)

  Summary
  - Add list-backed and developer-context presentations for plugin
  suggestion candidates.
  - Let tool planning, install validation, and request-tool copy follow
  the selected presentation.
  - Keep every production caller on the existing list-backed presentation,
  preserving the current list tool, request schema, connector behavior,
  and model-visible copy.
  - Leave developer-context presentation latent until the final PR in the
  stack.
  
  Stack
  - 2/3, based on #28399.
  - Follow-up: #27704 activates endpoint recommendations.
  
  Validation
  - `just test -p codex-core request_plugin_install`
  - `just test -p codex-core spec_plan`
  - `just fix -p codex-core`
  - `just fmt`
  - `git diff --check`

  Alex Daley · 2026-06-16 22:44:10 +00:00
  587487df9e
• app-server: preserve target-native environment cwd (#28146)

  ## Why
  
  app-server may run on a different OS from the selected exec-server
  environment. Parsing that environment’s cwd with the Codex host’s path
  rules prevents thread startup.
  
  ## What
  
  Carry environment cwd values as `LegacyAppPathString` at the app-server
  boundary and `PathUri` internally. Existing tool-call schemas and
  relative-path behavior stay host-native; remaining local-only consumers
  convert explicitly and leave follow-up TODOs.
  
  The Wine integration test verifies app-server can start a thread and
  complete an ordinary turn with a Windows environment cwd from Linux.
  
  ## Validation
  
  - `bazel test //codex-rs/core/tests/remote_env_windows:smoke-test
  --test_output=errors`
  - focused app-server environment-selection and protocol schema tests
  - scoped Clippy for `codex-core` and `codex-app-server-protocol`

  Adam Perry @ OpenAI · 2026-06-16 21:42:28 +00:00
  f8850cab1d
• [codex] Bind shell snapshots to retained thread environments (#28421)

  ## Why
  
  Shell snapshots are currently session-scoped even though shell and cwd
  are properties of a selected turn environment. That makes snapshot
  refresh depend on separate session-cwd plumbing, prevents retained
  environments from retaining their snapshot work, and can make snapshot
  construction use a different shell than command execution.
  
  This follows #27955 by making the retained thread-environment service
  own environment snapshot lifecycles. Session configuration remains the
  requested selection state, while `ThreadEnvironments` remains the source
  of successfully resolved environments.
  
  ## What changed
  
  - Configure the shell-snapshot builder before initial environment
  resolution.
  - Start each local environment snapshot task when its `TurnEnvironment`
  is built and retain that shared task while environment ID and cwd still
  match.
  - Inherit retained environment snapshots into spawned child threads.
  - Carry the selected `TurnEnvironment` through shell runtimes so
  snapshot construction and command execution use the same
  environment-specific shell and cwd.
  - Load project instructions and warm plugins/skills after initial
  environment resolution.
  - Continue decoding invalid UTF-8 instruction files lossily without
  emitting a startup warning.
  - Keep requested selections in `SessionConfiguration`; failed or
  duplicate resolutions only affect the resolved environment snapshot.
  
  ## Validation
  
  - `cargo check -p codex-core --tests`
  - `just test -p codex-home instructions` (6 passed)
  - Focused environment, instruction, shell-snapshot, and user-shell tests
  (84 passed)
  - Focused shell-snapshot, user-shell, and unified-exec tests (126
  passed; two event-timing tests passed on retry)

  pakrym-oai · 2026-06-15 20:10:53 -07:00
  022f1221e8
• [codex] retain resolved environments across turns (#27955)

  ## Why
  
  Selected execution environments are thread-scoped resources, but startup
  and turn construction repeatedly resolved their IDs and working
  directories. That discarded existing environment handles and shell
  metadata even when a selection had not changed.
  
  Session configuration updates also need to affect future turns without
  changing the resolved environment set already captured by a running
  turn.
  
  ## What changed
  
  - Create a `ThreadEnvironments` service inside `Codex` from the spawned
  `EnvironmentManager` and raw environment selections, then store it on
  `SessionServices`.
  - Split service construction from `update_selections`, allowing session
  configuration updates to mutate the resolved set in place.
  - Retain an existing `TurnEnvironment` when its environment ID and
  working directory match; resolve only added or changed selections and
  remove selections that are no longer present.
  - Normalize duplicate IDs by keeping the first selection and skip
  individual selections that fail to resolve instead of rejecting the
  entire update.
  - Give each `TurnContext` a cloned `TurnEnvironmentSnapshot`, so later
  session configuration updates affect future turns without rewriting an
  active turn.
  - Reuse the service-owned environment manager and resolved snapshot for
  startup work, MCP initialization, and child-thread spawning instead of
  flowing resolved environments through spawn arguments.
  
  ## Test plan
  
  - `cargo check -p codex-core --tests`
  - `just test -p codex-core environment_selection`
  - `just test -p codex-core turn_environments`
  - `just test -p codex-core
  session_update_settings_does_not_rewrite_sticky_environment_cwds`
  - `just test -p codex-core
  default_turn_does_not_overlay_legacy_fallback_cwd_onto_stored_thread_environments`

  pakrym-oai · 2026-06-15 16:15:07 -07:00
  9728992fab
• feat(core): add metadata field to ResponseItem (#28355)

  ## Description
  
  This PR adds an optional `metadata` field to `ResponseItem` for
  Responses API calls. Only mechanical plumbing, no actual values
  populated and sent yet. Turns out just adding a new field to
  `ResponseItem` has quite a large blast radius already.
  
  This change is backwards compatible because `metadata` is optional and
  omitted when absent, so existing response items and rollout history
  without it still deserialize and requests that do not set it keep the
  same wire shape. For provider compatibility, we strip out `metadata`
  before non-OpenAI Responses requests so Azure and AWS Bedrock never see
  this field.
  
  My followup PR here will actually make use of it to start storing and
  passing along `turn_id`: https://github.com/openai/codex/pull/28360
  
  ## What changed
  
  - Added `ResponseItemMetadata` with optional `turn_id`, plus optional
  `metadata` on Responses API item variants and inter-agent communication.
  - Preserved item metadata through response-item rewrites such as
  truncation, missing tool-output synthesis, compaction history
  rebuilding, visible-history conversion, rollout/resume, and generated
  app-server schemas/types.
  - Strip item metadata from non-OpenAI Responses requests while
  preserving it for OpenAI-shaped requests.
  - Updated the mechanical fixture/test construction churn required by the
  new optional field.

  Owen Lin · 2026-06-15 15:05:28 -07:00
  040dafa32d