Stop Claude Code From Running rm -rf, Force-Pushing or Reading .env

Register a PreToolUse hook that reads the command Claude is about to run, and exit with code 2 when it matches something you never want run. Claude Code then blocks the tool call and shows Claude your stderr message as the reason. This page gives you that hook: one settings.json block and one bash script that refuses a recursive rm aimed at /, ~, $HOME or .., any force push, git reset --hard, curl or wget piped into a shell, and any read or write of a .env file other than .env.example. It was fed 45 tool calls, and the full table of what it blocked and what it let through is below, including 15 near-misses it must not block and 6 dangerous commands it cannot see.

It is a seatbelt, not a sandbox. The last sections say exactly what gets past it and what to add.

Everything below about hook events, exit codes and the JSON a hook receives comes from the official Claude Code hooks reference, the hooks guide, the permissions page and the settings page, all fetched on 2026-09-29, when this machine’s claude --version reported 2.1.284. Every quote was re-checked word for word against the same pages on 2026-10-13; the three that had changed by then are quoted in their new wording, and so is the onFailure section the hooks reference has gained since.

How a hook blocks a command

The hook event is PreToolUse. It runs after Claude has written the tool call and before the tool runs, and on exit code 2 the reference’s per-event table says it blocks the tool call. In the reference’s words, PreToolUse “Runs after Claude creates tool parameters and before processing the tool call”, and its row in the exit code 2 table reads “Blocks the tool call”.

The message goes back to Claude, not only to you. The PreToolUse decision section says: “A hook that blocks by exiting 2 routes the same way as "deny": Claude sees the stderr message as the denial reason.” The hooks guide describes the effect of its own blocking example: “Claude receives feedback explaining why the edit was blocked, so it can adjust its approach.” So write the reason for Claude to read: “git push that rewrites the remote” says more than “denied”.

Two exit-code details decide whether a guard works at all:

• Exit 2, not exit 1. The reference warns: “Without valid JSON on stdout, Claude Code treats exit code 1 as a non-blocking error, even though 1 is the conventional Unix failure code. If your hook is meant to enforce a policy, use exit 2.” For a non-blocking error its exit code section says “The action goes ahead”, so a guard that ends in exit 1 lets everything through unless the hook sets "onFailure": "block" (see below).
• Exit 0 is not approval. The hooks guide says that for a PreToolUse hook exit 0 “doesn’t approve the tool call: the normal permission flow still applies.” So the guard can only take permissions away. Anything it allows still goes through your usual prompts and rules.

It also holds when you have turned the prompts off. The hooks guide says a PreToolUse deny blocks the tool even in bypassPermissions mode or with —dangerously-skip-permissions, and the reference says a hook that exits 2 routes the same way as a deny. The guide’s exact line: “PreToolUse hooks fire before any permission-mode check, in every permission mode, including dontAsk. A hook that returns permissionDecision: "deny" blocks the tool even in bypassPermissions mode or with --dangerously-skip-permissions.” That is the case this page is for: auto-accept and long unattended sessions.

The reference documents a second way to block, printing JSON with hookSpecificOutput.permissionDecision set to "deny" and exiting 0. This script uses exit 2 because it needs no JSON writer. The reference says to “Choose one approach per hook: either use exit codes alone for signaling, or exit 0 and print JSON for structured control”, and this one prints nothing on stdout.

The settings.json block

Add this to ~/.claude/settings.json. If the file already has a hooks key, put the PreToolUse entry inside it rather than replacing it. Settings files are strict JSON; the settings page puts it plainly: “a // comment or a trailing comma is a syntax error”. The "onFailure": "block" key needs Claude Code 2.1.295 or later; the section after the install step explains it and shows claude doctor checking it.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Read|Edit|Write",
        "hooks": [
          { "type": "command", "command": "~/.claude/hooks/claude-guard.sh", "onFailure": "block" }
        ]
      }
    ]
  }
}

The matcher names four built-in tools. The matcher table says a matcher made of only letters, digits and | is a list of exact names, so Bash|Read|Edit|Write fires for those four tools and nothing else. The four names are on the reference’s list of tools PreToolUse matches: “built-in tools such as Bash, PowerShell, Edit, Write, Read, Glob, Grep”.

The user file is the right place for a guard because the hook locations table scopes ~/.claude/settings.json to “All your projects”. The ~ in the command works because a command hook without args runs in shell form, which the reference says “is passed to a shell: sh -c on macOS and Linux”.

Create the folder, save the script from the next section into it, and make it executable:

mkdir -p ~/.claude/hooks
# save the script below as ~/.claude/hooks/claude-guard.sh, then:
chmod +x ~/.claude/hooks/claude-guard.sh

That last step matters more for a guard than for any other hook. The reference says a hook that can’t start is a non-blocking error too, for example “when the script path doesn’t exist or isn’t executable”, and warns that “a mistyped path in settings.json means the hook never runs.” After you install it, run the pipe test further down once, then watch the first tool call of your next session for a hook error notice.

Make a missing script block instead of pass: “onFailure”: “block”

That is what the "onFailure": "block" in the settings block above is for. The reference’s section Block the action when a hook fails says: “On most events, when a hook fails or times out, Claude Code still carries out the action, so a policy hook with a wrong path or a crashing script lets everything through. To block the action instead, set "onFailure": "block" on a command or http hook. The default value is "continue". Requires Claude Code v2.1.295 or later.” Run claude --version before you rely on it.

The value has to be spelled exactly. claude doctor checks settings files without starting a session, so it was run here twice on a scratch project whose .claude/settings.json holds this page’s settings block: once as published, once with the value misspelt as "blok". HOME and CLAUDE_CONFIG_DIR both pointed at an empty scratch folder, the scratch home has no claude-guard.sh in it at all, and claude --version printed 2.1.296 (Claude Code). The one change made to the outputs below is that the scratch home’s real path is printed as ~.

The scratch project, as published:

mkdir -p .claude
cat > .claude/settings.json <<'EOF'
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Read|Edit|Write",
        "hooks": [
          { "type": "command", "command": "~/.claude/hooks/claude-guard.sh", "onFailure": "block" }
        ]
      }
    ]
  }
}
EOF
ls ~/.claude/hooks/claude-guard.sh; echo "ls exit $?"
claude doctor </dev/null > block.txt; echo "doctor exit $?"
grep -A3 '^Invalid settings' block.txt; echo "grep exit $?"
grep -c 'claude-guard' block.txt; echo "grep exit $?"

ls exit 2
doctor exit 0
grep exit 1
0
grep exit 1

On stderr:

ls: cannot access '~/.claude/hooks/claude-guard.sh': No such file or directory

The same file with the value misspelt:

sed -i 's/"onFailure": "block"/"onFailure": "blok"/' .claude/settings.json
claude doctor </dev/null > blok.txt; echo "doctor exit $?"
grep -A3 '^Invalid settings' blok.txt; echo "grep exit $?"

doctor exit 0
Invalid settings
- ~/demo/.claude/settings.json › hooks.PreToolUse.0.hooks.0: Invalid command hook (onFailure: Invalid option: expected one of "continue"|"block") — a PreToolUse/PermissionRequest hook that cannot be loaded may be what guards the permissions declared beside it, so nothing it sits in is applied until the entry is fixed or removed.
- ~/demo/.claude/settings.json › hooks.PreToolUse.0.hooks.0.onFailure: Invalid value. Expected one of: "continue", "block"
  Suggested fix: Valid values: "continue", "block"
grep exit 0

With the value as published, the report has no Invalid settings section. It does not mention claude-guard either (the count is 0), although the script the entry points at does not exist, so doctor is no substitute for the pipe test or for onFailure. With "blok", doctor names the field and the two values it accepts, then says why it matters: “a PreToolUse/PermissionRequest hook that cannot be loaded may be what guards the permissions declared beside it, so nothing it sits in is applied until the entry is fixed or removed.” Put plainly, in doctor’s and the docs’ words: one misspelt value makes the guard a hook “that cannot be loaded”, and then “nothing it sits in is applied” until “the entry is fixed or removed”. Doctor exited 0 both times, so in a script, look for the Invalid settings line rather than the exit code.

What onFailure does when the script really fails, during a live session, was not run here: it needs a session, and this page’s runs never start one. The docs describe it: with the script missing, “Claude Code blocks the call, and the error includes failed; blocking because onFailure is "block"”.

The guard script

It needs bash and python3. Python parses the hook’s JSON and does nothing else; there is no jq. The reference’s PreToolUse input section says “PreToolUse hooks receive tool_name, tool_input, and tool_use_id”, and its per-tool tables list command as the Bash tool’s input and file_path as the input of Write, Edit and Read. Those three fields are all the script reads.

#!/usr/bin/env bash
# claude-guard.sh: a Claude Code PreToolUse hook that refuses a short list of
# destructive shell commands and any read or write of a .env file.
# Blocks by printing a reason to stderr and exiting 2; exits 0 otherwise.
# Needs bash and python3 (python3 only parses the JSON): no jq.

block() {
  printf 'Blocked by claude-guard: %s\n' "${1}" >&2
  exit 2
}

# --- the three documented fields, one per line --------------------------------
# tool_name, tool_input.command (Bash) and tool_input.file_path (Read/Edit/Write).
# Newlines inside a command become " ; " so each line of a script is still
# checked as its own command. If the input cannot be parsed, fail closed.
fields=$(python3 -c '
import json, sys
d = json.load(sys.stdin)
i = d.get("tool_input") or {}
one = lambda v: str(v or "").replace("\r", " ").replace("\n", " ; ")
print(one(d.get("tool_name")), one(i.get("command")), one(i.get("file_path")), sep="\n")
' 2>/dev/null) || block "could not parse the hook input, so nothing was allowed"
{ IFS= read -r tool; IFS= read -r cmd; IFS= read -r path; } <<<"$fields"

# --- .env files: .env and .env.anything, except .env.example ------------------
is_env_file() {
  case "${1}" in
    .env.example) return 1 ;;
    .env | .env.*) return 0 ;;
  esac
  return 1
}

case "$tool" in
  Read | Edit | Write)
    path="${path//\\//}"   # Windows backslashes -> slashes, as the docs advise
    is_env_file "${path##*/}" && block "$tool of ${path##*/} (secrets file)"
    exit 0
    ;;
  Bash) ;;
  *) exit 0 ;;
esac

# Any word in the command that names a .env file, e.g. cat .env, cp x .env
for word in $(printf '%s' "$cmd" | tr -c 'A-Za-z0-9_.~/-' ' '); do
  is_env_file "${word##*/}" && block "the command touches ${word##*/} (secrets file)"
done

# --- curl or wget piped straight into a shell ---------------------------------
pipe_to_shell='(curl|wget)[^|]*\|[[:space:]]*(sudo[[:space:]]+)?(ba|z|da)?sh([[:space:]]|$)'
subst_to_shell='(ba|z|da)?sh[[:space:]]+<\([[:space:]]*(curl|wget)'
if [[ $cmd =~ $pipe_to_shell || $cmd =~ $subst_to_shell ]]; then
  block "a downloaded script piped into a shell"
fi

# --- one command at a time -----------------------------------------------------
# Split on ; & | ( ) ` and newlines, drop quotes, then look at each command's
# first real word (after sudo, env, VAR=value and similar prefixes).
segments=$(printf '%s' "$cmd" | tr ';&|()`' '\n\n\n\n\n\n' | tr -d "\"'")
while IFS= read -r seg; do
  read -ra w <<<"$seg"
  n=0
  while ((n < ${#w[@]})); do
    case "${w[n]}" in
      sudo | doas | command | builtin | nohup | nice | time | env | exec | do | then | else | '!' | -* | *=*) ((n++)) ;;
      *) break ;;
    esac
  done
  prog="${w[n]##*/}"
  args=("${w[@]:n+1}")

  if [[ $prog == rm ]]; then
    recursive=0 opts=1
    for a in "${args[@]}"; do
      if ((opts)) && [[ $a == -- ]]; then opts=0; continue; fi
      if ((opts)) && [[ $a == --recursive || $a =~ ^-[a-zA-Z]*[rR] ]]; then recursive=1; continue; fi
      if ((opts)) && [[ $a == -* ]]; then continue; fi
      t="${a/#\$\{HOME\}/\$HOME}"   # ${HOME} -> $HOME
      [[ $t == */\* ]] && t="${t%/\*}"   # dir/* -> dir
      [[ -z $t ]] && t=/
      while [[ $t == */ && $t != / ]]; do t="${t%/}"; done
      case "$t" in
        / | '~' | '$HOME' | .. | . | '*') ((recursive)) && block "recursive rm aimed at $t" ;;
      esac
    done
  fi

  if [[ $prog == git ]]; then
    k=0
    while ((k < ${#args[@]})); do   # skip git's own options, e.g. -C dir
      case "${args[k]}" in
        -C | -c) ((k += 2)) ;;
        -*) ((k++)) ;;
        *) break ;;
      esac
    done
    sub="${args[k]}"
    rest=("${args[@]:k+1}")
    for a in "${rest[@]}"; do
      if [[ $sub == push ]] && [[ $a == --force* || $a =~ ^-[a-zA-Z]*f[a-zA-Z]*$ || $a == +* ]]; then
        block "git push that rewrites the remote ($a)"
      fi
      if [[ $sub == reset && $a == --hard ]]; then
        block "git reset --hard throws away uncommitted work"
      fi
    done
  fi
done <<<"$segments"

exit 0

What each part does:

• Parsing fails closed. If python3 is missing or the input is not JSON, the script blocks the call instead of waving it through. You will notice at once, because every Bash, Read, Edit and Write call is refused with the same message. A guard that fails open would fail silently. This check and "onFailure": "block" cover different failures: the script blocks when it runs and cannot read its input, and onFailure covers what the reference calls “a policy hook with a wrong path or a crashing script”.
• The file tools are checked by file name. A Read, Edit or Write is blocked when the last part of file_path is .env or starts with .env., unless it is exactly .env.example. The path cannot be dressed up to slip past, because the reference says: “Claude Code expands ~ and relative paths before hooks run, so a hook that matches on paths can’t be bypassed via ~ or a relative spelling of the same path”. The backslash line follows the same section’s advice for paths that arrive from Windows.
• Shell commands are checked for .env by word. Any word in the command whose last part is a protected .env name blocks it: cat .env, grep KEY config/.env.production, cp .env.example .env. The last one is a write of your real .env; run it yourself.
• The curl check looks at the whole command. curl or wget followed by a pipe into sh, bash, zsh or dash (with or without sudo), or bash <(curl ...), is blocked. A pipe into sha256sum or jq is not.
• rm and git are checked one command at a time. The command is cut at ;, &, |, brackets, backticks and newlines, and quotes are dropped. For each piece the script skips prefixes such as sudo, env and VAR=value to find the program actually being run. A recursive rm (-r, -R, -rf, -fr, --recursive) is blocked when a target is /, ~, $HOME, .., . or *, with or without a trailing / or /*. For git, options such as -C dir are skipped to find the subcommand; push is blocked with --force, --force-with-lease, -f or a +branch refspec, and reset is blocked with --hard.

--force-with-lease is blocked on purpose. It is safer than --force, but it still rewrites history on the remote, which is exactly what you do not want an unattended session doing. Delete --force* from the push line if you disagree.

Every command it was fed

These 45 tool calls were piped into the script as PreToolUse payloads, in the shape the reference documents. The table is generated from the recorded results, and the test that guards this page re-runs every row against the script as published here. Rows written as Read(…), Edit(…) or Write(…) are file-tool calls with that file_path; every other row is a Bash command, and ⏎ marks a newline inside one. A plain “Blocked” or a “near-miss” is the guard doing its job. A “known miss” is a dangerous command it lets through, listed so you know it exists. The one “over-block” is harmless and blocked anyway.

The near-misses are the reason not to write the one-liner most examples use. The reference’s own example blocks any command that starts with rm, and the guide’s drop table example greps the whole command, which is fine as a demonstration and miserable in a real session: rm -rf node_modules is something Claude runs all day, and a guard that blocks the routine work gets switched off.

Test it by piping a payload in

You do not need a Claude Code session to check the script. Pipe a payload in by hand and look at the exit code:

echo '{"hook_event_name":"PreToolUse","tool_name":"Bash","tool_input":{"command":"git push --force origin main"}}' | ~/.claude/hooks/claude-guard.sh; echo "exit $?"
echo '{"hook_event_name":"PreToolUse","tool_name":"Bash","tool_input":{"command":"rm -rf node_modules"}}' | ~/.claude/hooks/claude-guard.sh; echo "exit $?"

The first prints Blocked by claude-guard: git push that rewrites the remote (--force) and exit 2; the second prints only exit 0. If both say exit 0, the script is not the file you think it is.

What this cannot stop

A PreToolUse hook is not a sandbox. It reads the text of a command before the command runs, so anything that hides the real command from that text gets past it: a variable, eval, base64, bash -c with a quoted string, or a script that deletes files itself. Every one of those is a “known miss” row in the table, tested, not guessed:

• Variables. D=/; rm -rf $D passes, because $D is only resolved when the shell runs, after the hook has said yes.
• Another shell or eval. bash -c 'rm -rf /' and eval "$(echo ... | base64 -d)" pass. The guard would have to be a shell interpreter to see inside them.
• Other programs. A Python one-liner calling shutil.rmtree, a make clean, a test script or an npm script that calls rm itself: the command Claude runs looks innocent, and the damage happens a process later.
• Aliases and functions. A hook reads the command as text. It does not know that gpf is your alias for a force push.
• Commands that are not on the list. git clean -fdx, git checkout -- ., dd, mkfs, DROP TABLE. Add patterns for what worries you, and add near-miss rows to your own tests at the same time.
• Reading secrets without naming them. grep -r API_KEY . reads .env without the word .env in it.
• Tools the matcher does not name. The matcher above covers Bash, Read, Edit and Write only. On Windows, the reference says to “Match Bash|PowerShell in hooks that inspect shell commands”, and “A hook that matches only Bash never fires there.” This script parses bash syntax and is not written for PowerShell.
• Files you attach yourself. The reference: “PreToolUse runs only when Claude calls a tool.” A file you add with @ in your prompt goes in without a tool call, so no hook sees it.
• A hook that hangs. On the timeouts section: “A timed-out command, http, or mcp_tool hook doesn’t block the tool call.” This script makes no network calls and reads nothing but its input, so it has nothing to wait on. Keep it that way if you extend it.

Add permission deny rules

Permission rules are the other layer, and they are checked by Claude Code itself. The permissions page says “Rules are evaluated in order: deny, then ask, then allow”, and a hook cannot talk its way past them: “PreToolUse hook decisions don’t bypass permission rules.” Put this beside the hooks key in the same ~/.claude/settings.json:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(git push --force *)",
      "Bash(git reset --hard *)"
    ]
  }
}

The two Read rules are the settings page’s own example for stopping Claude reading .env files. The permissions page’s Read and Edit section says they reach further than the file tools: they “apply to Claude’s built-in file tools, to file commands Claude Code recognizes in Bash, such as cat, head, tail, sed, and tee”. Note that Read(./.env.*) also covers .env.example, which the guard allows.

Use both layers. The guard on this page refuses a Read, Edit or Write whose file is .env or .env.anything, and any shell command that names one. Add Read deny rules for your .env files to settings.json as well, because a deny rule is checked even when no hook runs. A broken script path, a missing python3 on a new machine or a hook you commented out while debugging all leave the deny rules standing.

Deny rules have the same blind spot as the guard, and the docs say so. From what a Bash rule doesn’t match: “a deny or ask rule covers the invocation Claude usually produces and isn’t a security boundary around the program.” Its examples are the same kind of miss as this page’s table: Bash(rm *) does not stop bash -c 'rm -rf build/', and Bash(git push *) does not stop git -C . push origin main. The two layers miss different things, though. The deny rule matches command text from the front, so Bash(git push --force *) does not match git push origin main --force (row 11), which the guard blocks. In the other direction, the compound commands section says deny rules apply “when any subcommand matches them, including a command nested inside a subshell, a command substitution, or a control-flow body such as a for loop”, and that a deny rule “matches past any leading assignment”.

For a real boundary, use a sandbox or a container

Neither layer reads what a program does after it starts. For that, the permissions page points to the OS. It calls permissions and sandboxing “complementary security layers”, where sandboxing “provides OS-level enforcement that restricts shell commands’ filesystem and network access”, and adds: “For OS-level enforcement that blocks all processes from accessing a path, enable the sandbox.” The blunt version of the same idea is to run long unattended sessions inside a container or a throwaway VM that holds only the project and no credentials you would miss. Then rm -rf ~ costs you a container, and a .env that is not mounted cannot be read by anything.

A guard like this one still earns its place inside a container. It stops the common accident early, with a reason Claude can read and act on, before the sandbox has to.

Related

Hooks can also tell you when Claude is done: Claude Code Notification When Done wires the Notification and Stop hooks to a desktop ping, and Make Your Terminal Glow When Claude Code Needs You lights up the right terminal when you run several sessions at once.

What was tested, and what was not

The script was tested by piping documented-shape PreToolUse payloads into it on Linux (bash 5.1, Python 3.10), not inside a live Claude Code session. The test that guards this page pulls the settings.json block and the script out of the built page, not out of a draft, and runs all 45 rows above plus two more cases: input that is not JSON, and a machine without python3, both of which must block. It also runs the hook’s command string through sh -c, the way the reference says shell-form hooks run, and checks that every hook event and tool name in the JSON blocks appears in the fetched docs. What it cannot prove is how a given Claude Code version responds to the block in a live session; for that, the docs quoted above are the source, and the pipe test is the quickest way to check your own copy.

The two claude doctor runs are re-run by the same test in a scratch HOME and CLAUDE_CONFIG_DIR, removed afterwards, and their outputs and exit codes must match the ones printed above. What a hook with "onFailure": "block" does when its script fails during a session was not run: that needs a live session, so for it the docs quoted above are the only source.

← Back to all posts

Follow new posts by RSS: paste dankdev.com/feed.xml into any feed reader. It is a plain XML file — no signup, no email address, no account. Posts land there the same day they go up, and there is nothing to unsubscribe from later.

Back to the top