Coding OS
Sign in
All posts

2 min read

Codex at full hook parity: what changed

adapterscodexrelease

Until recently, our adapter support matrix had an honest asymmetry: Claude Code got every hook; Codex got Bash-event hooks only. Write/Edit-level gates — the heart of Coding OS enforcement — couldn't fire there, so protected work effectively meant Claude Code.

As of the 2026-08 adapter refresh, that asymmetry is gone: the Codex adapter now runs at full hook parity.

What "full parity" means concretely

Parity is about equivalent kernel outcomes, not identical provider APIs. On Codex (CLI and app, via the codex adapter):

  • File-edit hooks fire. Codex applies changes through apply_patch; the adapter translates those into the same edit events Claude Code produces, so the complexity gate, skill enforcement, and doc-anchor checks now block undisciplined edits on Codex too.
  • Bash hooks were already native — git guards, dangerous-command blocks, commit-message enforcement.
  • MCP tool hooks match on tool names, so board-integrity rules (no hand-editing task state) hold.
  • Prompt-context injection works via the same UserPromptSubmit surface — session banners, recovery context, and reminders arrive identically.
  • Compact and subagent lifecycle events are covered, so long sessions keep their memory hygiene.

Two niche gaps remain, documented rather than papered over: Codex has no equivalent of a tool-failure hook (we observe error items instead), and non-managed hooks require a one-time trust review — a Codex platform property, and arguably a good one. Neither affects the core gates.

Why this was the hard kind of work

The adapter layer's contract is that the kernel never lies about enforcement. Every adapter declares which events its runtime can intercept, and the renderer emits only what the runtime can actually enforce. Getting Codex to parity meant runtime-identity plumbing (Codex Desktop doesn't guarantee env variables in every hook subprocess), payload translation for the patch format, and re-verifying the whole enforcement chain end to end — then updating every public claim to match, from the adapters matrix to llms.txt.

That last part matters as much as the code. A support matrix that overclaims is worse than a narrow one: teams route protected work based on it.

What to do with this

If your team was split between Claude Code and Codex, the capability question is now settled — pick per preference, not per enforcement:

uv tool install coding-os
cos init   # choose claude, codex, or both

The full capability table, including the two documented gaps, lives in Adapters & support. And if there's another runtime you want at this level, the adapter vote is open — adapter priority follows demand.

Codex at full hook parity: what changed · Coding OS