Problem
runners/claude_code_acp.py and runners/codex_acp.py put fail_mode_discipline.02_fail_open_honored in declined_categories with the rationale "Claude Code's PreToolUse hook is fail-closed by design. Cannot honor a fail-open directive…". That premise is wrong, so the scenario is being declined (self-N/A) when it should be a pass.
Why the premise is wrong
- Claude Code hooks are fail-open by default — per the hooks docs, only a hook that exits code 2 blocks a
PreToolUse call; any other non-zero/error exit lets it proceed. Fail-closed is the hook author's opt-in (exit 2) or a narrow hook-timeout behavior, not a platform default.
- ACP's own hook returns allow-on-unreachable (
govern.mjs: if (!res) return { allowed: true, reason: "fail-open", decision: "allow" }).
- So under scenario
02_fail_open_honored (policy fail_mode: fail_open, gateway unreachable 60s), the hook lets the call proceed → matches the scenario's expected: tool_allowed. It should PASS.
Scope
- Applies to the hook runners only:
claude_code_acp.py, codex_acp.py.
- Not the proxy runner (
openai_agents_acp.py) — its decline is legitimate: an unreachable proxy raises a network error in the HTTP client, not a governance decision, so honoring fail_open there needs app-level handling. Keep that one.
Fix
- Remove the
fail_open_honored entry from declined_categories in the two hook runners (and the wrong rationale string).
- Re-run the two hook runners live (real Claude Code / Codex CLI + gateway fault-injection) to regenerate
results/claude-code-acp-*.json and results/codex-acp-*.json.
- Expected:
fail_mode_discipline 4/6 → 5/6; overall ~43 → 44/48 for each hook runner.
Why now (blog dependency)
The 2026-07-23 content fact-check corrected three live posts in agenticcontrolplane.com (branch fix/content-fact-check) — architecture-is-governance, decorator-proxy-hook-three-governance-patterns, full-scorecard-seven-frameworks-48-scenarios. They now state that fail_open_honored is a pass for the hook pattern and that "the scorecard is being regenerated." Regenerating the results here closes that loop; until then the published scorecard understates the hook runners by that one scenario.
Source: 2026-07-23 live-content fact-check audit.
Problem
runners/claude_code_acp.pyandrunners/codex_acp.pyputfail_mode_discipline.02_fail_open_honoredindeclined_categorieswith the rationale "Claude Code's PreToolUse hook is fail-closed by design. Cannot honor a fail-open directive…". That premise is wrong, so the scenario is being declined (self-N/A) when it should be a pass.Why the premise is wrong
PreToolUsecall; any other non-zero/error exit lets it proceed. Fail-closed is the hook author's opt-in (exit 2) or a narrow hook-timeout behavior, not a platform default.govern.mjs:if (!res) return { allowed: true, reason: "fail-open", decision: "allow" }).02_fail_open_honored(policyfail_mode: fail_open, gateway unreachable 60s), the hook lets the call proceed → matches the scenario'sexpected: tool_allowed. It should PASS.Scope
claude_code_acp.py,codex_acp.py.openai_agents_acp.py) — its decline is legitimate: an unreachable proxy raises a network error in the HTTP client, not a governance decision, so honoringfail_openthere needs app-level handling. Keep that one.Fix
fail_open_honoredentry fromdeclined_categoriesin the two hook runners (and the wrong rationale string).results/claude-code-acp-*.jsonandresults/codex-acp-*.json.fail_mode_discipline4/6 → 5/6; overall ~43 → 44/48 for each hook runner.Why now (blog dependency)
The 2026-07-23 content fact-check corrected three live posts in
agenticcontrolplane.com(branchfix/content-fact-check) —architecture-is-governance,decorator-proxy-hook-three-governance-patterns,full-scorecard-seven-frameworks-48-scenarios. They now state thatfail_open_honoredis a pass for the hook pattern and that "the scorecard is being regenerated." Regenerating the results here closes that loop; until then the published scorecard understates the hook runners by that one scenario.Source: 2026-07-23 live-content fact-check audit.