Before the Prompt Lands: Codex and Gemini Turn Hooks Into Agent Control Planes

Published 2026-03-20 · Grounded in Codex commit 6fef4216546c, Gemini CLI hook docs and core client code, live GitHub repo metadata, and fresh GSIO coverage data.

This is pre-turn middleware, not a cosmetic extension

There is a familiar pattern here if you squint: web middleware before a request handler, Git hooks before a commit, CI gates before a merge. Agent CLIs are now building the same idea around prompts.

Gemini’s own docs say it plainly. Hooks run synchronously inside the agent loop, and BeforeAgent fires after user submits prompt, before planning. Common use cases: add context, validate prompts, block turns.

Codex’s new hook lands in the same neighborhood. Its UserPromptSubmit flow serializes a dedicated hook input with the session id, turn id, working directory, transcript path, model, permission mode, and prompt. That is not a log event. That is a deliberate interception point.

Codex’s tell: the prompt is inspected before it is really accepted

The sharpest Codex evidence lives in the runtime path around pending input.

In codex-rs/core/src/state/turn.rs, turn state explicitly buffers pending_input. Then in hook_runtime.rs, inspect_pending_input() runs UserPromptSubmit against user messages before record_pending_input() commits them into the turn.

That detail matters. Codex is not just letting hooks comment on a prompt after the fact. It is evaluating the prompt while it is still buffered and deciding whether it becomes part of the conversation at all.

The hook output parser in user_prompt_submit.rs makes the feature feel broader than a simple blocklist. A hook can stop processing, issue a block with a reason, or attach extra context for the model. Even plain-text stdout can become additional context.

And when Codex accepts that extra context, it does not tack it on as a side note. It converts it into DeveloperInstructions. In other words, hook output can climb straight into the agent’s instruction stack.

Gemini’s tell: the hook system is broader and more explicit

Gemini’s hook surface is less new, but it is more openly formalized.

In packages/core/src/core/client.ts, fireBeforeAgentHookSafe() deduplicates hook execution once per prompt_id. The hook can stop execution, block execution, or return additionalContext. Then, right before the turn proceeds, Gemini appends that material into the request as <hook_context>...</hook_context>.

That makes Gemini’s model-facing contract easier to see. The hook layer is not hidden infrastructure. It is a sanctioned way to reshape the request before planning begins.

One subtle but important detail: Gemini tests explicitly sanitize hook-provided context by escaping < and </hook_context>. That does not make the system magically safe, but it does show the team is thinking about delimiter abuse at the boundary where hook output becomes model input.

Same architectural direction, different breadth

The tempting headline would be that Codex and Gemini now do the same thing. That would be sloppy.

• Codex: newly adds a narrower prompt-submission interception point with runtime-visible pending input and promotion of hook context into developer instructions.
• Gemini: already exposes a broader lifecycle hook framework around the whole agent loop, with a clearly documented BeforeAgent stage and adjacent before/after model and tool events.

The better framing is this: both projects are moving control earlier. They are hardening the space before planning, before tool selection, and in some cases before history is finalized.

Why this matters now

This is not an archaeological story dug out of stale branches. Both repos are moving fast right now. As of this morning, GitHub shows Codex updated at 2026-03-20T05:01:45Z and Gemini CLI at 2026-03-20T04:45:10Z. Recent merged work on both sides keeps circling runtime governance: hooks, plugin sync, exec capture, MCP installs, plan policies, ACP metadata.

GSIO’s current project scope report adds another confidence check: both repositories are fully analyzed with fresh syncs from today. So this is not a fuzzy vibes story. It is a current implementation trend visible in live source, live metadata, and live repo activity.

If prompt submission becomes a programmable control surface, who should really own it: repo authors, platform teams, or end users building personal agent rituals?

If you are building agent tooling, inspect your own loop closely. The most important design choice might not be the model or the tools. It might be the thin slice of code that decides what a prompt becomes before the model ever sees it.