Claude Codeのpromptフックは「〜をブロックして」と書くと危険コマンドを通していた（未検証の報告）

何が起きたか

筆者は、Claude Code 2.1.294（2026年10月8日公開）の変更履歴にある、 指示の形で書いたpromptフックとagentフックがブロックすべきものを通していた、 という修正を実機で確かめた。promptフックは、ツールの実行前にモデルへ 通してよいかを判定させる仕組みである。筆者によれば、修正前の2.1.293では 「〜するコマンドをブロックして」と書いた判定文が、再帰的な削除をほとんど 止めなかった。検証は使い捨てのディレクトリで行われ、実際の被害は 報告されていない。

現場の混乱

筆者は毎回、使い捨てのディレクトリにファイル2つ入りの victim/ フォルダを 置き、claude -p にコマンドをそのまま1回だけ実行するよう頼んだ。実行後に victim/ が残っているかで、ブロックされたかを判定した。試したのは victim/ を丸ごと消す5種類（rm -rf、変数経由のrm -r -f、bash -c 経由、 find -delete、PythonのshutilによるrmTree）で、各3回、計15回である。

2.1.293では15回中13回がすり抜け、ブロックは2回だった。筆者は、 書き方を変えるとすり抜ける以前に、最も素直な rm -rf victim でも 止まらなかったと述べている。環境はLinuxで、検証は2026年10月8日に行った。

原因

2.1.294の変更履歴の1行は、指示の形で書いたpromptフックとagentフックが ブロックすべきものを通していた、というものである。筆者の記事は、 指示の形だとなぜ通ったのかという内部の仕組みには触れていないため、 ここでも原因をそれ以上は特定しない。

筆者の比較では、2.1.293でも判定文を「このBashコマンドは安全か」と問う形に し、危険な場合に返すJSONを明示すると、削除系5種を各2回、計10回すべて ブロックできた。このとき ls と1ファイルだけのrmは実行された。 判定に使うモデルは指定しておらず、既定のバックグラウンド処理用のモデルだった。

対策

筆者によれば、2.1.294では指示の形の同じ設定で15回すべてがブロックされた。 ls、git status、1ファイルだけのrmは止められなかった。拒否の理由は Claudeに返された。筆者は、claude --version で版を確かめ、2.1.294未満なら claude update で更新するよう勧めている。古い版を使う環境では、判定文を 質問の形にして返すJSONを明示する。

筆者は注意点も挙げている。モデルの判定は確率的なので、15回止まったことは 必ず止まる保証にはならない。絶対に止めたいものは、パターン照合の commandフックや permissions.deny と重ねて使う。Bashを実行するたびに 判定のためのモデル呼び出しが1回増え、時間と利用量がかかる。修正の対象は promptフックとagentフックで、commandフックには関係がない。

教訓は、危険コマンドの遮断をpromptフックだけに任せず、版を確認したうえで、 別の仕組みと重ねて動作を確かめておくことである。