Codex Hook Review Finds Four Built-In Paths Outside Pre-Execution Checks

Codex’s hook system can inspect most of the static built-in tool handlers in its current public core source before they run. But a bounded source review finds that four of 34 handlers do not emit PreToolUse payloads, leaving fresh pre-execution hook checks unavailable for write_stdin, tool_search, Code Mode execution and Code Mode wait controls. Hosted WebSearch sits outside the local hook system altogether.

That is not evidence that hooks are ineffective. It is a clearer map of what they govern. The dominant path is a locally dispatched function tool: Codex’s CoreToolRuntime supplies default pre- and post-hook payloads for that payload type and can rebuild an invocation after a pre-hook rewrites its input. The review found 30 of 34 static built-in handler types can use that pre-hook path, and 31 can emit a post-execution payload.

A strong default, with a defined perimeter

The denominator matters. The review counted 34 distinct static built-in CoreToolRuntime handler types in the public source at the September 20 cutoff. It excluded external MCP tools, dynamic tools, extension tools and hosted tool specifications. So these percentages describe a bounded core inventory, not every action that a particular Codex desktop, plugin, provider or configuration might expose.

The exceptions are not all the same kind of gap

The most consequential contrast is between a normal tool call and a specialized control surface. Code Mode’s outer execution handler receives a Custom payload containing raw JavaScript source, rather than the Function payload that triggers the runtime’s generic hook defaults. Its separate wait handler also opts out of both hook payloads because it controls an existing code cell rather than presenting a standalone action.

What falls outside a fresh pre-hook check

• write_stdin: It deliberately emits no new PreToolUse payload because it continues or polls an existing command. It can still produce a Bash post-hook payload when that original command finishes.
• tool_search: The discovery path has neither pre- nor post-tool hook coverage in the reviewed inventory.
• Code Mode: The outer JavaScript execution path and its wait or termination control do not emit the generic hook payloads.

These are narrower exceptions than an account of unrestricted tool activity would suggest. They are concentrated in transport, discovery and runtime-control paths. Meanwhile, several categories that might appear unusual—including update_plan, view_image, MCP resource operations and the native agent-orchestration handlers—use Function payloads in the current core source and inherit the generic pre-hook, post-hook and input-rewrite behavior.

A hosted lane follows a different route

Hosted WebSearch is a separate case, not merely another uncovered local handler. Codex appends it as a hosted model tool specification rather than sending it through the local registry dispatch path. That leaves it outside both PreToolUse and PostToolUse. A standalone extension-based web.run path can take the other route and receive generic function-tool hooks, so the boundary depends on how the capability is supplied.

The documentation supports the narrower reading

Codex’s official hooks documentation describes the system as an extensibility framework for actions such as logging, scanning prompts and validation. It also explicitly warns that hooks are a guardrail rather than a complete enforcement boundary, identifies hosted WebSearch as outside tool coverage, and notes that specialized paths can opt out. That framing aligns with the source-level result: broad protection for an important local pathway, not a promise that every possible action is mediated by one event.

There is also a reason not to overstate the review. It is a source-capability inventory, not an execution test. The reviewed main-branch snapshot had no recoverable commit hash, and it cannot establish that every desktop-owned, plugin-owned or provider-specific pathway reaches the core registry. A September 11 GitHub issue alleged that a Windows Desktop task-creation path bypassed disabled-tools settings and a trusted pre-hook, but that report remains unconfirmed in the supplied evidence.

What to watch next

The key question is whether Codex makes these boundaries easier to see and govern as its action surface expands. For users building policy around hooks, the immediate task is more basic: identify which tools use the local Function path, which rely on specialized controls, and which are hosted. A coverage percentage is useful only when paired with that map—and with the recognition that post-execution review cannot prevent an action that has already occurred.