## Why
Spawning a subagent before an environment was ready dropped the starting environment from the child's selections. The child needs to retain that environment and receive its configuration or failure when preparation finishes.
## What changed
- Pass the spawning step's environment snapshot to children, preserving ready and starting environments and configuration ownership.
- Propagate the original owner's first configuration result through descendants, applying each session's validation and leaving independently configured children unchanged.
- Preserve pending configuration waits across executor retries. Later owner updates do not overwrite the child's inherited configuration.
## Testing
Add regression coverage for fresh and forked subagents, readiness through turn-settings updates, failure propagation to children and grandchildren, child configuration precedence, and executor retries. Add a request snapshot showing a child using `wait_for_environment` before execution tools become available.
GitOrigin-RevId: a2afed740391f88d195596cfe28e418332b60d43
## 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
Thread permission updates could affect later steps of a running turn. Keep inherited environment settings consistent throughout the turn and apply saved updates when the next turn starts.
## What changed
Store active thread defaults alongside selected environments and refresh them when activating a new turn, even when its environment selections are unchanged. Resolve new selections from those active defaults while preserving owner-provided configuration, selection workspace roots, and the local Windows sandbox type.
## Testing
Add a regression test that changes permissions during a paused turn and verifies that both steps retain restricted filesystem access while the next turn receives unrestricted access. Update session and MCP elicitation tests to check that permission changes take effect on the next turn.
GitOrigin-RevId: 37ee44198fa40c138d140974dc90c4177d8c1f4c
## What changed
Add the default-off `features.prefer_mxc` flag to select MXC for local Windows execution when native support is available and effective network settings do not explicitly forbid local binding. Otherwise, retain the configured backend and legacy setup behavior.
Resolve the preference during config loading and use the effective local backend for execution, network proxy setup, sandbox diagnostics, and `windowsSandbox/readiness`. Preserve the configured backend for remote executors and `config/read`. Explicit `windows.sandbox = "mxc"` remains strict, and command failures do not trigger backend fallback.
## Testing
Add coverage for preference resolution, startup readiness without rewriting configuration, local and remote backend selection across environment updates and child threads, and workspace-write permission context in an agent turn.
GitOrigin-RevId: b51178f0371d38ebb58e41af54a068fca67fa316
## Why
MXC's native host-loopback access is bidirectional, so it cannot enforce `allow_local_binding = false`. Treating an omitted setting as `false` prevents managed networking from working with the default configuration.
## What changed
- Preserve an omitted `allow_local_binding` until the executor's sandbox policy is known. Default to `true` for Windows MXC and `false` elsewhere, including remote execution.
- Reject an effective `false` for MXC managed networking after applying policy restrictions, without enabling disabled networking.
- Use the executor's resolved value for remote network approval decisions while preserving explicit controller restrictions.
- Document that local binding permits local servers and direct host-loopback connections and skips additional private-network destination checks; proxy domain rules still apply.
## Testing
Add coverage for per-executor defaults, explicit values, MXC rejection of `false`, and remote network review cleanup with the resolved policy.
GitOrigin-RevId: 0fa7c1eaec68bebada2b8f7af45688315eea70a9
## Why
Environment settings saved for the next turn must not change MCP tool availability during the active turn.
## What changed
- Use one captured environment snapshot for MCP policy evaluation and runtime publication, including selections that are still starting or have failed.
- Compare both captured selections and ready environment handles when deciding whether to refresh the runtime, and rebuild the startup configuration when resolved selections change.
- Preserve the configuration origin of failed selections so MCP authority evaluation retains whether configuration comes from the thread.
- Box the MCP refresh future to keep it off the sampling request's stack.
## Testing
Add a regression test that updates the environment MCP policy while a turn waits for user input, verifies the tool remains visible when that turn resumes, and verifies it disappears on the next turn. Extend snapshot tests to cover starting and failed selections.
GitOrigin-RevId: cc2744b5137be69f000d70b0c7009b14079f39ae
## Why
Updating environment selections while a turn is running must not redirect its tools or prevent its pending environment setup from completing.
## What changed
- Store future environment selections separately from active environments, and activate them when preparing new work with no task running.
- Keep turn contexts and MCP workspace roots tied to the active environment snapshot. Report saved selections through thread settings and `environment_selections()`.
- Route environment configuration and failure callbacks to matching active or future selections so each can finish setup independently.
- Stop the running task before manual compaction adopts the saved environments.
## Testing
Add regression tests that preserve a running task's working directory and workspace roots, then adopt the saved selection for the next task. Add remote environment coverage showing that future setup can complete while the active turn waits, with each turn receiving its own capability roots.
GitOrigin-RevId: 09a6b90131d2ab2441ce2fe9b0368a3668889f31
## Why
Model requirements must be evaluated against the permissions that will apply
after a settings update. Validating against the current profile can reject a
valid model-and-permission update or allow a later permission-only update to
invalidate the selected model.
## What changed
- Group model, reasoning, service-tier, personality, and approval inputs into
`StepSettings`, with a single apply-and-validate path.
- Apply permission and environment changes before validating step settings, so
auto-review requirements use the proposed effective permissions.
- Revalidate existing step settings when permission or environment changes alter
their constraints, and commit the update only when the complete candidate is
valid.
## Testing
Added unit and integration coverage for atomic model/permission updates,
permission-only revalidation, environment-derived constraints, and both
standalone and turn-start settings operations.
GitOrigin-RevId: f50dfbd300484a09acc51ee4607278f300ca1cd9
## Why
`EnvironmentConfig.network_policy` could describe attachment-owned traffic
restrictions, but core rejected every configured policy because execution did
not enforce it.
## What changed
- Resolve each remote environment's network policy for the selected command
and apply it to the execution-scoped proxy.
- Compose owner rules with controller constraints and saved network decisions
while preserving inherited domain and Unix-socket denials.
- Keep strict allowlists non-expandable, allow reviewable policies to use
network approvals, and reject sandbox escalation that would bypass an owner
policy.
- Reject policies for local execution, disabled managed enforcement, or a
disabled controller proxy.
## Testing
Added coverage for policy composition, scoped remote proxy behavior, approval
and denial flows, offline execution, and unsupported environment authority.
GitOrigin-RevId: d9331f616df24de6cd13ed68196f0ff7b0ca4dd9
## Why
Environment-owned permission profiles and workspace roots must remain effective
without being persisted or restored as thread-owned settings.
## What changed
- Keep thread settings snapshots and restore data separate from the effective
configuration supplied by the primary environment.
- Use resolved environment permissions, active profiles, workspace roots, and
network policy when building turn context and session events.
- Preserve environment selections when agents are evicted, resumed, or spawned,
and validate owner configuration when it becomes ready.
- Start memory initialization only after the primary environment is configured.
## Testing
- Extend remote-environment and multi-agent tests to cover settings persistence,
owner permission profiles, workspace roots, spawning, eviction, and resume.
GitOrigin-RevId: d82f126981cd0190233020bbdd61d96c70558868
## Why
Thread settings could replace an owner-provided environment configuration with
`FromThread`, allowing the thread to take ownership of that configuration.
## What changed
Reject environment settings updates that change an existing owner-provided
configuration to `FromThread`.
## Testing
Cover preview and turn settings updates for pending, ready, and failed
owner-provided environments.
GitOrigin-RevId: c516954819447ceb29e2ff9f29fe781ca101ae54
## What changed
- Add `EnvironmentNetworkPolicy` as a serializable view of portable domain,
Unix-socket, upstream-proxy, and local-binding restrictions without exposing
controller-owned proxy runtime settings.
- Add an optional `network_policy` field to `EnvironmentConfig` and re-export
the policy and related permission types through the core APIs.
- Reject owner-provided network policies during environment preview and
readiness until runtime enforcement is implemented, while preserving the
existing controller policy when the field is absent.
## Testing
- Cover rejection through both environment preview and readiness, including
preservation of the existing environment selection.
GitOrigin-RevId: 80ad4cf4d4a45632daa7a823e6cf568eb0e8bb80
## What changed
- Add an optional restrictive execution policy to `EnvironmentConfig` and merge it over the active command policy for shell execution and approval decisions.
- Reject environment policies that contain allow rules, so environment configuration can only tighten command access.
- Include the environment policy fingerprint in cached approval keys so policy changes require fresh session approvals.
## Testing
- Cover restrictions overriding saved prefix approvals, policy changes invalidating session approvals, and environment overlays remaining effective when model-specific prefix filtering is active.
GitOrigin-RevId: e94f877549ed5e0f577b8cb52f3c1872c58f029d
## What changed
- Carry `ShellEnvironmentPolicy` in each resolved `EnvironmentConfig` and use
the selected turn environment's policy for shell commands, user shell tasks,
and unified exec.
- Infer the policy from the thread configuration when an environment does not
provide its own resolved configuration.
- Redact the policy from `EnvironmentConfig` debug output because it can contain
explicit environment variable values.
## Testing
- Verify shell handlers and unified exec filter inherited variables according
to the selected environment while preserving its explicit overrides.
GitOrigin-RevId: 9f6a52aa4af60e5f17251a0e1b11e1926b779055
## Why
An environment connection can be available before its owner has supplied the
configuration for a particular thread attachment. Threads need to start without
blocking while ensuring turns do not use that attachment prematurely.
## What changed
- Accept `Pending` environment configuration and resolve each attachment only
after both its shared executor connection and owner configuration are ready.
- Add a `Failed` configuration state and `environment_failed` callback so an
owner can fail one thread's attachment without affecting other threads.
- Keep pending and failed attachments out of capability-root inspection and turn
environments, and allow failed attachments to recover through a ready update.
- Apply owner configuration before waking a waiting turn so its permission
profile, login-shell policy, capability roots, and tools are immediately
consistent.
## Testing
Add an integration test covering non-blocking thread startup, independent ready
and failed callbacks, waiting-turn resumption, installed capability and tool
configuration, and recovery from failure.
GitOrigin-RevId: d587e2025d584c867d782d470b18bf5a1a27b76c
## What changed
- Add `EnvironmentConfigState` to `TurnEnvironmentSelection` so each environment attachment can inherit thread configuration or carry ready configuration for its login-shell policy and selected capability roots.
- Apply ready configuration during thread creation and thread-settings updates while reusing the existing environment connection.
- Validate selection configuration before applying settings, rejecting unsupported pending state and invalid capability roots.
## Testing
- Cover attachment-scoped capability roots, ready configuration at thread startup and turn updates, and rejection of invalid selections without changing existing settings.
GitOrigin-RevId: 86cf8f2148fdaa746ea0dd12890ab7b1577d7587
## What changed
- Make `ThreadEnvironments` the source of truth for live environment selections and use it when building configuration snapshots, permission profiles, per-turn configuration, and MCP refresh inputs.
- Keep settings previews side-effect free while applying accepted environment updates consistently to subsequent turns.
- Move `EnvironmentConfig` into `codex-protocol` so environment ownership no longer depends on a core-only type.
## Testing
- Cover environment previews and snapshots, accepted and rejected steer updates, and active-turn environment stability.
GitOrigin-RevId: 7bcf8fb5df1215f720e4e9c419541a51a871aa5e
## Why
Threads that share an executor environment can require different capability roots and login-shell policies. Treating readiness configuration as executor-wide can expose one thread's settings to another.
## What changed
- Add `CodexThread::environment_ready` and `EnvironmentConfig` so hosts can install capability roots and login-shell policy for an exact thread, environment, and working-directory attachment.
- Validate attachment readiness updates, merge ready attachment roots with persisted thread roots, and refresh MCP capabilities when those roots change.
- Preserve installed environment policy across thread settings updates and child-thread inheritance while resetting it when the selected working directory changes.
## Testing
- Cover attachment config inheritance and reset behavior.
- Verify that threads sharing an executor retain independent model-visible capability roots and login-shell tool schemas across updates.
GitOrigin-RevId: 60e7a296b3e41b835b0413aa2837451e8a55c230
sayan-oai