Claude Code Hooks: The 6 I Actually Run in Production

I run Claude Code unattended — it researches, writes, builds, and pushes on a schedule while I'm asleep. The first time I let it loose, I did what everyone does: I wrote a long system prompt full of “never commit secrets,” “always run the build,” “don't touch the migrations.” It mostly worked. Mostlyis the problem. Over a long enough run, an instruction buried in a 3,000-token prompt is a suggestion the model can quietly drift from, and you find out at 7am when something's in the git history that shouldn't be.

A hook doesn't drift. It's a shell command Claude Code runs itself, at a defined moment, outside the model's judgment. And the ones that fire beforea tool call can veto it — exit non-zero and the action is blocked, with Claude handed a clear error explaining what it hit. That's the mental shift:

Claude Code fires hooks at several lifecycle events. The four I lean on: PreToolUse (before a tool runs, can block it), PostToolUse (after a tool succeeds, can't undo it), SessionStart (when a session begins, its stdout becomes context), and Stop (when the agent finishes). Each entry declares the event, an optional matcher for which tools it applies to, and the command to run. Anthropic's hooks guide documents the full list of events. Below are the six I actually run.

These two are the reason I sleep. Both are PreToolUse hooks matched to the Write and Edit tools, and both work by refusing to let a bad write reach disk.

1. Block secret writes. The hook reads the content Claude is about to write and greps it for secret shapes — private-key headers, long token-shaped strings, common names like SECRET, PASSWORD, or a bare sk- prefix. One match, exit 1, write blocked, Claude told why. This is the single highest-leverage hook you can write. A leaked key in a public repo is a genuinely bad day; a five-line grep makes it structurally impossible.

2. Protect sensitive files. Same idea, keyed on the target path instead of the content. If the file being edited is .env, a lockfile, or a database migration, the hook rejects it. Migrations especially — I never want an autonomous agent rewriting a migration that's already run against production. The hook makes “don't touch these” a fact of the filesystem, not a line the model has to keep in mind 40 turns deep.

Keep these two near-instant. A PreToolUse hook sits in the critical path of everymatching tool call, so a slow one taxes the whole run. A path check or a grep is microseconds — that's the budget.

A PostToolUse hook fires aftera tool succeeds. It can't undo anything, so it's for reacting, not gating.

3. Auto-format the edited file.After every successful edit, run the formatter on just the touched file. The payoff isn't only clean diffs — it's that formatting stops being something the model has to spend attention on. It writes roughly-right code; the hook makes it exactly-right. Style disappears as a category of thing to get wrong.

4. Run the fast tests. After a code change, run the quick unit tests related to what changed — not the whole suite. This catches the obvious regression the moment it happens, while the context is still fresh, instead of at the very end when the agent has moved on. The discipline here is scope: a hook that runs your entire test matrix after every edit will make the agent crawl. Fast, related tests only. I save the full suite for the end.

If you're wiring hooks into a longer autonomous loop, the same restraint applies to the whole run — I wrote up the budget-and-kill-switch side of that in running AI agents on autopilot without torching your budget.

The last two aren't guardrails — they're quality-of-life, and they're the ones that turned my unattended runs from “works” to “trustworthy.”

5. Inject context on SessionStart. When a session begins, this hook prints the current git branch, the last few commit messages, and any open issues to stdout — and Claude Code injects that stdout straight into the model's context. Instead of starting cold and asking “what am I working on,” the agent opens already knowing the branch, the recent history, and the queue. It's the cheapest way to make a fresh session feel like it never left. This matters even more with subagents, which start cold by design and re-buy their context at the uncached rate.

6. Ping me on Stop.When an unattended job finishes, a Stop hook POSTs a one-line result to Telegram — done, what shipped, or what broke. I don't babysit a terminal for a job that runs at 3am; the hook tells me it's finished and whether I need to look. This is the difference between an automation you trust and one you keep checking on.

A useful contrast: hooks are the deterministic layer, and skills and MCP servers are the model-driven layer. Hooks fire whether or not the model “decides” to; skills and tools are things the model chooses to reach for. You want both, doing their own jobs.

Put the project-level ones in version control so every agent and every teammate runs the same guardrails. That's the whole game for anything unattended: the rules travel with the repo, not with whoever remembered to paste them into a prompt. If you're building the loop around these, my notes on dynamic Claude Code workflows cover how the pieces fit together.

• A hook is a shell command Claude Code runs at a lifecycle event; PreToolUse hooks can block the action by exiting non-zero.
• If something must happen, it belongs in a hook, not a prompt — prompts drift, hooks don't.
• Guard with PreToolUse: block secret writes and protect .env / migrations. These are the two that let you run unattended.
• React with PostToolUse: auto-format the edited file, run fast related tests. Keep both quick.
• SessionStart injects branch + commits + issues as context; a Stop hook pings you when the job's done.
• Check project hooks into version control so the guardrails travel with the repo.