Research investigation R0920 / claim audit

Can Codex Hook Policies See the Tool Calls They Claim to Govern?

The checked source supports a bounded finding: hooks cover most enumerated static built-in handler types, but selective exclusions and hosted paths mean they are not a complete action-governance boundary.

Archived snapshotv1Sep 20, 2026
Verified observations
4

4 measured fields

Supported claims
8

8 material findings

Cited sources
7

6 primary or authoritative

Research score
85

Automated topic and evidence score

Interactive figureCan Codex Hook Policies See the Tool Calls They...
CSV JSON
Data status88.235 verified records across 1 period

Snapshot only. There is not enough history to claim a trend yet.

Verified observationHover or focus any mark for exact valuesLast updated Sep 20, 2026

Version ledger

Frozen public editions

Each edition preserves the records, method, sources, and downloads available at publication time.

  1. v1 / latestSep 20, 20264 records / 7 sources

    Initial public snapshot with 4 records and 7 cited sources.

Coverage note

The matrix is a handler-type capability audit, not a measure of tools enabled in one deployment, successful hook execution in every product surface, or end-to-end policy effectiveness. V1 and V2 agent handlers are mutually exclusive at runtime.

Dataset ID
spd:can-codex-hook-policies-see-the-tool-calls-they-claim-to-govern-8a8262f1
Stable URL
/research/can-codex-hook-policies-see-the-tool-calls-they-claim-to-govern-8a8262f1
Version
v1
Coverage
2026-09-20
Records
4
Fields
7
Updated

Read the data

The records behind the figure

CSV JSON
Can Codex Hook Policies See the Tool Calls They Claim to Govern? data records
EntityMetricValueUnitObservedSourceTransform
Codex static built-in CoreToolRuntime typesboth_pre_and_post_hook_capable30 of 34 (88.2%)percent2026-09-20https://github.com/openai/codex/blob/main/codex-rs/core/src/tools/registry.rsCounted handlers capable of emitting both payloads; divided 30 by 34 and multiplied by 100.
Codex static built-in CoreToolRuntime typeshandlers_enumerated34handler_types2026-09-20https://github.com/openai/codex/blob/main/codex-rs/core/src/tools/spec_plan.rsCounted unique static built-in handler types registered by spec_plan.rs, including both V1 and V2 orchestration variants and excluding external MCP, dynamic, extension and hosted tools.
Codex static built-in CoreToolRuntime typespost_tool_hook_capable31 of 34 (91.2%)percent2026-09-20https://github.com/openai/codex/blob/main/codex-rs/core/src/tools/registry.rs(34 total handlers - 3 handlers without PostToolUse payloads) / 34 * 100.
Codex static built-in CoreToolRuntime typespre_tool_hook_capable30 of 34 (88.2%)percent2026-09-20https://github.com/openai/codex/blob/main/codex-rs/core/src/tools/registry.rs(34 total handlers - 4 handlers without PreToolUse payloads) / 34 * 100.

Measurement technique

How to read this report

  1. 01Evidence matrix plan: use the source-defined inventory of static built-in CoreToolRuntime handler types as the denominator; exclude external MCP tools, dynamic tools, extension tools, and hosted WebSearch specifications.
  2. 02Classify each handler by source-level capability to emit PreToolUse, emit PostToolUse, and accept pre-hook argument rewriting.
  3. 03Separate local registry-dispatched function tools from specialized control surfaces and hosted tool specifications.
  4. 04Preserve the September 20, 2026 cutoff and treat the recovered main-branch snapshot as a bounded source review, not a new collection or execution.
  5. 05Compare the implementation boundary with official hooks documentation, while keeping Desktop- or plugin-owned paths distinct from registry-path capability.
Next report / 01AI Model Economics Index All research reports
YOUR READING SPACE

Notifications