PreToolUse hook enforcement

Definition

A PreToolUse hook runs before a tool executes and can block the call (shell hook exit code 2, or JSON permissionDecision: "deny"). It is the application-layer intercept used to hard-enforce policy that prompt text cannot guarantee.

Key points

• The exam's signature rule: for money movement and destructive operations (e.g. DB DELETE, process_refund, force-push), a PreToolUse hook is the only reliable enforcement. CLAUDE.md and system-prompt instructions are probabilistic and insufficient alone.
• Blocking mechanics: shell hook exit 2 → tool call prevented, stderr fed back to Claude; or JSON hookSpecificOutput.permissionDecision = "deny" (priority deny > defer > ask > allow — any deny blocks).
• Matcher targets the tool(s): exact (Bash), pipe-list (Edit|Write), or regex (^mcp__, mcp__server__.*).
• This is Zero-Tolerance Compliance in practice: validate at the application layer / hook, not by asking the model to behave.
• Distinct from PermissionRequest (fires at the permission dialog) — PreToolUse fires for every matching call regardless of permission mode.

Why it matters for the exam

Comes up repeatedly. When a scenario asks how to guarantee a financial/destructive action never fires incorrectly, the correct answer is a PreToolUse hook, never "add an instruction to CLAUDE.md/system prompt."

Common gotchas

• Choosing CLAUDE.md / system-prompt wording for hard enforcement = wrong answer (probabilistic).
• Exit code 0 with block intent does nothing — you must use exit 2 (or JSON deny).
• On exit 2, JSON on stdout is ignored; only stderr reaches Claude.

See also

• Zero-Tolerance Compliance
• Hook Types And Events
• Hook Exit Codes And JSON Output
• Permissions Merge And Deny Beats Allow
• Minimal footprint principle

Sources

• docs-tools-agents
• netlight-study-guide
• architects-playbook