8 Claude Code Hooks That Automate What You Keep Forgetting

Have you ever told Claude Code to do something and it just didn't? You said format the code - It didn't. You said don't touch that file - It did. You said run tests before finishing - It forgot. That's because CLAUDE.md is a suggestion. Claude reads it and follows it about 80% of the time. Hooks are different. They're automatic actions that fire every time Claude edits a file, runs a command, or finishes a task. Below I will share 8 personal hooks you can copy straight into your settings.json and never think about again 👇 Before we dive in, I share daily notes on AI & vibe coding in my Telegram channel: https://t.me/zodchixquant🧠 How hooks work (30-second version) What are hooks? Hooks are automatic actions that run every time Claude Code does something, like editing a file or running a command. You set them up once and they work in the background without you thinking about it. The two you'll use most: PreToolUse runs before Claude does something. You can inspect the action and block it by returning exit code 2. Think of it as a bouncer. PostToolUse runs after Claude does something. You can run cleanup, formatting, tests, or logging. Think of it as quality control on the assembly line. You configure them in .claude/settings.json in your project root. That file gets committed to git, so your whole team gets the same hooks automatically. Full documentation: https://code.claude.com/docs/en/hooks 1. Auto-format every file Claude touches The problem: Claude writes correct code that breaks your formatting rules. You add "always run Prettier" to CLAUDE.md and it works most of the time, but not always. The hook: Prettier runs automatically after every file write or edit. Swap npx prettier --write for whatever formatter you use: black for Python, gofmt for Go, rustfmt for Rust. The pattern is the same. This was the first hook I set up and honestly it should be the default for every project. No more "Claude forgot to format" commits. 2. Block dangerous commands The problem: Claude is powerful enough to run rm -rf, git reset --hard, DROP TABLE, or curl to random URLs. It probably won't, but "probably" isn't good enough when it's your production database. The hook: Block destructive commands before they execute. Create .claude/hooks/block-dangerous.sh: Then add to your settings.json: Exit code 2 is the key. It blocks the action and sends your error message back to Claude so it can try a safer approach. Exit code 0 means "go ahead." Anything else logs a warning but doesn't block. 3. Protect sensitive files from edits The problem: Claude can read and edit any file in your project. That includes .env, package-lock.json, config files, and anything else you'd rather it didn't touch. The hook: Block edits to files that should be off-limits. Create .claude/hooks/protect-files.sh: 4. Run tests after every edit The problem: Claude makes a change, says "done," and you discover the tests are broken 20 minutes later when you try to commit. The hook: Run your test suite automatically after every code change. If tests fail, Claude sees the failure and can fix it immediately. The tail -5 keeps the output short so it doesn't flood Claude's context. You want Claude to see "3 tests failed" not the full 200-line test output. Boris Cherny, the creator of Claude Code, says giving Claude a feedback loop like this improves output quality by 2-3x. Instead of writing code and hoping it works, Claude writes code, sees the test results, and fixes failures on its own. 5. Require passing tests before creating a PR The problem: Claude finishes a feature and immediately creates a PR. Tests are failing. Your reviewer sees red CI and sends it back. The hook: Block PR creation unless all tests pass. Create .claude/hooks/require-tests-for-pr.sh: This is a hard gate. No green tests, no PR. Claude will fix the failures first because exit code 2 tells it the action was blocked and why. 6. Auto-lint and report errors The problem: Claude writes code that works but violates your ESLint rules, style guide, or type checks. You catch it during review and send it back. The hook: Lint after every edit. If lint fails, Claude sees the errors and fixes them before you ever look at the code. You can chain this with the auto-format hook from #1. Prettier runs first, then ESLint. By the time you see the code, it's formatted and lint-clean. 7. Log every command Claude runs The problem: Claude runs a lot of shell commands during a session. If something goes wrong, you want to know exactly what it did and when. The hook: Append every Bash command to a log file with timestamps. Create .claude/hooks/log-commands.sh: Now you have a timestamped audit trail of every command Claude ran. Add .claude/command-log.txt to your .gitignore so it doesn't pollute your repo. This is especially useful for debugging: if Claude broke something three sessions ago, you can look at the log and find exactly when and what it ran. 8. Auto-commit after each comple