Claude Hooks
Claude Hooks is 1.0% of the CCDV-F blueprint, the smallest named sub-skill on it. It tests the mechanism: events, matchers, the three-way exit-status contract, and why a hook that runs after an action cannot prevent it.
Written by Kiran Manne
1% of the CCDV-F blueprint, which is roughly 1 question of 53. It sits inside Security and Safety, worth 8.1% in total.
Claude Hooks is the smallest named sub-skill anywhere in the CCDV-F blueprint at 1.0%. On a 53-question paper that is a single mark, and on some forms it may be none at all. Read this page once, understand the mechanism, and move on. Over-studying it is the most predictable way to lose time you needed elsewhere.
That single mark is cheap to secure, though, because hooks are a small mechanism with sharp edges. A hook is a command the harness runs at a defined moment in a session, configured in settings rather than requested by the model. It receives structured information about what is happening on standard input, and it answers through its exit status and what it writes to the output streams. Because the harness invokes it, the model has no say in whether it runs.
What makes it examinable is the exit-status contract. There are three outcomes rather than two, and the distinction between the blocking one and the merely failed one is exactly the sort of detail a certification enjoys. Add the difference between hooks firing before an action and those firing after it, and you have most of what a question can reasonably ask for.
What the exam tests here
- That hooks are configured in settings and executed by the harness, independent of the model's judgement
- The three-way exit-status contract, and specifically which status stops an operation
- Which lifecycle moments can prevent an operation and which can only react to one
- Matching a hook to particular tools rather than firing it on everything
- That a hook is arbitrary code with the user's privileges, making shared configuration a supply-chain concern
The shape of a hook
A hook binds an event to a command. The configuration names the lifecycle moment, optionally narrows it to particular tools with a matching pattern, and supplies a command line. When the moment arrives the harness executes that command, passes a structured payload describing the event on standard input, and interprets what comes back.
Two properties follow and both are examinable. The command runs whether or not the model would have wanted it to, which is the entire reason hooks exist as a control. And it runs on every event that matches, so a slow command behind a broad matcher taxes every tool call in the session. Narrow the matcher to the tools that genuinely need the behaviour, and keep the command quick.
Three exit statuses, not two
Zero is success and the operation proceeds. Status 2 specifically is a blocking failure: the operation is stopped and what the hook wrote to standard error is fed back to the model so it can adjust rather than simply losing the turn. Any other non-zero status is a non-blocking failure, where the user is told the hook had a problem and the operation goes ahead anyway.
That middle case is where a hook quietly stops enforcing anything. A script exiting 1 on failure, which is the reflex of anyone who has written shell scripts, has a guard that complains and permits. When a question describes a policy that was supposed to prevent something and did not, an incorrect exit status is a plausible and frequently correct explanation.
Before and after are different powers
A hook running ahead of a tool call can veto it, because the operation has not happened yet. That is the placement for anything phrased as a prohibition: writing outside a directory, running a destructive command, touching a protected file. A hook running afterwards can only respond to what already occurred, which makes it the right home for formatting a file that was just edited, appending to an audit trail, or running a check whose result should inform the model rather than undo the change.
Trying to enforce a prohibition from the later position is a category error that questions like to offer as a plausible option. Once the write has landed, a non-zero status is a complaint rather than a rollback.
Hooks, permission rules and written guidance are three layers
Pick the cheapest layer that can carry the requirement. A permission rule is declarative: it allows, asks about or denies a tool by name and argument pattern, needs no code, and cannot express anything subtler than the pattern it matches. A hook is code, so it can read the payload, consult the repository, run a checker and decide.
Guidance in a project file is advice and belongs to preferences rather than invariants. The sorting question is whether a pattern alone settles the case. If it does, use a permission rule, which carries no runtime cost and nothing to maintain. If the decision requires inspecting content or running something, that is a hook. If breaking it is merely undesirable, prose is fine.
Where candidates go wrong
Trap 1: exiting 1 to block an operation
Only status 2 blocks. Everything else non-zero is reported and then ignored, so a guard written with the conventional shell idiom of exiting 1 on failure will announce its objection and let the operation through.
The result is a control that appears installed, passes a casual test because the message does appear, and enforces nothing whatsoever. A question describing a policy that fires without preventing anything should send you straight to the exit status.
Trap 2: assuming a hook is sandboxed
A hook is a command running with your credentials, your environment and your filesystem access. Cloning a repository whose checked-in settings define hooks therefore means running somebody else's code on the first matching event, with no prompt, before you have read anything.
Treat hook configuration from an untrusted source the way you would treat a build script from one. The corollary is that a hook can leak: a command echoing environment variables into a log has published whatever secrets were in scope.
Trap 3: putting expensive work behind a broad matcher
Because every matching event fires the command, a full test suite attached to every file edit turns a two-second interaction into a minute of waiting. The workable pattern is narrow matching with fast commands.
Anything genuinely slow belongs at a coarser moment, such as the end of a turn or the end of a session, where paying the cost once is acceptable and nobody is sitting through it repeatedly.
Common questions
How much of the CCDV-F exam is Claude Hooks?
1.0%, the lowest weight of any named sub-skill on the blueprint. That is one question out of 53 at most, and possibly zero on a given form. Understand the mechanism well enough to answer confidently and then spend your remaining time on the heavier areas.
Which exit status blocks an operation?
Two. Zero permits it, two stops it and returns the standard error text to the model so it can correct course, and every other non-zero value surfaces as a non-blocking problem while the operation continues. That three-way split is the most examinable fact in the sub-skill.
When should I use a hook rather than a permission rule?
Use a permission rule when the decision is fully determined by the tool and an argument pattern, since it needs no code and costs nothing at run time. Reach for a hook when the decision requires logic: inspecting file contents, checking repository state, or running a validator before deciding.
Can a hook undo something that already happened?
No. A hook running after an operation observes the result and can report on it, but the effect has landed. Anything that must not happen has to be caught by a hook positioned before the operation, or excluded by a permission rule so the tool is never reachable in the first place.
The rest of Security and Safety
Practise this
The CCDV-F bank covers every sub-skill in the blueprint, weighted the way the real paper is. Free sample questions need no account.
Free CCDV-F questions