A fresh Codex commit gives a specific answer to a hard remote-environment question: when an agent works in more than one place, whose authority follows the work? A selected, ready environment can carry its own permission profile instead of silently inheriting the profile of the thread that selected it.
The useful part is not the new field name. It is the test that accompanies it. Codex creates a thread that can write in its workspace, attaches an environment marked read-only, asks it to write a marker file, and requires the result to say WRITE_DENIED; the file must not exist afterward. That is a small source-level experiment with a large operational implication: an environment boundary can be stricter than the conversation around it.
The permission belongs to the attachment
Codex distinguishes a selection that comes from the thread from one that arrives ready with its own configuration. The former follows thread settings. The latter supplies the complete attachment configuration used for execution and capability-root selection. A companion follow-up change matters because it preserves that ownership: later edits to thread settings may refresh thread-owned attachments, but should not overwrite a ready attachment’s read-only profile or capability roots.
That sequencing is the story’s real challenge to the first, too-broad security angle. This is not a proclamation that every Codex environment is safe, nor a new release promise. It is an implementation contract for one situation in a system that can select environments, reconnect them, and update a thread while it runs. The public source says where the boundary is supposed to hold; it does not settle everything on the other side of it.
Test the narrower place, then change the larger setting
For an operator, the check is now concrete. In a disposable workspace, start a write-capable thread, select one read-only environment, and try one harmless file write there. Then change the thread’s settings and repeat the attempt. The selected environment should keep refusing the write. That test is more useful than asking whether a product has “permissions”: it checks whether the stricter place retains its own authority when the broader session changes.
These are main-branch code and tests, not proof of a shipped client, production enforcement, or an independent security review. The next meaningful signal is integration coverage for reconnects, attachment replacement, child threads, capability roots, credentials, and network policy. If a documented selected read-only environment can write through one of those paths, this clean boundary will need a much messier headline.