Codex forks it, Gemini threads it: execution context becomes first-class

There’s a point in every software wave where the glamour feature stops being the real story.

For terminal agents, that moment is landing now.

The flashy conversation is still about reasoning, tool use, autonomy, subagents, and all the usual sci-fi candy. But the more interesting code this week lives lower in the stack. It lives where the runtime decides what an agent actually inherits when it wakes up, what policy comes with it, what tools are wired into its loop, and how much of that state can survive a handoff.

The pattern I see in both Codex and Gemini CLI is this: execution context is turning from background plumbing into a first-class runtime object.

Codex: a fork now arrives with a visible inherited context

OpenAI’s codex repo has a small-looking PR with a big smell of inevitability: PR #15443, “core: snapshot fork startup context injection.”

On paper, this is “just” a test. In practice, it tells you exactly what the team thinks matters enough to freeze into a snapshot.

The new Rust test, fork_startup_context_then_first_turn_diff_snapshot(), creates a parent session, submits a seed turn, forks the thread, changes approval behavior at fork startup, then changes it again on the fork’s first turn while also entering plan mode. The captured snapshot for that first forked request is the revealing bit.

It does not show a blank child agent starting fresh. It shows inherited structure: permissions instructions, environment context, the parent’s user input, then a second developer block layering in the fork-specific approval change and collaboration-mode instructions before the new user input lands.

That sequence matters because it means the fork is not being treated like an empty shell plus a prompt. It is being treated like a continuation with baggage — deliberate baggage.

And PR #15443 is not isolated. gsio surfaces nearby Codex artifacts that rhyme with it:

• d3603ae5d38a: spawn a sub-agent by forking the parent thread’s rollout.
• c2e126f92ad5: inherit and reuse the parent session’s user-turn state.
• 84f4e7b39d17: inherit the parent thread’s exec policy on spawn and resume.

Put those together and the shape gets clear. Codex is teaching forks to carry runtime lineage, not just fresh instructions.

Gemini CLI: stop treating config as the whole world

Google’s gemini-cli is arriving at a similar destination from a different direction.

Commit de656f01d760, “Fully migrate packages/core to AgentLoopContext”, is one of those changes that looks boring until you read what it actually does. Gemini introduces an AgentLoopContext interface that explicitly carries the execution-scoped view of the world for a single turn or loop: config, promptId, toolRegistry, messageBus, and geminiClient.

That is a meaningful architectural sentence. It says the runtime no longer wants callers to reach into a giant ambient config object and figure things out ad hoc. It wants each loop to receive the specific operating context it should run with.

The code doubles down on that intention. Config now implements AgentLoopContext, but the direct getters for toolRegistry, messageBus, and geminiClient are marked deprecated with the same message: “Use the injected AgentLoopContext instead.”

This is not just a naming cleanup. It is a boundary cleanup.

And Gemini keeps threading that boundary outward. Commit 39d3b0e28c1a, “Partial threading of AgentLoopContext”, pushes the same execution-scoped pattern into ACP client and command execution. In other words: not only the core loop, but the machinery around it, is being taught to accept context as an explicit dependency.

Why this is bigger than “just refactoring”

If you only skim commit titles, this can look like ordinary cleanup work. It isn’t.

Agent systems break in exactly the places where context is fuzzy.

Which approval policy is live right now?

Which tool registry belongs to this loop?

Which message bus should hear this confirmation?

What state came from the parent, and what was changed for the child?

Those questions become painful the moment agents fork, resume, delegate, or run in parallel. If the answers live in ambient globals and half-implicit conventions, the runtime starts to feel like a haunted house. If they live in a concrete context object — or in a snapshot that makes inherited state inspectable — the system gets a lot easier to reason about.

The proof is already leaking into policy

You can see the payoff in nearby Gemini work too. Commit 4a3d9414ef75, “enable global session and persistent approval for web_fetch”, changes web_fetch so its policy update options return an empty object instead of URL-specific narrowing patterns, and removes it from the set of tools that require mandatory argument narrowing for persistent approval.

That’s a policy change, but it is also a runtime-confidence change. Systems only make approval more durable when they trust their execution boundaries more.

Codex shows the same instinct from the other side. In the fork snapshot, approval state is not hand-waved. It appears as part of the inherited and overridden context surrounding the forked request itself.

What both repos are really building

Here’s the simplest way to say it: these CLIs are moving from “the agent reads config and figures it out” to “the runtime hands the agent a complete operating envelope.”

• Codex is making inherited fork state visible, testable, and transportable.
• Gemini CLI is making loop state explicit, typed, and injectable.

Different implementation styles, same direction.

And that direction matters because multi-agent software does not mature when you add more cleverness alone. It matures when every spawned worker gets the right baggage, the right boundaries, and the right wiring — predictably.

The bigger pattern

For a while, the agent market has acted like the main question was: can the model use more tools?

I think the sharper question now is: what exact runtime does each tool-using agent step into?

That sounds less dramatic, but it is more durable. Once execution context becomes a real object, forks get cleaner, approvals travel more sanely, subagent behavior gets less improvised, and debugging stops relying on vibes.

So here’s the open question: if agent runtimes get much better at packaging and transporting execution context, does that make developers more willing to trust delegated work they cannot directly watch?

If you build agent tooling, this is the layer worth watching. The next leap may come not from a smarter answer, but from a runtime that knows exactly what state an agent should carry when it starts.