Execution Environments Should Own Their Configuration Policy
A runtime can let different turns select different execution environments. Working directory, permission boundary, and resource location all come from the resolved environment. If subprocess launch still reads environment-variable policy from thread-global state, however, the system develops a subtle split: work executes in environment B while process configuration obeys environment A.
The 2026-08-17 Research Object examined a merged Codex change. EnvironmentConfig now carries ShellEnvironmentPolicy. Regular shell, user-shell, and unified-exec build inherited variables and explicit overrides from the selected turn environment, with a session-derived configuration as an explicit fallback when no resolved environment exists. Regression tests deliberately conflict thread and environment policies, demonstrating that selected-environment filtering wins while its explicit values survive.
Those public primary-source implementation facts support the central conclusion: execution context describes not only where work happens, but who owns execution-scoped configuration.
Environment selection is incomplete without policy selection
A thread-global policy is simple when execution environment never changes. Once a turn can move to a container, remote host, or another local boundary, that policy can become stale. Filesystem and permissions come from the selected environment while PATH, proxy, toolchain, or credential-like variables come from another scope. Effective behavior becomes hard to explain and reproduce.
Passing a raw map per command does not automatically solve the problem. It distributes ownership among callers and makes it harder for separate executors to prove that they applied the same rules. A clearer model treats the resolved environment as a configuration-authority boundary. It carries inheritance filters and explicit values, and executors consume that policy instead of reaching back into historical state.
This does not mean an environment may override every higher-level constraint. An intentionally non-overridable organization policy can remain a separate governed layer, provided its merge order with environment-owned policy is explicit. The goal is not universal decentralization; it is an explainable source and precedence for every effective value.
Fallback and precedence must be part of the contract
When no resolved environment exists, fallback should not depend on implicit global state. The selected implementation uses a session-derived environment configuration, making the fallback source deterministic. A production contract should go further: when is fallback allowed, which variables are inherited, whether filtering occurs before explicit overrides, whether environment-authored values can bypass higher constraints, and whether every shell path consumes the same effective policy.
Filtering inherited variables and adding explicit values are different capabilities. A filter can prevent accidental leakage from the host process, but it does not constrain values deliberately inserted by the policy. Explicit values therefore need provenance and authority: who created them, why they may enter this environment, how long they live, and where they may be logged.
Every integration that launches a subprocess should declare its policy source. Regular shell, user-shell, and unified-exec have evidence of shared ownership here. The current material does not establish whether MCP servers, hooks, or other integrations use the same boundary. Missing coverage should remain an explicit unknown rather than being inferred from the three demonstrated paths.
Durable work also needs policy identity
Determinism tells us which value wins now. Resumable or replayable work must also establish whether the restored policy is semantically the same as the one present at pause. A stable environment name does not prove that inheritance rules, explicit values, or higher-level policy remained unchanged.
A stronger recovery contract gives the effective environment policy a stable identity or fingerprint. A checkpoint records it; on resume, a changed fingerprint can require re-admission, explicit acceptance of drift, or a recorded low-risk continuation. The correct response depends on workload risk. Policy fingerprinting is an architectural recommendation from the Research Object, not behavior established by the selected code.
Debug redaction is not a confidentiality guarantee
The Debug representation of EnvironmentConfig redacts the policy, acknowledging that the object may contain sensitive explicit values. This protects one observability surface. It does not establish that secrets cannot appear in command output, error messages, subprocess logs, telemetry, or downstream tools.
Environment-owned policy likewise addresses configuration ownership and scope mismatch, not complete process isolation. The evidence comes from one implementation and its tests, not an independent isolation benchmark, and it does not prove universal subprocess coverage.
The bounded design rule is therefore not “put policy in EnvironmentConfig and isolation follows.” It is: bind execution-scoped configuration to the environment that actually owns the work; make fallback, precedence, and provenance explicit; add policy identity for durable recovery; and use separate controls for secrets in storage, logs, output, and downstream processes. Aligned configuration authority is a necessary part of reliable execution, not a complete security model.