- In short
- A PreToolUse hook is a shell command Claude Code runs before a tool executes. It inspects the proposed call and can allow it, deny it, or rewrite its arguments, which makes it the mechanism for enforcing business rules the model is not free to ignore.
What interception means at the PreToolUse stage
When a model decides to use a tool, it does not run the function itself; it emits a request that your environment fulfils. A PreToolUse hook sits squarely in that gap. Before Claude Code actually executes the requested call, it runs your shell command with the tool name and the proposed arguments, and your command returns a verdict. That verdict can let the call through, stop it cold, hand it to a human to approve, or quietly correct the arguments and continue.
Because it runs before anything happens, a PreToolUse hook is the lifecycle event you reach for whenever an action must be governed rather than merely tidied. This is the mirror image of a PostToolUse normalisation hook: one reshapes a result after the fact, the other decides whether the action is allowed in the first place. Getting that before-versus-after distinction right is the foundation of everything else in this task statement.
- PreToolUse hook
- A lifecycle handler that runs before a tool executes. It receives the tool name and proposed arguments and returns a decision, allow, deny, ask, or defer, and can supply updated arguments, giving deterministic control over whether and how an action happens.
How interception fits the agentic loop
To see why this event is so powerful, recall how a tool call actually happens. The model does not run functions; on a turn it emits a request to use a tool, and your environment is what fulfils that request. Between the model proposing the call and the environment executing it lies a gap, and the PreToolUse event is a handler the runtime invokes inside that gap. The model has expressed intent, but nothing has happened yet, which is precisely the window in which a decision can still change the outcome.
That position in the loop is what gives interception its authority. The model remains free to attempt whatever it judges useful, so the agent keeps its flexibility, but the environment gets the final say on what is permitted to run. You can think of it as a checkpoint stamped onto the request-response cycle: the proposal flows in, the hook adjudicates, and only an approved call proceeds to execution and back into the conversation. Understanding that the model and the runtime have distinct responsibilities here is the conceptual key to the whole knowledge point.
The decision surface a PreToolUse hook controls
The official hooks reference gives this event a precise vocabulary. Exiting with code 2 is a blocking error: the tool call is prevented and the message your script wrote to standard error is shown to the model. For finer control you exit cleanly and return a hookSpecificOutput object whose permissionDecision is one of four values. deny stops the call, allow approves it, ask escalates to a human prompt, and defer hands the choice back to the normal permission flow. A permissionDecisionReason explains the verdict, and an updatedInput field lets an approval rewrite the arguments on the way through.
The reliability guarantee is what makes this worth learning. A deny decision is enforced by the runtime, not negotiated with the model, so it holds even under a long conversation, an adversarial prompt, or a mode where ordinary permission prompts are skipped. That is the precise property a business rule needs: a single failure is unacceptable, so the rule cannot be something the model is merely encouraged to follow.
Blocking, escalating, and clamping
There are three shapes this enforcement usually takes. The bluntest is an outright block: a refund tool asked to move more money than policy permits is denied, and the model is told why so it can choose a compliant alternative. A softer shape is escalation, where instead of refusing you set ask so a human signs off on a sensitive operation before it proceeds. The most surgical shape is clamping, where you approve the call but use updatedInput to bring an out-of-bounds argument back inside policy, for example capping a batch size or stripping a disallowed flag.
Each shape keeps the decision in deterministic code rather than in the model's judgement. The model stays responsible for choosing what to attempt; the hook stays responsible for what is permitted. That division is why an interception hook composes so cleanly with the rest of an agent, and it is the same enforcement instinct behind prerequisite gate design, where a step is only allowed once its preconditions are provably met.
Reading the arguments to make a decision
A PreToolUse hook is only as good as the data it bases its verdict on, and that data is the proposed tool_input. The discipline here is to decide from the arguments themselves, not from anything the model claims in prose. If the rule is a spending cap, read the numeric amount from the arguments and compare it; if the rule is a forbidden target, parse the path or identifier and match it. Basing the decision on structured arguments rather than on the model's narration is what makes the enforcement trustworthy, because narration can be confident and wrong while the arguments are the actual request.
Defensive parsing matters too. Arguments can arrive missing, oddly typed, or shaped unexpectedly, and a hook that throws on a surprise is a hook that fails open or disrupts the agent. A robust interception hook treats an unparseable or ambiguous request as a reason to deny or escalate rather than to wave through, so the safe default is the conservative one. That fail-safe stance is a small habit with a large payoff: it ensures the rare malformed call lands on the protective side of the decision rather than slipping past the check.
Why prompts cannot do this job
The exam trap for this knowledge point is relying on prompt instructions to enforce a financial threshold instead of using a hook. A prompt that says never issue a refund above five hundred dollars is guidance the model interprets, and interpretation can drift: a long thread dilutes the instruction, an unusual phrasing routes around it, or the model simply reasons its way to an exception. None of that is possible with a PreToolUse deny, because the rule is checked in code the model cannot argue with.
This is the practical heart of prompt-based versus programmatic enforcement. For preferences and soft style, a prompt is fine and cheaper. For a rule where one breach causes real loss, the enforcement has to be programmatic, and at the tool boundary that means a PreToolUse hook. Knowing which side of that line a requirement falls on is exactly the applied judgement Task Statement 1.5 is testing.
Worked example
A customer-support agent can issue refunds with an issue_refund tool, but company policy caps autonomous refunds at $500 and requires a manager for anything higher.
A frustrated customer pushes hard, and across a long conversation the model becomes persuaded that a $900 goodwill refund is justified. If the only safeguard were a sentence in the system prompt, the model might well comply, because it has reasoned itself into treating this as the exception the rule did not anticipate.
Instead you attach a PreToolUse hook to issue_refund. The hook reads the proposed amount from the arguments. For $500 or less it returns allow and the refund proceeds. For more, it returns a permissionDecision of ask, escalating to a manager, or deny with a reason that tells the model to offer the customer a smaller refund or a human callback. The $900 call never executes autonomously, no matter how convincing the conversation became.
The lesson is about where the guarantee lives. The model still drives the interaction and proposes the action, which is what keeps the agent flexible. The threshold, the one thing that absolutely must hold, lives in a hook that does not bend. Swap the refund cap for any hard limit, a deletion blast radius, an outbound spend, a production deploy, and the same interception pattern applies unchanged.
It is worth tracing what the model experiences when the hook denies the $900 call. It receives the rejection along with the reason you wrote, and that reason becomes part of its context for the next turn. A well-phrased denial therefore does double duty: it stops the action and it steers the model towards a compliant alternative, such as offering the customer a $500 refund now and a manager callback for the rest. The hook is not merely a wall; it is a wall with a sign that tells the agent where the door is, which keeps the interaction productive rather than stuck.
Common misreadings to avoid
Misconception
A strongly worded system prompt is enough to stop the agent from exceeding a financial threshold.
What's actually true
Misconception
Interception means catching the bad result after the tool has run and discarding it.
What's actually true
How it shows up on the exam
Within Domain 1 this knowledge point usually appears inside the customer support and developer productivity scenarios, where an agent has a tool capable of a costly or irreversible action. The question describes a threshold or approval requirement and asks how to enforce it reliably. The credited answer is a PreToolUse hook that denies or escalates the call; the distractors offer better prompts, post-hoc checks, or model-configuration tweaks that cannot give a guarantee.
A quick test settles most of these items: if the requirement is that something must never happen, or must happen only with approval, you need pre-execution interception. Pair that with the next step, the hooks versus prompts decision framework, and you can defend not just which hook to use but why a hook is required at all rather than a prompt. Watch, too, for distractors that propose detecting the violation after the fact and rolling it back; for a truly irreversible action there is no rollback, which is the whole reason interception has to happen before execution and not after.
An agent has a deploy_to_production tool. Policy says deploys are forbidden on Fridays and outside business hours, with no exceptions. The team currently relies on a CLAUDE.md instruction, but a Friday deploy still slipped through. What is the most reliable fix?
People also ask
What is a PreToolUse hook?
How do you block a tool call in Claude Code?
Can a PreToolUse hook modify tool input?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Useful hooks!
Why watch: Real examples that block or modify outgoing tool calls illustrate tool-call interception for enforcement.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.