Claude Code just deleted your entire project folder. Not because it wanted to. Because no one told it not to. That is the kind of silent disaster that claude code hooks were built to prevent, and most Claude Code users do not even know they exist.
If you have spent any time with Claude Code, you already know the feeling. You ask it to refactor a file and it starts renaming things you never touched. You tell it to fix a bug and it decides the real problem is your environment variables. You step away for coffee and come back to find it has rewritten half your config files. Claude Code is powerful, sure. But it is also a little too eager to help, and that eagerness can cost you hours of cleanup or worse, expose secrets you forgot were lying around in plain text.
Hooks change the dynamic entirely. They are small scripts that run automatically before or after Claude does something, giving you a hard stop on dangerous actions. Think of them as guardrails that actually work, not just polite suggestions in a system prompt. Here is what they do, why they matter, and exactly how to set up the ones that will save you the most grief.
What claude code hooks actually do
A hook is a shell command, an HTTP request, or even another LLM prompt that fires at a specific point in Claude Code’s workflow. There are a few trigger points, but the two that matter most are PreToolUse (before Claude runs a command or edits a file) and PostToolUse (right after it finishes).
When a PreToolUse hook exits with code 0, Claude proceeds normally. When it exits with code 2, Claude stops dead in its tracks. The hook can send a message back through stderr explaining why, and Claude will actually read that message and try a different approach instead of blindly retrying the same thing.
This matters because Claude Code does not naturally pause and think about consequences the way a cautious human would. It sees a task, it executes. Hooks add that missing pause. They are deterministic scripts, meaning they behave the same way every single time, regardless of how Claude is feeling or what context it has accumulated.
The hooks live in your project’s .claude/settings.json file or in your global Claude Code configuration. You do not need to be a developer to set them up. If you can copy and paste a few lines into a JSON file, you are good.
Why you need hooks (even if you are not a developer)
Maybe you are thinking, “I only use Claude Code for simple stuff, I do not need this.” Fair enough. But consider this: Claude Code has access to your terminal. It can run shell commands, edit files, create new files, and modify existing ones. If your project has an .env file with API keys, database credentials, or payment processor secrets, Claude can read those, modify them, or accidentally include them in a response.
Even for non-coding tasks, hooks prevent Claude from wandering into directories it should not touch, running commands that take down your local server, or making git commits that overwrite your team’s work.
The five claude code hooks below cover the most common ways Claude Code can accidentally wreck your day. Pick the ones that apply to your setup.
5 claude code hooks that prevent real damage
Block destructive commands before they run
This is the one that saves you from the “oh no” moment. The hook intercepts every bash command Claude tries to run and blocks anything destructive. We are talking rm -rf, dd if=, mkfs., and the classic curl | bash pattern where something downloads and executes a script without you ever seeing what is inside.
The hook reads Claude’s proposed command as JSON from stdin, checks it against a list of regex patterns, and if anything matches, exits with code 2. Claude gets the block message and suggests a safer alternative.
You can customize the regex patterns to include other commands you want to block. Maybe DROP TABLE for database work, or git push --force if you are extra cautious. The point is that this runs before the command executes, every single time, without exception.
Protect your .env files and secrets
Claude loves to “fix” configuration files. You tell it something is not working and its first instinct is often to poke around your .env file and start adjusting values. That is fine when the values are harmless test data. It is a catastrophe when those values are live API keys or production database URLs.
This hook targets the Edit and Write tools specifically. It checks the file path Claude is about to modify, and if the path matches patterns like .env, secrets, or credentials, it blocks the action entirely. Claude cannot read, write, or modify those files.
If you use tools like Claude Code for connecting Claude to your apps with Zapier, you probably have API keys scattered across multiple .env files. This hook is not optional for that setup.
Stop git disasters like force pushes
Git history is the kind of thing you do not appreciate until it is gone. Claude Code can run git commands, and while it usually means well, it has been known to force push to main, delete branches people were still using, or reset commits that contained work from other team members.
This hook monitors git-related commands and blocks the dangerous ones. Force pushes to protected branches, branch deletions without confirmation, and hard resets all get caught. Claude gets told why the command was blocked and proposes a safer git strategy.
If you have ever lost work because an AI agent rewrote your git history, you know why this matters. It is not theoretical. It happens.
Limit runaway token spending
Claude Code can run long tasks that burn through tokens fast, especially when it gets into a loop of trying to fix something, failing, and retrying with a slightly different approach. The token meter keeps ticking while you are not watching.
A token monitoring hook checks Claude’s usage at regular intervals and flags or blocks tasks that exceed a threshold you set. It does not stop Claude from working, but it forces a checkpoint where it pauses, reports its progress, and asks if it should continue.
This is especially useful for the /goal command that turns Claude Code into an autonomous worker. Left unchecked, a long-running goal can drain your Claude subscription faster than you realize.
Run quality checks before commits
Instead of letting Claude commit whatever it wants, this hook runs your linting tools, tests, or formatting checks before the commit goes through. If anything fails, the commit gets blocked and Claude has to fix the issues first.
This is not about being strict for the sake of it. It is about making sure that Claude’s code actually passes the same quality bar you would apply to your own work. No one wants to debug a failing test suite that Claude confidently declared was “probably fine.”
You can configure which checks run and how strict they are. Maybe you only want type checking for TypeScript projects. Maybe you want the full test suite for mission-critical code. The hook runs whatever you tell it to, and Claude cannot skip it.
How to add hooks in claude code
Setting up claude code hooks takes about five minutes. Open your project’s .claude/settings.json file (create it if it does not exist), and add a hooks section with the scripts you want. Each hook needs a matcher that tells Claude which tool triggers it, a command that runs the script, and an optional timeout.
For a PreToolUse hook that blocks destructive commands, the structure looks like this: you define the hook type, point it to your bash script, and set which tools it applies to. Claude Code reads this configuration on startup, so you will need to restart your Claude Code session after making changes.
You can also set hooks globally in your Claude Code user settings, which means they apply to every project you work on. This is handy for the .env protection hook, since you probably want that running everywhere, not just in one repo.
Claude Code has a lot of powerful features that fly under the radar, and hooks are right at the top of that list. They turn Claude Code from a tool that sometimes does unexpected things into a tool that does exactly what you allow it to do. The upfront cost of setting up five hooks is maybe ten minutes. The cost of not having them could be a deleted project, exposed credentials, or a mangled git history.
Start with the destructive command blocker and the .env protector. Those two claude code hooks alone will save you from 90% of the accidents that Claude Code users run into. Then add the rest as you need them. Hooks are not about limiting Claude. They are about making sure Claude works the way you actually want it to.
