RuleReceipt vs Claude Code hooks

A PreToolUse hook can stop the action before it happens

You can wire a hook to inspect a tool call and return permissionDecision: "deny" — and the call never runs. That is real, in-flight prevention. For a specific, well-defined danger (“never let rm -rf touch this path”), a hook is the right tool, and it beats a checker that only tells you afterwards.

RuleReceipt is post-hoc by design: it reads the transcript after the session and reports. It does not make the model obey, and it can’t un-run a command. If prevention of one known action is your whole problem, use a hook — you may not need us at all.

A stalled hook doesn’t block — it fails open

“A timed-out command, http, or mcp_tool hook doesn’t block the tool call. The call continues through the normal permission flow, so don’t count on a stalled hook to act as a gate.” Claude Code docs · Hooks · PreToolUse

The default timeout for those hook types is 600 seconds. If your check hangs — a slow subprocess, a network call, a wedged script — it is discarded and the action proceeds. The gate you were relying on quietly isn’t there.

Silence is not approval — but it isn’t denial either

“The hook can deny the call, but staying silent doesn’t approve it.” Claude Code docs · Hooks · How a hook resolves

A hook that exits cleanly with no decision hands the call back to the normal permission flow. That’s sensible — but it means a hook only stops what you explicitly told it to deny. Anything you didn’t anticipate isn’t caught by the hook; it falls through to whatever the permission settings allow.

A hook guards the actions you listed; your rules are broader than that

Hooks match on tool calls — a command pattern, a file path, a tool name. Most CLAUDE.md rules aren’t shaped like that: “update the changelog before finishing,” “don’t weaken a threshold without saying so,” “surface bad news first.” You can’t write a PreToolUse matcher for most of what you actually wrote down. A hook can’t verify a rule it can’t express as a tool-call pattern.

Every rule, checked against what actually happened

After the session, RuleReceipt reads the transcript and goes rule by rule through your CLAUDE.md / AGENTS.md: followed, broken, or can’t-tell — each with the exact quoted line from the session as evidence. It covers the rules a hook can’t express, and it catches the case where the hook was meant to fire but failed open.

We’re honest about the ceiling: this is detection and reporting, after the fact. It does not prevent, and it does not make the model comply. There is one narrow exception — an optional guard hook that blocks a small, specific set of file and branch actions. That’s a deliberately limited guard, not a general enforcement layer, and we won’t describe it as one.

The honest summary

• Use hooks to prevent specific, known-dangerous actions in-flight. Nothing here replaces that.
• Use RuleReceipt to verify, after the session, that every rule you wrote was actually followed — including the ones no hook could match, and the times a gate failed open.
• They stack. The gate stops what it can; the receipt tells you what got through.