The control plane of an agent used to be easy to imagine as a settings screen: pick a model, choose an approval mode, select a sandbox, start working. This week's code is less tidy. It suggests that real agent control has to travel with the work.
For builders, operators, and teams evaluating agent tools, that is the practical question. When a session resumes, a model changes, a subagent starts, or a tool worker thread runs code on the user's behalf, does the same control contract come along, or does it quietly fall back to whatever that layer happens to know?
Yesterday's edition followed machine boundaries: workspace roots, denied reads, Docker persistence, and cleanup rules. The day before followed the visible control room. Today's evidence sits between those layers. It is about the data structures that let an agent remember what kind of control room it is supposed to be in.
Codex stores the permission profile, not just the old sandbox label
OpenAI Codex commit a1ecf0cf is blunt about the problem. The older SandboxPolicy shape remained in thread-store APIs, which kept consumers tied to a legacy representation and prevented richer permission-profile data from round-tripping through thread metadata.
The change replaces thread-store sandbox policy fields with canonical PermissionProfile fields. It also persists permission-profile metadata as canonical JSON while continuing to read older legacy sandbox values. Local storage, in-memory storage, live metadata sync, and rollout extraction paths are updated to propagate TurnContextItem::permission_profile().
That matters because a permission profile is not just a label for a prompt. It is part of the session's operating contract. If a thread is listed, reopened, reconciled from rollout data, or summarized from stored state, the permissions need to be recoverable as the same kind of object the runtime uses.
The model's tool mode becomes turn state
Another Codex commit, 5577a9e1, moves a different control decision into the turn. The commit adds optional model metadata for tool mode: direct, code_mode, and code_mode_only. If that metadata is missing or unknown, the client falls back to existing feature flags.
The key implementation detail is where the resolved value lands. Codex carries the resolved ToolMode directly on TurnContext, outside the static config object, and uses it for turn creation, model switches, review turns, tool planning, and code execution.
The public consequence is subtle but important. Tool behavior is not merely a global preference once the agent is running. It can be model-specific, it can change when the model changes, and it has to be available to the runtime paths that decide what tools the model will actually get.
Subagents get lineage in the outbound metadata
Codex commit fc9cf62e adds another kind of control memory: lineage. The commit says forked_from_thread_id was already available to trace where a thread's context came from, but Codex also needed to know which parent thread spawned a subagent and what kind of subagent it was.
The patch adds parent_thread_id and subagent_kind to the x-codex-turn-metadata header sent to the Responses API. It also restores persisted session and thread source from resumed session metadata, so cold-resumed subagent threads keep lineage on later API requests.
This is not a claim that subagents are solved. It is a narrower claim: delegation is easier to reason about when the child carries explicit parentage instead of relying on an observer to infer it from history.
The labels have to match the control state
The UI side is smaller but still relevant. Codex commit 1333f4a6 aligns TUI permission labels with the app. The changed files touch config persistence, permission popups, permission menus, status surfaces, tests, and snapshots.
That is the user-facing half of the same problem. If the runtime stores richer permission profiles but the terminal and app use different language, the human is left comparing surfaces instead of reviewing one control model. Naming is not the whole trust layer, but mismatched names are where trust starts to leak.
Hermes shows the boundary from the worker-thread side
NousResearch Hermes Agent has a different architecture, but two fresh commits point in the same direction. Commit 10839772 restores approval context in execute_code RPC threads. The commit says local Unix-domain-socket and remote file-RPC threads are wrapped with context propagation so gateway sessions do not fall into a non-interactive auto-approve branch.
The same change adds a guard for execute_code itself: a fail-closed approval check for the whole script before the child process starts. It also narrows environment passthrough by dropping broad HERMES_ forwarding in favor of an explicit allowlist and additional secret substrings.
That is the thread-level version of the story. A worker thread that executes code is not outside the control plane just because it is one layer down. If it can call tools or run commands for the agent, it needs the same approval context the user thought they were operating under.
Implicit auth fallback is getting less comfortable
Hermes commit 41ff6e59 tightens a separate boundary: auth fallback. Its title says the legacy Nous session-key fallback is disabled. The patch changes auth, credential pool, runtime provider, proxy adapter, web server, and tests.
The article should not overstate that as a universal security fix. The grounded point is narrower: another implicit control path is being removed from the normal flow. In an agent runtime, credentials are part of the same control story as permissions and approvals. Silent fallback behavior may be convenient, but it also makes the active contract harder to inspect.
The settings panel is becoming a runtime record
Taken together, these commits do not prove a shared standard. They do not prove complete safety. They do not even prove that every user can see these controls clearly today.
They do show the same engineering pressure from multiple angles. Permission profiles have to persist. Model tool behavior has to be resolved for the turn that is actually running. Subagents need lineage. Worker threads need approval context. Auth fallback behavior has to be explicit enough that the runtime can explain what path it used.
That is the next trust layer for agent tooling. The question is no longer only "what is the agent allowed to do?" It is "where is that answer stored, and does it survive the next boundary?"