Claude Hooks as Deterministic Enforcement

Hooks are deterministic code callbacks in the agent loop / Claude Code (PreToolUse, PostToolUse, stop hooks, and others). Because they are code rather than model output, they run every time, regardless of what the model decides -- which is exactly why they are the right place to enforce a hard rule.

What Hooks Enforce

• Block destructive commands -- e.g., deny rm -rf, refuse writes outside an allowed path
• Require human approval before a sensitive tool runs
• Redact or validate tool arguments and outputs
• Gate completion on a passing test/build -- a Stop Hook used as a verification gate

Why Hooks Beat Prompts for Hard Rules

A prompt instruction is probabilistic: the model usually follows it, but "usually" is not a guarantee, and a sufficiently adversarial input (or an ordinary model mistake) can override it. A hook is deterministic: the code either denies the tool call or it doesn't, independent of the model's reasoning that turn. This is why hooks appear as *the* answer whenever an exam item asks how to "prevent destructive actions" or enforce a rule that must never be broken.

Worked Example

Where should a rule that blocks a destructive shell command be enforced? In a PreToolUse hook / permission rule that deterministically denies it -- not in the system prompt, not by lowering temperature, and not by asking the model to be careful. Hooks are deterministic code; prompts are probabilistic and can be overridden.

Common exam traps

• Confusing "a strongly worded system prompt" with an enforceable rule. Only code that runs on every call -- a hook or permission rule -- is enforceable in the deterministic sense the exam is testing for.
• Assuming hooks are only about blocking. They also cover validating/redacting arguments and outputs, and gating task completion on objective criteria like a passing build.