Claude Code Hooks: Which Ones Actually Earn Their Keep

Real talk: most Claude Code hooks you will see people brag about are fun for a day and then quietly deleted. After running hooks on real client builds for months, exactly three stayed on every project I touch. A PostToolUse hook that auto-formats every file the agent edits. A PreToolUse hook that blocks a short list of commands I never want run while I am not watching. And a Stop hook that tells me out loud the second a long task is done so I stop babysitting the terminal. That is the whole keeper list. Everything below is why those three survived and the rest did not.

A hook is a command that runs on its own at a specific moment, so you never have to remember to run it. You define hooks in your settings and pick the event that triggers each one. The events you will actually use are PreToolUse (fires before the agent runs a tool, and can block it), PostToolUse (fires right after a tool runs, great for cleanup), and Stop (fires when the agent finishes its turn). That is the mental model. The power is not any single hook - it is that the thing happens every single time, automatically, whether or not you were paying attention.

This is the one I would fight you for. I run a PostToolUse hook that formats every file Claude Code writes or edits, the moment it touches it. Before this, I would let the agent build for an hour and then get a diff full of inconsistent spacing and quote styles that I had to clean up by hand or in a separate pass. Now the formatter runs on each edit, so the code is already clean when I read it. The agent never drifts on style, and I never review formatting noise. It is invisible, which is exactly why it is the best hook I have - you only notice it the day you turn it off.

The second keeper is a PreToolUse hook that inspects a command before it runs and blocks a short deny-list of things I never want executed unattended. This is not about not trusting the agent. It is about the one time in a hundred where a broad delete or a force-push would be a genuinely bad afternoon. The hook checks the command, and if it matches my list it stops it and tells me why, so I decide instead of finding out after. Hot take: a small block-list hook does more for letting the agent run on a longer leash than any amount of careful prompting, because it is a hard stop, not a polite request.

The third one is small and I love it. A Stop hook fires when the agent finishes a turn, and mine plays a sound and shows a notification. On a long task I used to sit and watch the terminal like it was a kettle. Now I go do something else, and the moment it is done or needs me, I hear it. This is the hook that changed how I work more than the fancy ones did, because it broke the babysitting habit. The lesson under all three keepers: the best hooks remove a small thing you were doing manually every session, not a big thing you do once.

Here is the part a summary of the docs will not give you: what did not work for me. I tried a hook that auto-committed to git after every edit. It sounded tidy and it was chaos - a commit history full of half-built states I had to squash later. Deleted. I tried a hook that ran the full test suite on every single edit; on a real project that meant waiting on tests after trivial changes, so it killed my flow. I moved testing to when I actually asked for it. And I tried stacking notification hooks on many events, which turned into noise I learned to ignore, which is worse than no notification at all. The pattern: if a hook fires too often or does something heavy on a light action, you will end up fighting it. Keepers are light, specific, and rare enough to matter.

Start with the auto-format hook, because it is the safest and the one you will feel immediately. Add a single PostToolUse hook that runs your formatter on the file that was just edited, then work as normal for a session and watch your diffs come back clean. Do not add three hooks at once - add one, live with it for a day, and only add the next when you catch yourself wishing it existed. That is the same rule I use for everything in Claude Code: let the real work tell you what to automate, instead of automating things you imagine you will need. Shipping a clean build beats collecting clever config.

Hooks are the quiet layer that turns Claude Code from a tool you drive into a workspace that maintains itself while you build. The three keepers cover the daily grind - clean code, a safety net, and a nudge when it is your turn. Inside the CCC community we keep a running list of the hooks members actually kept versus the ones they dropped, with the exact commands, so you can copy what works instead of trial-and-erroring your own. Come grab the current list and add yours to it.