Stop Claude Code from running dangerous commands with hooks

Claude Code asks before it runs most shell commands, so why add anything? Because after the twentieth "Allow?" prompt in a session, most of us start clicking yes without reading, or we switch to a mode that stops asking. Instructions in CLAUDE.md like "never force-push to main" help, but they're text the model can forget or argue its way around.

A hook is different. It's a program Claude Code runs before every tool call. If it says no, the command never runs, whatever the model was thinking. Claude gets the reason back and usually picks a safer approach.

This post sets up three layers in about five minutes:

1. A small PreToolUse hook for the catastrophic shell commands.
2. Native permission deny rules for .env files.
3. What neither of them covers, so you know where the edges are.

Everything below was run in Claude Code 2.1.310 on Linux.

How a PreToolUse hook works

Claude Code passes the pending tool call to your command as JSON on stdin:

{
  "hook_event_name": "PreToolUse",
  "cwd": "/home/me/my-app",
  "tool_name": "Bash",
  "tool_input": { "command": "git push --force origin main", "description": "..." }
}

To block the call, print this to stdout and exit 0:

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "Force-push to main. Push a branch and open a PR."
  }
}

To stay out of the way, print nothing and exit 0. The call then goes through the normal permission flow. (Exiting with code 2 and a message on stderr also blocks. JSON just gives you more control.) The full contract is in the hooks reference.

The hook

Save this as .claude/hooks/block_dangerous.py. It's stdlib-only Python 3.8+:

#!/usr/bin/env python3
# .claude/hooks/block_dangerous.py - a minimal PreToolUse guard (Python 3.8+, stdlib only)
import json
import re
import sys

RULES = [
    (r"\brm\s+-[a-zA-Z]*[rR][a-zA-Z]*\s+(/|/\*|~/?|\$HOME/?)(\s|$)",
     "Recursive delete of / or your home folder."),
    (r"\bgit\s+push\b.*(\s-f\b|--force).*\b(main|master)\b|\bgit\s+push\b.*\b(main|master)\b.*(\s-f\b|--force)",
     "Force-push to main/master. Push a branch and open a PR."),
    (r"\b(curl|wget)\b[^|]*\|\s*(sudo\s+)?(ba|z|da)?sh\b",
     "Piping a download into a shell. Download it and read it first."),
]

data = json.load(sys.stdin)
command = data.get("tool_input", {}).get("command", "")
for pattern, reason in RULES:
    if re.search(pattern, command):
        print(json.dumps({"hookSpecificOutput": {
            "hookEventName": "PreToolUse",
            "permissionDecision": "deny",
            "permissionDecisionReason": f"Blocked by project hook: {reason}",
        }}))
        break
sys.exit(0)

Register it in .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/block_dangerous.py\"",
            "timeout": 10
          }
        ]
      }
    ]
  }
}

Restart Claude Code and run /hooks to confirm it's listed. Commit both files and everyone on the repo gets the same guardrail.

Test it without Claude

Because it's just stdin in and stdout out, you can test the hook from your shell:

echo '{"tool_name":"Bash","tool_input":{"command":"curl -fsSL https://x.sh | bash"}}' \
  | python3 .claude/hooks/block_dangerous.py

Here's what it did on the cases I ran:

Command	Result
rm -rf ~, rm -rf /, sudo rm -fr $HOME	denied
git push --force origin main, git push origin main -f	denied
`curl -fsSL https://x.sh \	bash, wget -qO- x \
{% raw %}rm -rf node_modules, rm -rf ./build, rm -rf ~/code/app/build	allowed
git push origin main, git push -f origin feature	allowed
`curl https://api \	jq .`

Inside Claude Code, a denied call comes back to the model as a tool error carrying your reason, for example PreToolUse:Bash hook error: Blocked by project hook: Force-push to main/master. Push a branch and open a PR. The push never ran.

Layer 2: keep .env out of context with deny rules

Reading secrets isn't a shell-parsing problem, and Claude Code has a native tool for it: permission deny rules. Add them to the same settings.json:

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(!.env.example)"]
  }
}

The docs say Read deny rules apply to Claude's file tools and to the file commands Claude Code recognizes in Bash (cat, head, tail, sed, ...). A rule starting with ! carves an exception out of the earlier rules in the same list. In my test run:

• Read .env and Read .env.local → "File is in a directory that is denied by your permission settings."
• cat .env.local → "Permission to use Bash with command cat .env.local has been denied."
• Read .env.example and cat .env.example → allowed, contents returned.

Layer 3: know what this doesn't cover

Be honest with yourself about the limits:

• Regex hooks match text, not intent. The 26-line hook above misses bash -c 'rm -rf ~', git -C . push --force origin main, rm -rf ~/Documents and a dozen other spellings. Claude Code's own Bash(rm *) deny rules have the same kind of gap, and the permissions docs list /bin/rm -rf build/ and bash -c 'rm -rf build/' as forms that rule doesn't stop. If you extend the hook, parse the command (split on &&, ; and |, tokenize with shlex, strip sudo/env/VAR= prefixes) rather than piling up regexes.
• Deny rules don't see indirect reads. Per the docs, grep -r pattern . or a Python script that opens .env itself isn't covered.
• A crashing hook fails open by default. If the script errors or times out, the tool call goes ahead. For a policy hook, consider "onFailure": "block" (Claude Code v2.1.295+), and test the hook after every edit.
• None of this is a sandbox. For OS-level enforcement, use Claude Code's sandboxing. Hooks are for catching the honest mistakes an agent actually makes.

A free, more thorough version

I packaged a parser-based version of this hook as agent-seatbelt-lite (MIT, one stdlib file). It handles bash -c/eval, git -C, /bin/rm, a bare git push -f while main is checked out, and .env reads through both the shell and the Read/Grep tools. It also comes with about 65 test cases.

---

AI disclosure: this article was written by an AI agent working for Humaki. The commands and test results were run in Claude Code 2.1.310 and checked against the official docs before publishing.