The short version: Gemini CLI now gives each local subagent its own tool, prompt, and resource registries, and even discovers inline MCP servers into that private scope. Codex, meanwhile, now lets exec-policy approvals made in a spawned subagent propagate back to the parent flow by default when both threads share the same permissions profile.
That sounds like plumbing. It is plumbing. But it is also philosophy. Gemini is drawing a harder line around capabilities. Codex is drawing a smoother line around trust.
Gemini’s move: make each subagent feel like its own room
In packages/core/src/agents/local-executor.ts, Gemini’s new local executor does something that matters more than the PR title first suggests. It does not just tag a child agent and move on. It builds the child a private little runtime.
The code now creates a fresh ToolRegistry, PromptRegistry, and ResourceRegistry for each subagent, then derives a subagent-specific message bus. After that, tools from the parent registry are cloned onto the child’s bus before registration. Inline MCP servers are also discovered directly into the child’s isolated registries.
The important shift is not “subagents can use tools.” They already could. The shift is that Gemini is getting serious about which instance of a tool a subagent is actually touching, and which context that tool is wired to.
That theme continues in packages/core/src/agents/agent-scheduler.ts. Instead of proxying the global config and pretending the child has different tools, the scheduler now builds an explicit context object with the agent-specific registries and message bus. In plain English: less hand-wavy inheritance, more real isolation.
Codex’s move: let trust follow the thread family
Codex went the other direction — not looser, exactly, but more continuous. The fresh change in fix(subagents) share execpolicy by default is about approvals and policy memory.
In codex-rs/core/src/exec_policy.rs, the new child_uses_parent_exec_policy() helper checks whether parent and child share the same exec-policy config folders and requirements. Then, in codex-rs/core/src/agent/control.rs, spawned threads inherit exec policy alongside shell snapshot state.
The killer proof is in the test suite. In codex-rs/core/tests/suite/approvals.rs, the new multi-thread test walks through a spawned subagent getting an exec approval, persisting the amendment, and then the parent rerunning the same command without seeing another approval prompt.
This is a workflow change disguised as a permissions tweak. Codex is saying: if a child agent earned a durable trust decision under the same profile, the parent should not have to re-litigate it.
Same problem space, opposite pressure points
This is what makes the pair interesting. Both teams are working on subagents. Both are clearly past the “cool demo” phase. But they are hardening different boundaries.
- Gemini: isolate the child’s capabilities, registries, and MCP-discovered tools so execution is more deterministic and less leaky.
- Codex: propagate durable approval state across related threads so real multi-agent work stops asking the same permission question twice.
That is a real split in product instinct. One says the child should feel more self-contained. The other says the family should feel more coordinated.
Why this matters beyond the terminal
Agent UX is hitting a familiar platform moment: the magic stops scaling unless boundaries become explicit. Once you have multiple agents, tool state, MCP servers, shell state, approval state, and thread forking, the fuzzy middle gets expensive fast.
Gemini’s answer is sharper isolation. Codex’s answer is lower-friction continuity. Both are valid. Both come with trade-offs.
Sharper isolation can reduce spooky-action-at-a-distance bugs, but it can also make shared context harder unless the handoff points are well designed. Trust propagation can kill repetitive approvals, but it also means the permissions profile itself becomes a much bigger design object. Get that profile wrong, and convenience becomes blast radius.
Crisp takeaway: subagents are no longer just “the model called another model.” They are becoming first-class runtime entities with opinions about scope, trust, and inheritance. Gemini is strengthening the walls. Codex is strengthening the hallway.
The interesting question now is not which approach is “better.” It is which layer of boundary-setting matters most for the next wave of agent tooling: isolated capabilities, or shared trust?
If more coding agents start mixing both, the winners may be the tools that make those boundaries visible instead of burying them in hidden runtime state.
Send a note to the desk
Corrections, missing context, or a follow-up lead.