Claude Codeで複数行コマンドの自動承認が効かない問題の原因と対処法

Claude Codeの自動承認ルールは、以前heredocや複数行の文字列を含むBashコマンドに、ワイルドカードパターンを一致させられませんでした。原因はワイルドカード照合の実装にあり、v2.1.72で修正済みです。この記事では不具合の仕組み、修正された範囲、修正後も残る別の落とし穴、そして改行を避けられないコマンドを自動承認したいときの対処法を確認します。

Claude Codeの自動承認ルールが複数行コマンドに一致しなかった不具合とは

この不具合は、settings.jsonのallowルールやSub-agentのfrontmatterに書いたauto_approve_patternsが、改行を含むBashコマンドに一致しない現象でした。2025年11月にGitHubのissueとして報告され、コミットメッセージのheredocや複数行のSQLなど、日常的なコマンドで再現しました。

たとえばBash(echo 'のようなプレフィックスルールを設定していても、echo '本文\n\n署名' > file.txtのように改行を含むコマンドは一致せず、毎回確認プロンプトが立ちました。報告者はBash(echo:*)やBash(echo *)など複数の書き方を試しましたが、いずれも改行の手前で照合が止まっています。issueには38件のコメントが付き、AWSのマルチラインコマンドやpsqlのクエリでも同じ現象が報告されました。

影響は軽くありませんでした。複数のユーザーが、この不具合のために--dangerously-skip-permissions(通称yolo mode)へ切り替えたとコメントしています。git commitのheredocやサブエージェント経由のBash呼び出しは複数行になりやすく、自動承認が効かないと結局すべてのコマンドを手動承認する状態に戻ってしまうためです。

なぜheredocや埋め込み改行だけワイルドカードをすり抜けたのか

原因を特定したのは、issueにコメントしたユーザーのxhirogaさんです。Claude Codeのバンドル済みソース(cli.js)を追ったところ、ワイルドカード照合が*を.に変換して正規表現を組み立てている実装が見つかりました。

問題は.の挙動にありました。JavaScriptの正規表現で.は、既定では改行文字にマッチしません。dotAllフラグ(s)を付けない限り.は\nを素通りするため、改行を含むコマンド文字列全体にワイルドカードルールを一致させられませんでした。

ここで区別したいのが、複合コマンドの評価で扱う「改行が区切り演算子として働くケース」との違いです。git statusとnpm testを改行だけで2行に分けて実行させると、Claude Codeはその改行を&&などと同じ区切り演算子として扱い、各行を独立したサブコマンドとして評価します。一方、heredocの本体やクオートされた複数行文字列の中身は、シェルの構文上1つのコマンドの一部です。区切りとしては扱われず、その改行を含む文字列全体がワイルドカードパターンに一致するかどうかがそのまま問われます。今回の不具合は、後者の「1つのコマンドに埋め込まれた改行」でワイルドカードが機能しなかったケースでした。

v2.1.72で修正された範囲と、まだ残る別の落とし穴

公式changelogを見ると、修正は1回ではなく短い間隔で2回に分けて入っています。v2.1.71では「heredocのコミットメッセージを含む複合Bashコマンドで誤って確認プロンプトが立つ」不具合が修正され、続くv2.1.72では次の不具合がまとめて修正されました。

Fixed several permission rule matching issues: wildcard rules not matching commands with heredocs, embedded newlines, or no arguments

issueは2026年4月19日にクローズされ、Anthropicの公式アカウントが「v2.1.72で修正済み」とコメントしています。Anthropicのbcherny氏は、クローズ直前(2026年4月7日)のコメントで修正の範囲を明確にしました。氏によれば、元の不具合(Bash(...)のallowルールで*が改行をまたいで一致しない)は2026年3月上旬にdotAllフラグを使う修正で解消済みで、これがv2.1.72に対応します。氏はあわせて、スレッドに書き込まれた別の症状は個別の不具合として扱われているとも述べています。挙げられたのは次の3つでした。

• $()やバッククォートによるコマンド置換があると確認を求められる動作(コメント時点で対応中と説明)
• バックスラッシュによる行連結を「複数の操作」として扱ってしまう、コマンド分割側の別の不具合
• 引用符付きの改行の後に#で始まる行が続くときのヒューリスティックの誤判定

これらはheredocの照合バグとは別に追跡されているため、v2.1.72を適用しても解消しない場合があります。実際、バックスラッシュやコマンド置換に関わる権限マッチングの修正は、v2.1.72より後のリリースでも続いています。v2.1.98ではバックスラッシュ付きの引数が誤って読み取り専用として自動承認されてしまう不具合、v2.1.243ではフックのif条件がコマンド置換を含む文字列に誤反応する不具合が、それぞれ修正されました。

改行を含むコマンドで確認プロンプトが立ったときの切り分け方

まだ確認プロンプトが立つ場合、最初にclaude --versionか/statusで現在のバージョンを確認します。v2.1.71・v2.1.72より前なら、今回のheredocの不具合そのものが原因である可能性が高く、アップデートで解消します。

それより新しいバージョンでも立つ場合は、別の不具合を疑います。確認プロンプトのメッセージを見て、$()やバッククォートを含むコマンドならコマンド置換まわり、バックスラッシュの行連結が絡むなら別の分割ロジックの不具合の可能性があります。該当のキーワードで変更履歴を検索し、使っているバージョンに修正が含まれているかを確認するのが確実です。現在有効なallow/denyルールそのものを見直したいときは、/permissionsコマンドでスコープごとの一覧を確認できます。

改行そのものを避けられるなら、それも実用的な選択です。heredocの代わりに一時ファイルへ書き出してから実行する、複数行のSQLやコミットメッセージを;で連結した1行に収めるといった書き換えで、既存のワイルドカードルールがそのまま効くようになります。ちなみにこれはターミナルへの複数行入力(Shift+Enterで改行するプロンプト入力)とは別の話で、こちらは生成済みのBashコマンド文字列に含まれる改行の話です。

それでも自動承認したい場合はPermissionRequestフックに判定を委ねる

改行を避けられないコマンドを安全に自動承認したいなら、権限ルールのワイルドカード一致に頼らず、PermissionRequestフックでtool_input.commandの生の文字列を直接検査する方法があります。フックはJSON経由でコマンド全文を受け取るため、改行が含まれていても文字列としてそのまま判定できます。

たとえば、コマンドの先頭行だけを見て安全なパターンかどうかを判定するフックなら、次のような形になります。

#!/bin/bash
input=$(cat)
command=$(jq -r '.tool_input.command // empty' <<<"$input")
first_line=$(head -n1 <<<"$command")
 
case "$first_line" in
  "git commit -m "*|"cat <<"*)
    jq -n '{hookSpecificOutput:{hookEventName:"PermissionRequest",decision:{behavior:"allow"}}}'
    ;;
  *)
    exit 0  # 決定なし。通常の確認ダイアログに委ねる
    ;;
esac

先頭行だけで判定する設計は単純ですが、issue内でraducoriu氏が指摘したように、コマンドがコメント行から始まる場合はこの判定だけでは不十分です。実運用では、コマンド全文に複数のパターンを当てるか、rm -rfのような危険な操作を含んでいないかを別途チェックする設計にします。フックの入出力の詳細な仕様、updatedPermissionsでルールをどこに保存するか、deny/askルールとの優先順位はPermissionRequest hookで承認ダイアログの前に判定を挟むで扱っています。

よくある質問

v2.1.72より前のバージョンで今すぐ回避する方法はありますか

あります。上記のPermissionRequestフックのように、コマンド文字列を直接検査する方法ならワイルドカード照合のバグを経由しないため、旧バージョンでも機能します。もちろんバージョンをv2.1.72以降へ上げること自体も有効な対処です。

複合コマンドの評価とheredocの不具合はどう違いますか

複合コマンドの評価は、&&や改行で区切られた複数のコマンドをサブコマンドごとに判定する仕組みで、今回の不具合とは別の話です。詳しくはClaude CodeのBash権限ルールは複合コマンドをどう評価するかにまとめています。

まとめ

heredocや複数行文字列を含むBashコマンドにワイルドカードの許可ルールが一致しない不具合は、ワイルドカード照合の正規表現がdotAllフラグを持たなかったことが原因でした。v2.1.71・v2.1.72の2段階で修正済みですが、コマンド置換やバックスラッシュの行連結が絡む別の不具合は個別に追跡されており、修正はその後のリリースでも続いています。まだ確認プロンプトが立つなら、まずバージョンを確認し、変更履歴で該当のキーワードを検索するところから始めます。改行を避けられないコマンドを確実に自動承認したいなら、PermissionRequestフックでコマンド文字列を直接検査する設計に切り替える選択肢もあります。