Menu

#335 Codex host fails open when its own hook layer crashes: detect, document, contain

open
nobody
2026-08-11
2026-08-11
Anonymous
No

Originally created by: fu351

Live testing on 2026-08-09: in the interactive Codex CLI, the PreToolUse hook layer crashed with tree-sitter failed to allocate 3891494 bytes before Doberman ran. No AUTH was raised; the destructive command executed unmediated. tree-sitter is not a Doberman dependency (grepping every .py/.toml in the repo turns up zero references), so this is a crash in Codex's OWN hook infrastructure. Doberman's fail-closed guarantee (hookio.py denies on any internal exception) never got a chance to apply, because Doberman itself was never invoked.

This can't be fixed from inside doberman-core. A crashed host hook layer failing open is a property of the host, not something a policy engine downstream of it can intercept. What we can do is detect the condition and be honest about it.

Scope

  1. A doberman doctor canary that detects "the Codex hook is installed but not actually firing," distinct from the existing _check_codex_version (src/doberman/cli/doctor.py), which only checks install-state and CLI version, never whether the hook runs. Prior art for the pattern (manual today, not automated in doctor): adapters/codex/README.md's "Verify it's live" section (codex exec "read the file .env..." should be blocked) and adapters/openclaw/README.md's mandatory canary check. This needs a live codex subprocess call, so it probably wants to be an opt-in / slow-check tier, not part of the default doctor run.
  2. Document the containment limit honestly: a line in docs/PARITY.md or adapters/codex/README.md's "Honest limits" section stating that a host-hook-layer crash pre-empting Doberman is fail-open by necessity, a host property core cannot fix.
  3. Draft an upstream bug report for the Codex CLI project describing the exact crash text and repro shape, ready to file.

Not in scope: patching Codex itself.

Related

Tickets: #350

Discussion


Log in to post a comment.