Claude Code の Yes/No が急に増えた原因は、自作フックの書き換えだった

Claude Code で Yes/No の確認が急に増えて困っている方へ。私の PC では、自作フックが命令を書き換えて壊していたのが原因でした。

読むと、フックを疑う順番と、確認を消す設定に手を出さなくて済む理由が分かります。まず同じ命令の結果を 4 つの条件で比べます。

同じ for の形を 4 つの条件で頼むと、何が返りましたか？

頼んだ命令は、存在しない 2 つの .py を for で回すだけの形で、rm は含みません。条件ごとに 3 回ずつ、モデルは haiku、--strict-mcp-config を付けて頼みました。

判定は 2 つの文を別々に数えました。1 つは公式の拒否の文「could not be checked for dangerous rm operations」。もう 1 つは確認の題名「Dangerous rm operation not ruled out」です。

返った文は次のとおりです。「This command could not be checked for dangerous rm operations: the shell may read it differently than it was parsed. This requires explicit approval.」。3 回とも同じでした。

この画面なしの実行では「not ruled out」という題の文は 1 回も返らず、返ったのは上の拒否の文でした。以前の私は、この 2 つを区別せずに数えていました。

動画は、同じ表を窓に出す様子です。表の数字は、実験で保存した出力から数えた値です。

注意が 1 つあります。普段の設定の行は、フックを直した後の本番で測りました。直す前の本番で測り直したものではなく、直す前の動きは写しで確かめています。

書き換えの中身は、どこが壊れていましたか？

PreToolUse のフックは、Claude Code が道具を使う直前に動く仕組みです。許可や拒否だけでなく、渡す命令を書き換えることもできます。

この PC では、自己テストの語がある命令に環境変数を足す自作フックがありました。直す前の処理は、区切りの頭に足していたため、書き換え後の命令が次の形になりました。

for f in 無い1.py 無い2.py; SELFTEST_ISOLATED=1 do python -X utf8 $f --自己テスト …

シェルでは、for の「do」の前に代入は置けません。文法が壊れるので、シェルと Claude Code で命令の読み方が割れる恐れがあると見なされ、拒否の文になったと考えています。内部の判定処理そのものは解析していません。

直した処理は、do の後ろに足します。書き換え後は次のとおりで、命令は走って終了コード 2 が返りました。

for f in 無い1.py 無い2.py; do SELFTEST_ISOLATED=1 python -X utf8 $f --自己テスト …

たとえるなら、荷物に付ける伝票を、箱の中ではなく蓋の継ぎ目に貼ってしまった状態です。中身は同じでも、受付が「中を確かめられない」と止めます。

最初の測定の「88 回で 0 回」は、なぜ根拠にならないのですか？

最初に、rm を含まない害の無い 40 形を 88 回回しました。通常が 40 回、bypassPermissions が 40 回、auto が 8 回です。確認は 0 回でした。

この測定では --setting-sources project を付け、普段のフックを読み込まない条件で回していました。原因のフックが動かない条件で数えたので、回数を重ねても普段の問題を捉えられません。

つまり「普段のフックを外した条件では、確認は 88 回中 0 回」までが言えることです。「普段の設定でも出ない」とは言えません。測る前に、困っている場面と同じ設定が読み込まれているかを確かめるべきでした。

公式の説明と、返った文は同じですか？

公式のDangerous rm operation not ruled out の説明は、シェルと Claude Code で命令の読み方が割れる恐れがある場合に、この確認が出るとしています。rm が無い命令でも対象です。

同じ節に、auto と bypassPermissions では確認の代わりに「could not be checked for dangerous rm operations」という拒否の文になる、とも書かれています。今回返ったのは、こちらの文でした。

だから「rm を含まないのに Dangerous rm の確認が出た」と書くのは正確ではありません。正しくは、拒否の文が返った、です。

自分の環境で確かめるには、何を順にすればよいですか？

私が実際にやった順は、全フック停止、rtk とそれ以外に分ける、語を見て 1 本に絞る、の順でした。再現できる形で書きます。

1. 全フックを止めて同じ命令を試す。次の 1 行だけの json を作り、claude -p --settings stop.json のように渡します。{"disableAllHooks": true} です。
2. 命令を書き換えるフックを探す。フックのフォルダで findstr /s /i updatedInput *.py を回すと、updatedInput を返す処理が見つかります。
3. 1 本だけを結線して比べる。その 1 本の写しを作り、--settings の一時ファイルの PreToolUse にだけ書いて、同じ命令を頼みます。
4. 書き換え後の命令を保存して読む。文法が壊れていないかを見ます。直した後は、同じ命令で 3 回確かめます。

私の測定では、rtk だけを有効にした条件では出ず、rtk 以外を有効にした条件では出ました。自己テストの語がある形では出て、無い形では出ませんでした。この 2 つが絞る手掛かりでした。

確認を消す環境変数は、使ってよいですか？

おすすめしません。公式は CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 で、bypassPermissions のこの確認を消せると説明しています。ただし rm -rf ~ のような命令も素通りになり得ると警告しています。詳細は公式の環境変数の説明にあります。

今回必要だったのは、確認を消すことではなく、フックが壊した命令を直すことでした。危険なので、この環境変数は設定して試していません。

まだ分かっていないことは何ですか？

分かったのは、この PC の自作フックの書き換えが、拒否の文の原因だったことです。写しで 3 回中 3 回が 3 回中 0 回に変わり、全フック停止でも 3 回中 0 回でした。

分かっていないのは 3 つです。フックを使わない人に同じ文が出る原因、人が対話画面で押す確認の出方、公式の判定処理の中身です。rm を含む削除は、安全のため実行していません。

この記事に出てくる言葉

📬 新着記事をメールでお届けします

記事公開時にメールでお知らせします。週数本・無料・いつでも 1 クリックで解除できます。

登録する

登録するとプライバシーポリシーに同意したものとみなされます。