Which Hook Event Can Actually Prevent the Write
Your team keeps a machine-generated .env.production file that Claude
should never be allowed to modify, no matter what a prompt or a
compromised instruction asks for. You want to register a hook that,
when it exits with status 2, guarantees the edit never lands on disk
in the first place — not one that merely notices the change after the
fact.
Which hook event should this guardrail be registered on?
The correct answer is "PreToolUse, blocking with exit 2 before the write executes."
PreToolUse fires before a tool call executes, which is the only
point in the lifecycle where a hook can still prevent the call —
exiting 2 cancels it before the Edit/Write ever touches the file,
and stderr is fed back to Claude as the reason so it can adjust
instead of just failing silently.
"PostToolUse, blocking with exit 2 after the write executes" is the
classic trap: PostToolUse only fires once the tool call has already
succeeded, so by the time it runs, .env.production has already been
overwritten — an exit code at that point can react (alert, revert via
a separate command) but cannot stop the write itself, which is what
the requirement actually calls for. "Stop, blocking with exit 2 when
Claude ends its turn" is the wrong granularity entirely — Stop fires
once per turn, not per tool call, so it has no reliable way to
intercept one specific Edit/Write before it happens; by the time a
turn ends, an unwanted edit earlier in that same turn has long since
landed. "SessionStart, blocking with exit 2 at session start" isn't
even in the running — it fires once when a session begins or resumes,
has no visibility into individual tool calls at all, and per the
lifecycle table it cannot block anything in the first place.
Share this question