ChaseInTech Digest
Claude Code and Codex Are Quietly Becoming Agent Control Planes
Recent releases add model-switch hooks, restricted execution, spend visibility, MCP result interception and tighter subagent accounting. The coding agent is becoming a governed runtime.

Coding agents are no longer just models wrapped in a terminal. Their release notes now read like the beginnings of an operating system for delegated work: policy hooks, restricted modes, spend visibility, subagent supervision, tool-result inspection and recovery controls.
I use these systems enough to care less about the feature headline than the authority behind it. A model can be excellent at code and still be unsafe to leave unattended if I cannot answer basic questions about the run.
Which model executed the task? What tools could it reach? Did a subagent inherit the same permissions? Could a project file silently change the operating rules? What happened after a tool returned data? How much did the whole task tree spend? Could I stop it and reconstruct what it had already done?
The latest Claude Code and Codex releases are interesting because both products are starting to expose answers.
Claude Code adds policy around model changes
Claude Code v2.1.251 added PreModelSwitch and PostModelSwitch hook events. The release notes say these hooks can block, confirm or annotate a model switch.[1]
That sounds small until a session can move between models with different prices, capabilities, context state or policy requirements. A model change is an operating event. It can alter how the next action is produced.
A useful pre-switch hook can check which model the session wants to use, why the change is happening, what state will be carried forward and whether the new route is allowed for that task. A post-switch hook can record what changed and attach the decision to the run.
The hook does not prove that the switch is safe. It gives an operator somewhere to enforce policy.
Claude Code also added per-session prompt-cache information and spend-limit visibility for developers using a Claude apps gateway with those limits. These additions make cost less mysterious, especially in long sessions where cache misses and re-caching can change the shape of the bill.[1]
Cost visibility is not the same as cost control, but invisible spending cannot be governed at all.
Restricted mode changes the default authority
Claude Code v2.1.248 introduced a restricted mode. In that mode, command and code-execution tools, WebFetch and broad file permissions are removed by default. The release also says bypass-permission mode is refused while restricted mode is active.[2]
That is a more important design choice than another convenience command.
Most agent incidents do not begin with a dramatic exploit. They begin with a tool that was available because nobody removed it. A coding task that only needs repository reading and a narrow edit should not automatically inherit shell execution, unrestricted network access and every writable path on the machine.
Restricted mode moves the starting point. The operator has to add authority instead of remembering to subtract it.
This is still configuration, not a guarantee. Teams can choose a broader profile, allow the wrong path or misunderstand what a plugin can do. But the product now exposes a clearer least-authority lane.
The filesystem fixes show why policy must survive runtime changes
The same Claude Code release fixed file tools following a symlink that had been swapped inside the working directory after the permission check. It also fixed plugin commands declared in a marketplace entry being able to point outside the plugin directory.[1]
These fixes are a reminder that checking a path once is not enough. The resource used at execution time must still be the resource that was approved.
An agent can ask permission for a path that appears safe, then reach somewhere else if the path changes before the operation. A plugin can look contained in its manifest and still escape that boundary if the resolved command points outside it.
A real control plane has to govern the resolved runtime object rather than trusting the earlier string that named it.
Codex is exposing coordination and interception points
Codex 0.150.0 added task-to-task coordination primitives and interrupt handling.[3] Codex 0.151.0 followed with changes around MCP tool results, sandbox behavior, permission state and nested subagent accounting.[4]
The MCP result interception point is particularly useful.
Tool governance is often described as deciding whether an agent may call a tool. That is only half the path. The result can also contain hostile instructions, malformed records, secrets, unexpected links or data that should not be allowed into the next reasoning step unchanged.
A control plane needs somewhere to inspect, redact, reject, replace or annotate the result before the agent treats it as trusted context.
This matters even when the tool itself is legitimate. A browser, issue tracker, documentation server or repository search can return untrusted content. Permission to call the tool does not make every returned byte safe.
Subagent budgets need one root contract
Codex 0.151.0 also tightened accounting for nested subagents so descendants can remain under a root token budget.[4]
Without that relationship, a parent agent can appear bounded while repeatedly spawning work underneath it. The top-level session stays within its own apparent limit, but the full task tree does not.
The same problem applies to time, API spend, tool calls and side effects. A parent task should not escape a limit by delegating the expensive part.
I want one task contract at the root:
- maximum model and API spend;
- maximum elapsed time;
- maximum subagent depth and count;
- allowed tools and paths;
- actions that require fresh human approval;
- evidence required before the run can close.
Every child should inherit that contract unless the operator explicitly narrows or extends it. A child must not be able to grant itself more authority than the parent had.
Streaming is useful, but background work still needs receipts
Claude Code v2.1.251 added live streaming of a foreground subagent’s tool calls and results to Remote Control clients. The release notes distinguish this from background subagents, which still show status rather than the same live detail.[1]
That distinction matters.
Foreground visibility helps an operator understand a task while it is happening. Background agents create a different requirement. If the system cannot show every step live, it needs durable receipts after the fact.
A status such as “completed” is not enough. I need the task input, model route, tool calls, files changed, commands run, external effects, test results, approval events and final output. If the work failed, I also need to know what state survived.
Live observation and replayable evidence solve different problems. Mature agent systems need both.
This is not a benchmark contest
Nothing in these release notes proves that Claude Code or Codex writes better software. It does not establish that either sandbox is complete, that every plugin is safe or that a nested task always stays inside the intended boundary.
The releases do show where the products are investing.
They are adding policy seams around model routing. They are making authority profiles explicit. They are exposing cost and cache state. They are providing more control over coordination and tool results. They are repairing gaps where an approved path could become a different runtime resource.
That is control-plane work.
The model still matters. So do the prompt, repository, tests and human reviewer. But once a coding agent can coordinate tasks and execute tools, the surrounding control system decides whether that intelligence can be used repeatedly without turning every run into a trust exercise.
What I will measure next
I do not want to judge these controls from release notes alone.
The practical test is a bounded repository task run under both systems with the same contract. I would record:
- which policy decisions are visible before execution;
- how model changes are represented;
- whether child tasks inherit limits;
- what tool results can be inspected before reuse;
- how filesystem boundaries behave under path changes;
- what evidence remains after interruption or failure;
- how much human time is required to reconstruct the run.
That test would not declare a universal winner. It would show which control surfaces are usable, which are only configurable and which still rely on operator discipline.
Coding agents are getting more capable. The more important change is that their authority is finally becoming something we can inspect and shape.
Sources
[1] https://github.com/anthropics/claude-code/releases/tag/v2.1.251 - Claude Code v2.1.251 release notes [2] https://github.com/anthropics/claude-code/releases/tag/v2.1.248 - Claude Code v2.1.248 release notes [3] https://github.com/openai/codex/releases/tag/rust-v0.150.0 - Codex 0.150.0 release notes [4] https://github.com/openai/codex/releases/tag/rust-v0.151.0 - Codex 0.151.0 release notes