## Why
Incremental tool declarations were limited to Responses Lite. Regular OpenAI Responses requests sent the full current tool catalog on each request.
## What changed
- Add the disabled-by-default `incremental_tools_legacy` feature for regular OpenAI Responses, independently of the Responses Lite `incremental_tools` flag.
- Support tool declarations and updates in conversation history, including during compaction, while preserving existing history prefixes.
- Keep hosted `web_search` configuration in top-level `tools` rather than `additional_tools`, including in compaction requests.
## Testing
Extend request-history scenarios and snapshots to cover regular Responses catalog updates, model switches, compaction, and MCP tool removal and restoration. Assert that incremental requests preserve input prefixes and keep web search out of history declarations.
GitOrigin-RevId: fa347409e387aa973ce2e41df8505769b7db1ec2
## Why
Agent messages that arrive after a model request starts must survive compaction until a normal inference request includes them. Compactor output alone does not establish that those messages were delivered.
## What changed
- Persist history sequences and sampling checkpoints in harness metadata, capturing the input prefix for each normal inference request.
- Retain pending agent messages within existing size budgets during local and remote compaction, placing the summary before pending messages and subsequent caller input.
- Preserve sampling progress across history replacement and resume, and drain queued mail after interrupted sampling even when compaction leaves context above the token limit.
## Testing
Add regression coverage for request-boundary sampling checkpoints, pending messages across local compaction and repeated remote compaction with resume, and injected messages that interrupt sampling before mid-turn compaction.
GitOrigin-RevId: 26c04ab96b5a1c3cc1d6625ccc74a0f00201d14c
## What changed
- Match final serving assessments to their response and output item, then retain them with tool invocations and code cells across waits.
- Use matching assessments instead of asynchronous scoring for adaptive review: low-risk actions can skip synchronous review, while elevated-risk actions require it.
- Revalidate captured authorization and policy before approval. Require fresh review for stale or incomplete authorization, preserve explicit review requirements, and discard assessments when hooks rewrite tool input.
- Keep asynchronous scoring as the fallback when an assessment is missing or does not match.
## Testing
Add integration coverage for direct and nested tool calls, hook rewrites, explicit escalation, interrupted responses, catalog-driven policy, incomplete authorization, and assessment retention across code-cell yields and waits.
GitOrigin-RevId: 4346a227204137f018c03c34b302d6f1e9592c96
## What changed
- Include ready environments' configured hooks in lifecycle events and execute command hooks using each owner's shell, working directory, shell environment policy, and managed network policy.
- Resolve tool environments before `PreToolUse` and use those targets for tool hooks, execution, and permission review. Route MCP hooks by server ownership and file-copy hooks to both endpoints.
- Preserve environment, MCP server, and terminal session selectors across hook input rewrites, rejecting attempts to switch targets.
## Testing
Add regression coverage for permission-request selector preservation, MCP resource hook ownership, and file-copy hooks that rewrite paths while preserving source and target environments.
GitOrigin-RevId: 31a3a6830523965285dab451cfc866c620ef6c83
## Why
Executor hooks depended on V1 discovery snapshots, so plugins discovered through V2 could not run their cleanup hooks.
## What changed
Prepare executor hook sources during step setup from either V1 or V2 discovery and capture them in `StepContext` for stop, interrupt, and memory consolidation hooks. Restrict V2 sources to selected plugin installations while preserving plugin enablement, hook admission, MCP routing, and app tool policy checks.
## Testing
Add unit coverage for V2 hook admission, environment routing, disabled plugins, and failed discovery. Add integration coverage showing that `Stop` and `Interrupt` cleanup hooks run with V2 discovery alone and remain silent when the plugin is disabled.
GitOrigin-RevId: a4c0e9c56bdebcdf22cea63f02f8fb4c5eed358e
## Why
Temporary environment attachments for a parent turn should not become a
subagent's persistent environments. Children also need to retain their
configured executor bindings when their runtime is evicted and reloaded.
## What changed
- Add the disabled-by-default `subagent_thread_environments` feature flag.
When enabled, both subagent implementations inherit configured thread
environments captured with the invoking step, excluding turn-only attachments.
- Track configured bindings separately from active turn attachments, preserving
pending configuration ownership and sharing completed executor startup.
- Retain configured selections and bindings across idle eviction. Reload children
using retained bindings when the parent changes workspace, while continuing to
validate current parent roots and permissions for matching workspaces.
## Testing
Extend regression coverage for configured, empty, forked, pending, and legacy
inheritance; temporary attachment removal across eviction; and reload behavior
with changed workspaces, deferred startup, and restricted permissions.
GitOrigin-RevId: 15692ecd99deb38002014b44fd859d793bd54373
## Why
Skill tools depended on World State rendering to initialize their catalogs and could return `skill catalog is not ready for this step` before rendering completed.
## What changed
- Add an asynchronous `ToolContributor::prepare_for_step` hook and await all contributors before constructing tools.
- Prepare immutable skill catalogs, aliases, plugin policy, and configuration for each step. Tools, invocation detection, and World State rendering consume the prepared state without relying on rendering to perform discovery.
- Apply configuration reloads to subsequent steps while preserving live authorization checks for skill reads.
## Testing
Add coverage for preparation completing before tool construction and World State rendering, skill tools working before rendering, catalogs remaining stable across steps, and configuration reloads during discovery.
GitOrigin-RevId: 1fb95c58c412488353f3bd4403824d6d1476d3d0
## What changed
- Remove `subagent_thread_environments` and the separate configured environment bindings. Spawned agents inherit the invoking step's environment snapshot.
- Retain environment selections across child eviction without retaining executor bindings. Reload V2 children against the parent's captured environments, requiring matching environment IDs, working directories, and workspace roots while preserving permission validation.
GitOrigin-RevId: d820c63ea20f5834ed88071d16c60683f2545406
## Why
Temporary environment attachments for a parent's turn should not become a child's persistent environment configuration or survive child eviction.
## What changed
- Add the default-disabled `subagent_thread_environments` feature flag. When enabled, subagents inherit configured thread environments captured with the spawning step instead of active turn selections.
- Track configured bindings separately from turn attachments, preserving pending configuration ownership when turn selections change.
- Retain configured bindings across child eviction and reload, excluding temporary attachments. Preserve the child's workspace when the parent switches workspaces, while enforcing current roots and permissions when the parent still configures the same workspace.
## Testing
Extend coverage for both multi-agent versions, forked children, empty configured environments, pending configuration, and legacy inheritance. Add eviction and reload cases covering temporary attachments, workspace changes, deferred executor startup, and permission validation.
GitOrigin-RevId: 4533645503d5f863a9ccc064386ed7ca169d98b7
## What changed
- Add the disabled-by-default `executor_capability_discovery_v2` feature to acquire `capabilities/discoverV2` inventories from supporting remote executors using each selected environment's working directory and sandbox.
- Share snapshots with MCP and world-state contributors and skill providers without activating discovered plugins or publishing discovered skills to the model.
- Cache inventories by environment instance, executor session, working directory, and sandbox. Coalesce concurrent requests, refresh the cache at turn start, retry transient failures, and refresh MCP projections after recovery.
- Resolve the system skills root in the executor and pass it explicitly to capability location discovery.
## Testing
Add coverage for feature gating, unsupported executors, inert inventories, cache reuse and eviction, turn refreshes, failure recovery, executor replacement, and system skill locations.
GitOrigin-RevId: 1bdca28fa7f17622b27e2713ab3dcc0c13426889
## What changed
Remove `workspace_roots`, `current_date`, `timezone`, `network`, `personality`, and `multi_agent_mode` from `TurnContextItem` and stop recording them in rollouts. Update the precomputed protocol schema accordingly.
Make `summary` optional when reading turn context and write `"none"` as a compatibility placeholder for older readers, rather than persisting the active reasoning-summary setting.
## Testing
Update protocol tests to cover omitted `summary` fields and compatibility-placeholder serialization. Extend compaction tests to verify that model requests retain the updated reasoning-summary setting after compaction while the rollout checkpoint records the placeholder.
GitOrigin-RevId: d49eabaa1b340be1d79f7f09115281a307ea8a64
## Why
Changing the incremental tools setting on resume should not move tool declarations and base instructions within an existing context window.
## What changed
- Determine the current window's tool declaration mode from its history, and apply the incremental tools setting when building a new window after compaction or a context reset.
- Use that mode consistently for sampling, remote compaction, startup prewarm, prompt debugging, and Guardian input budgeting.
- Preserve tool declarations alongside their comparison baseline in full-history agent forks, including compacted histories; remove them together when rebuilding context.
## Testing
Add request snapshots covering legacy resume, migration after remote compaction or a context reset, disabling incremental tools, and tool updates after restart. Extend agent fork and WebSocket startup prewarm tests to cover retained declarations and incremental tools.
GitOrigin-RevId: 7c46849a1788027a8435082e4d1f7e7f48d2700c
## What changed
When `IncrementalTools` is enabled for Responses Lite, track tool definitions in world state and conversation history. Send the initial catalog once, then append only added or changed definitions while preserving earlier request history. Emit developer notices for removed tools and namespace instruction changes.
Use history-supplied definitions for normal requests and remote compaction, and omit empty `additional_tools` prefixes. Keep the existing tool delivery behavior for the Responses API and when the feature is disabled.
## Testing
Add unit and snapshot coverage for catalog and namespace transitions, empty catalogs, and stable hashing across JSON object key order. Add a request-history scenario covering unchanged tools, a model switch that changes one definition, persisted catalog hashes, and Responses API behavior.
GitOrigin-RevId: 76bde175973b81f8ad23873919da3c8ddcdf6065
## Why
Environment changes and overlapping catalog refreshes can cause a step to use another step's selected plugins or executor skills. Model context and skill tools need to agree on the capabilities captured for that step.
## What changed
- Resolve selected plugins from each step's ready capability roots, honoring disabled plugins, and retain the snapshot with the step's extension data.
- Use that snapshot for skill attribution in World State and the first step's active-plugin telemetry.
- Return executor skill catalogs directly from refresh so overlapping requests render their own results while retaining thread caches.
## Testing
Add regression coverage for overlapping executor catalogs and environment changes during step preparation. Verify that `skills.list` retains the original step's skills, the next step advertises the new skills, and disabled executor and plugin skills remain absent from model context.
GitOrigin-RevId: 37d3cbe8c7e062fd06290aa985ada4d3b3462d43
## Why
Executor skill reads need to use the environments and permissions captured for the current step, including newly approved grants. Cached continuation pages must remain bound to the filesystem and permissions that produced them.
## What changed
- Supply borrowed `EnvironmentAccess` to turn-input contributors and extension tools, with session and originating-turn grants already applied.
- Require executor skill reads to use filesystem access from an environment available to the callback, and replace separate optional read contexts with `SkillReadContext`.
- Bind skill pagination snapshots to `EnvironmentAccessKey`, which identifies the source filesystem and callback permissions.
- Route image-generation filesystem operations through the same accessor.
## Testing
Extend skill-read integration coverage to verify that a denied reference becomes readable after a turn-scoped grant is captured by the next model step. Update Windows coverage to verify that restricted reads fail when the executor cannot enforce a sandbox, and add a test requiring turn environment selection before exposing capability roots.
GitOrigin-RevId: 825b49302319965835d61c77fc5bcdb951e10543
## Why
Background code-mode cells can continue running after a new turn starts. Looking up grants and strict review requirements through the active turn can make those cells lose their approved access or use another turn's permissions.
## What changed
- Keep turn-scoped grants and strict review state in `TurnContext`, retained by captured steps and background cells.
- Record permission responses against the requesting turn, including requests made after a later turn starts.
- Share live session-scoped grants across turns while keeping turn-scoped grants isolated.
- Use the originating turn's permissions and review requirements for tool execution, patches, MCP calls, file uploads, and terminal input.
## Testing
Add regression coverage for background cells retaining grants across turn changes, turn versus session scope, permission requests after the next turn starts, and strict review enabled while `write_stdin` is queued.
GitOrigin-RevId: 641502fbfd43553c2c42424d4aaa53ae8020c850
## Why
With `instant_interrupt` enabled, new user input should reach the model without waiting for an unfinished response or stream retry backoff.
## What changed
- Interrupt request setup, response streaming, and retry backoff when user input arrives, then continue the turn with the queued input.
- Reset the WebSocket connection and continuation state after preemption so the next request sends full history.
- Drain pending input after a preempted step even when compaction leaves the estimated context above the token limit.
## Testing
Add regression coverage for WebSocket reconnection with full history, interrupted retry backoff, input queued during compaction, and yielding running code-mode calls. Add a streaming scenario that preserves completed commentary while excluding unfinished assistant text from the replacement request.
GitOrigin-RevId: b7e42b6afffbf87da15af05e0850af8579d1353f
## Why
User input queued during a long-running code-mode `exec` or `wait` can remain pending until the call returns. Allow these calls to yield early so Codex can receive the new input while the cell continues running.
## What changed
- Add the `instant_interrupt` feature flag, disabled by default.
- Watch queued user input for each sampling request and pass a shared preemption signal to code-mode `exec` and `wait` calls, including calls received later in the same response.
- Yield running cell IDs without stopping the cells, allowing subsequent `wait` calls to collect their results.
## Testing
Add integration coverage for enabled and disabled behavior, repeated steering during `exec` and `wait`, input deferred during compaction, and later calls in the same response. Verify that direct tool results and queued user messages are preserved, and add a scenario snapshot showing continuation after a cell yields.
GitOrigin-RevId: e33466a980d98e113bfb6c6a45c59de0cc7b3c1d
## Why
A realtime call can start or end while a text turn is still running. Using call activity captured at turn creation leaves subsequent model requests with stale realtime context.
## What changed
Capture realtime activity and mode instructions together in a `StepContext` snapshot for each model request. Use that snapshot to build realtime instructions and persist `realtime_active` in the request's turn context. Store the conversation and mode instructions under one mutex so they are installed together when a call starts.
## Testing
Extend the realtime handoff integration test to start and close a call during one text turn, verifying that successive requests include the appropriate start and end instructions.
GitOrigin-RevId: 4c5c2b47b7c0c06ae28167013218dc2e3cd72c42
## What changed
- Add `environments` to `TurnSettingsUpdate` to replace the selection for subsequent steps without changing future turns.
- Capture model settings and environments together so combined updates apply or reject atomically, while existing steps retain their captured selection.
- Validate environment IDs, working directories, configuration ownership, and permission requirements against the running turn's selections.
- Preserve executor startup behavior when switching environments and use the step's local working directory for tool hooks.
## Testing
Add coverage for workspace switching and restoration on the next turn, atomic model and environment updates, permission validation, executor connection waits, and replacement of pending environment selections.
GitOrigin-RevId: 02b5c57a78fd594b2aed84fc09d9e99eb97be28c
## Why
Background processes can outlive their launching turn. Their approval reviews need the originating environment's filesystem restrictions, even when the active turn uses a different environment. Remote restrictions must also be resolved using executor paths rather than the local filesystem.
## What changed
- Capture settings and environment selections together in `StepInputs`. Preserve the captured selection during active model updates while allowing environment startup to finish.
- Carry environment IDs into Guardian network and `execve` requests, and use the owning process's environment with current review settings. Refresh environment readiness for network requests that fall back to the active turn.
- Resolve remote denied paths and globs using the executor's policy context. Decline automatic approval when the request's environment is unavailable or an explicitly denied temporary directory cannot be resolved.
## Testing
Add regression coverage for active model updates retaining their environment while the next turn adopts a new selection, background approvals using their owning environment, newly ready network environments, and remote denied paths and globs, including Windows paths and missing temporary-directory metadata.
GitOrigin-RevId: b620d4b030c597a4f430fe0500864fa5469db3d4
## Why
Command execution and plugin measurement events lack model and reasoning-effort labels. Attribution needs to reflect the step that invoked the command, even when model settings change before a background process finishes.
## What changed
- Add `model_slug` and `reasoning_effort` to command execution and plugin measurement analytics.
- Capture model context from resolved step settings and carry it through execution, approval, Guardian review, and plugin metrics collection.
- Preserve the first command-start model context when subsequent start notifications arrive.
- Keep the carried context out of serialized protocol items and generated schemas.
## Testing
Extend analytics tests to cover model switches before invocation and during background execution, default reasoning effort, Guardian-denied commands, and repeated start notifications retaining the original model context.
GitOrigin-RevId: af90e1c0d39bab625f2e89786085b61a9b96c0ce
## What changed
- Update the status heading from the latest usable reasoning line and retain it through tool activity and empty reasoning items. Keep completed reasoning in the expanded transcript only.
- Restore active reasoning after resume, thread switches, and session refreshes, including when earlier events have left the replay buffer.
- Default new embedded TUI threads to `model_reasoning_summary = "detailed"`, honoring explicit summary settings. Keep `concurrent_reasoning_summaries` opt-in and disable it when summaries are `none`.
- Persist the request's captured reasoning summary setting in context updates and local and remote compaction checkpoints.
- Animate status text with a smooth, grapheme-aware shimmer that respects terminal colors and reduced motion.
## Testing
Add regression coverage for reasoning status updates, transcript visibility, resume and buffered replay, outbound summary configuration, and summary settings across all three compaction modes. Add shimmer snapshots and checks for smooth brightness changes and Unicode grapheme preservation.
GitOrigin-RevId: 725c7de20f23166d7a3da6daeca617add5cbc600
## Why
Model settings can change between steps in the same turn. Token-budget defaults,
context-window limits, and model-visible guidance need to stay aligned with the
model captured for each step.
## What changed
- Preserve the turn's original token-budget preferences and resolve model-owned
defaults when each `StepContext` is created.
- Use the step's model to determine context-window availability and token-budget
guidance, while keeping explicit user settings unchanged.
- Emit one-time replacement or removal notices when context-window guidance
changes, including compatibility with previously persisted world-state
snapshots.
- Add `ModelInfo::usable_context_window()` to distinguish reserved-headroom
capacity from the resolved context window and auto-compaction limit.
## Testing
- Cover mid-turn model switches with model defaults, explicit settings, config
reloads, missing context windows, and missing destination guidance.
- Cover unchanged, replaced, removed, blank, and legacy guidance transitions.
GitOrigin-RevId: 91100a9f3625bef8a79ecd158eb028051c309eee
## Why
Thread settings can change while a turn is running, and delegated review or
compaction steps can select a different model. Each request needs a consistent
set of settings resolved against the model that will execute it.
## What changed
- Capture immutable resolved settings for each model step, including model
metadata, reasoning options, service tier, approvals, and personality.
- Keep in-flight steps on their captured settings while applying thread updates
to subsequent work.
- Resolve inherited reasoning summaries and filter service tiers against the
selected model and feature configuration for review and compaction steps.
## Testing
Added coverage for settings updates during paused turns, model changes,
previous-model compaction, review-model defaults, and service-tier filtering.
GitOrigin-RevId: fca4b3b305379f1bf26a5cac75ee0dd1747ac1f6
## Why
Thread settings can change while a turn is still active, including between sampling requests. Those updates should apply to the next turn instead of changing the model configuration partway through the current turn.
## What changed
- Snapshot the model, reasoning settings, service tier, approval settings, and model-attributed telemetry in `StepContext`.
- Build prompts, model requests, world state, tracing, and startup prewarms from that step-scoped snapshot.
- Share immutable model metadata between turn and step contexts.
## Testing
Added an integration test that pauses an active turn, updates its thread settings, and verifies that all requests in the active turn retain the original settings while the next turn uses the updates.
GitOrigin-RevId: c51352218e463dcc9b7338566d16742292c49fbf
## What changed
- Read the frozen MCP tool catalog directly from the step-scoped `McpBinding`
when building tool routers, plugin injections, and connector state.
- Remove the redundant `Vec<ToolInfo>` from `StepContext` and stop returning a
duplicate catalog from `built_tools`.
GitOrigin-RevId: d12d694e1224da3f6ccb1960868491f0d80c6e19
## What changed
- Make `McpRuntime` own the published MCP configuration, connections, elicitation routing, and selected capability roots for a thread.
- Capture immutable MCP bindings for model steps and tool calls so in-flight work keeps a consistent connection set and approval authority while refreshed state is published atomically.
- Mark MCP state dirty when relevant configuration, plugins, environments, authentication, or elicitation capabilities change, then rebuild it before the next sampling request or out-of-band MCP operation.
- Separate config reloads from server invalidation: `ReloadMcpConfig` applies resolved MCP inputs, while `RefreshMcpServers` requests reinitialization from the thread's latest state.
## Testing
- Cover refreshed state visibility for existing turns, stable step bindings, current approval authority, cancelled refresh retries, resource-client reconciliation, and Apps recovery between sampling requests.
GitOrigin-RevId: 59eabb1aa8dc083426bd18ef4d3630508f376401
## Why
Interrupting a turn while MCP tools were still starting could abort before the
submitted user input was recorded in conversation history.
## What changed
- Build and retain the MCP tool list and tool router as part of each step
snapshot, using the turn cancellation token during tool discovery.
- Record turn hooks and submitted input when cancellation occurs during startup
prewarming, pre-sampling compaction, or first-step capture.
- Reuse the captured router for sampling, compaction, and prompt debugging so
advertised and executable tools share the same request-scoped view.
## Testing
Add coverage that interrupts each affected MCP startup phase and verifies that
the user prompt remains in history before the turn-aborted marker.
GitOrigin-RevId: 6e96c6814357a55545d69b580e28f35933cfadf7
## What changed
- Remove the step-scoped `ExtensionData` argument from context, turn-input, and tool contributors.
- Pass the host's optional `McpResourceClient` through `ThreadStartInput` so extensions can retain session capabilities explicitly.
- Keep the MCP resource client in skills-owned session state for catalog loading and skill tools.
GitOrigin-RevId: bafa77bcd998aff408d6a396c5fd9ac268c4cce4
## What changed
- Add an `ExtensionData` store to each `StepContext`.
- Pass the step store to context, world-state, turn-input, and tool contributors so extensions can use capabilities bound to the current sampling step.
- Preserve the captured step context when rebuilding initial context during compaction.
GitOrigin-RevId: 51f3105d3a793f60534f122f9be8247c131c2ca5
## Why
Selected capability roots can contribute plugins, MCP servers, connectors, and
skills. Discovering each contribution separately requires repeated access to the
executor filesystem.
## What changed
- Add the `capabilityRoots/discoverV1` exec-server RPC to scan selected roots and
materialize recognized plugin manifests, configuration files, skill
instructions, and skill metadata in one bounded request.
- Add the opt-in `executor_capability_discovery` feature, with a thread-scoped
cache and per-step snapshot shared by MCP and skill discovery.
- Parse MCP, connector, and skill contributions from the materialized snapshot,
including serving cached skill instructions without another filesystem read.
## Testing
- Cover discovery limits, manifest precedence, root-local failures, cache reuse,
plugin contributions, and parity with the existing environment skill loader.
GitOrigin-RevId: f98fd2321cafb58c596db02da1f83c09d8eb375d
Follow-up to #30226.
## Why
#30226 makes Apps World State inspect the MCP tool list, while
tool-router construction reads the same list again later in the sampling
request. `list_all_tools()` walks the MCP clients and may reconnect or
wait for tools, so doing that work twice adds latency and lets context
and tool construction observe different MCP states for one request.
## What
- Add a lazy MCP tool snapshot to `StepContext`.
- Reuse that snapshot for Apps World State and tool-router construction.
- Let each new `StepContext` refresh naturally for the next sampling
request, without manager-level caching or invalidation.
## Testing
- `just test -p codex-core apps_instructions`
- `just test -p codex-core
apps_guidance_appears_after_background_recovery_within_a_turn`
## 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.
## 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.
## 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.
## 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`
## 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>
Alex Kira