Claude Code の PreToolUse フックで rm -rf を止める設定と、その限界

rm -rf のような取り返しのつかないコマンドだけは、確認を挟まずに実行されると困ります。PreToolUse フックを使うと、ツール呼び出しの直前にスクリプトで判定して拒否できます。

このフックの強みは、権限モードより先に発火することです。公式ドキュメントは、PreToolUse フックが dontAsk を含むすべての権限モードで権限チェックより先に発火し、permissionDecision: "deny" を返せば bypassPermissions や --dangerously-skip-permissions でもツールをブロックすると明記しています。

終了コード 2 で止める

もっとも短い書き方です。スクリプトを stderr にメッセージを書いて exit 2 で終えるだけで、ツール呼び出しが拒否され、その stderr が Claude に渡されます。

#!/usr/bin/env bash
# .claude/hooks/block-rm-rf.sh
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

if echo "$CMD" | grep -Eq '(^|[;&|[:space:]])rm[[:space:]]+(-[a-zA-Z]*r[a-zA-Z]*f|-[a-zA-Z]*f[a-zA-Z]*r)'; then
  echo "Blocked: 再帰的かつ強制の rm は禁止です。削除対象を個別に指定してください" >&2
  exit 2
fi

exit 0

macOS と Linux では実行権限が必要です。

chmod +x .claude/hooks/block-rm-rf.sh

登録は .claude/settings.json に書きます。公式ドキュメントの例と同じく、ログ用と判定用の 2 つを並べられます。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r .tool_input.command >> ~/.claude/bash.log"
          },
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/block-rm-rf.sh"
          }
        ]
      }
    ]
  }
}

公式ドキュメントはこの構成の動きをこう説明しています。2 つのフックは並列に実行され、ログ用は 0 で終了して判定を返さず、判定用が 2 で終了してツール呼び出しを拒否します。拒否が優先されるためコマンドはブロックされ、ログは先に実行済みなので記録も残ります。

permissionDecision で理由を伝える

終了コードの代わりに、stdout に JSON を出す方法もあります。理由を構造化して渡せます。

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "再帰削除は禁止です。git clean -n で確認してから個別に消してください"
  }
}

PreToolUse で指定できる値は 3 つです。

値	動作
allow	対話的な権限プロンプトを省略する。deny ルールと ask ルールは引き続き適用される
deny	ツール呼び出しを取り消し、理由を Claude に渡す
ask	通常どおり権限プロンプトを表示する

deny の場合、permissionDecisionReason がそのまま Claude にフィードバックされます。Claude はそれを読んで別の手段を取れるので、単に止めるより「なぜ駄目か・代わりに何をするか」を書いておくと作業が止まりません。

ファイル編集側も止める

rm は Bash ツール経由ですが、Edit や Write で重要ファイルを壊されるのも同じ種類の事故です。公式ドキュメントはファイルパスを見て拒否する例を示しています。

#!/bin/bash
# protect-files.sh

INPUT=$(cat)
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')

# Windows のバックスラッシュ区切りを正規化して、下のパターンに一致させる
FILE_PATH="${FILE_PATH//\\//}"

PROTECTED_PATTERNS=(".env" "package-lock.json" ".git/")

for pattern in "${PROTECTED_PATTERNS[@]}"; do
  if [[ "$FILE_PATH" == *"$pattern"* ]]; then
    echo "Blocked: $FILE_PATH matches protected pattern '$pattern'" >&2
    exit 2
  fi
done

exit 0

この場合は matcher を Edit|Write にして登録します。stdin の JSON の構造は hooks が受け取る stdin JSON の構造、matcher に書ける値は hooks の matcher に書ける値一覧 を参照してください。

文字列一致の限界

ここが重要です。コマンド文字列の一致は簡単に外れます。

書き方	素朴な rm -rf 一致
rm -rf build	一致する
rm -r -f build	一致しない
rm --recursive --force build	一致しない
FLAGS="-rf"; rm $FLAGS build	一致しない
find . -delete	そもそも rm ではない

上のスクリプトは -rf と -fr の並びに対応していますが、それでも網羅ではありません。フックは「うっかり」を止める運用上の歯止めとして有効で、悪意のある回避を防ぐ仕組みではありません。

確実に遮断したい対象には、次の層を併用してください。

• permissions の deny ルール: Bash(rm -rf *) のようなルールは、フックの結果に関わらず評価されます。公式ドキュメントは「フックの判断は権限ルールを迂回しない。PreToolUse フックが何を返しても deny ルールは評価される」と説明しています(settings.json で permissions を設計する)
• サンドボックス: プロセス単位でファイルシステムへのアクセスを制限します。スクリプトが内部で開くファイルにも効きます

なお、critical path を対象にした rm と rmdir は、どの権限モードでも自動承認されません。フックの allow でも承認されない、という点も公式に明記されています。

動作を確認する

登録したら /hooks を実行して、対象のイベントの下にフックが出ているかを確認します。スクリプト単体の確認は、サンプル JSON を流し込むのが確実です。

echo '{"tool_name":"Bash","tool_input":{"command":"rm -rf /tmp/x"}}' | ./.claude/hooks/block-rm-rf.sh; echo "exit=$?"

exit=2 になれば期待どおりです。終了コードごとの意味は hooks の終了コードの意味と使い分け にまとめています。

まとめ

• PreToolUse フックは権限チェックより先に発火し、deny は bypassPermissions でも効く
• 止め方は 2 通り。短く書くなら exit 2、理由を渡すなら permissionDecision の JSON
• 同じイベントに複数のフックを並べると並列実行され、拒否が優先される
• フックの allow では deny ルールを上書きできない。強められるが緩められない
• 文字列一致は rm -r -f や変数展開で外れる。確実な遮断は deny ルールとサンドボックスに任せる