sayan-oai

Honor per-environment login shell policy (#36811) ## What changed - Store the effective `allow_login_shell` setting on each turn environment, including inherited environments whose child thread has a different policy. - Expose the `login` argument for shell tools when any selected environment permits login shells. - Validate each command against the policy of its selected environment instead of the turn-wide configuration. ## Testing - Cover tool schema generation for single and multiple environments. - Cover login-shell rejection by both the command handler and the unified exec integration. GitOrigin-RevId: 5a93149a5c86f4087f2b92d663ebc33feff8a57c

Enforce environment MCP policies (#39335) ## What changed - Add environment-provided MCP restrictions for configured and plugin-provided servers. - Disable attachment-scoped servers while their environment configuration is pending, failed, or unselected, while preserving selected-plugin access and the controller-owned Apps server. - Apply the resolved policy to runtime startup, model tool exposure, telemetry, OAuth flows, and skill dependency installation. ## Testing - Cover policy filtering for configured and plugin servers, environment state transitions, Apps ownership, and managed OAuth rejection. GitOrigin-RevId: 7ca5d4dda14068e758497f88835d5cba685e159e

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`

Honor attachment-owned permissions for MCP servers (#40728) ## Why MCP servers attached to executor environments must retain their owner's permission profile instead of inheriting the thread-wide sandbox authority. ## What changed - Resolve and capture a permission profile for each enabled MCP server when publishing the runtime, and reject calls or elicitations when that authority is unavailable. - Use the captured server profile for tool approval decisions, elicitation, and sandbox metadata, including after runtime refreshes. - Materialize `:workspace_roots` from `PathUri` values so permissions preserve the path convention of remote executor environments. - Give threadless app discovery and resource reads an explicit default permission profile. ## Testing Added coverage for per-server elicitation authority, unresolved attachments, runtime refreshes, restricted tool calls, and foreign-platform workspace roots. GitOrigin-RevId: 6b188d4b08b29e9971ff7aa68a7785a0cdf9e394

Use turn environment permissions for tool execution (#37038) ## What changed - Derive sandboxing, approval, and permission-profile environment variables from the selected turn environment for shell, unified exec, `apply_patch`, image viewing, and network approval flows. - Materialize project-root permissions against every workspace root in that environment, allowing `apply_patch` to write to secondary workspace roots while preserving protected paths. - Carry the selected environment's permission profile into spawned or resumed agents and Guardian permission context. ## Testing - Add an integration test covering `apply_patch` writes in a secondary workspace root. - Extend tool, Guardian, and multi-agent tests to distinguish environment permissions from thread-level permissions. GitOrigin-RevId: e22da8974bcd3de1e724978b1a7790307a51e4bc

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`

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.

Use step environments for Guardian approval reviews (#37618) ## Why Deferred environments can become ready after a turn starts. Guardian approval reviews must use the environment selected for the current step so their working directory and permission context are not taken from the stale turn snapshot. ## What changed - Carry `StepContext` through tool execution and approval handling. - Add a Guardian review context that pairs the parent turn with the current step's environment snapshot. - Use that snapshot for Guardian prompts, reviewer sessions, and delegated reviewer threads while retaining turn-level fallbacks for callers without a step context. ## Testing Added an integration test that makes a deferred remote environment ready before an escalated command and verifies Guardian receives that environment's working directory and denied-read policy instead of the initial local environment's. GitOrigin-RevId: 779096bc7d0e0c7453a009c02141029714b9b407

Separate thread settings from environment configuration (#39597) ## 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

Enforce environment network policies for remote execution (#39980) ## 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