Claude Codeで読み取り専用コマンドが自動承認される条件

Claude Codeはls・cat・grepなど組み込みの読み取り専用コマンドの集合を持っています。これらはManual mode・acceptEdits mode・auto mode・plan mode・dontAsk mode・bypassPermissions modeのどのモードでも確認プロンプトなしで実行されます。この集合は設定で変更できません。特定のコマンドだけ確認を求めたい場合は、askルールかdenyルールを個別に追加します。ただし「読み取り専用だから常に無条件で通る」わけではなく、ワイルドカードの展開先やコマンドの組み合わせ次第でプロンプトが立つ例外がいくつか存在します。

自動承認される読み取り専用コマンドの主な顔ぶれ

Claude Codeが読み取り専用として扱う組み込みコマンドの主なものは、ls・cat・echo・pwd・head・tail・grep・find・wc・which・diff・stat・du・cdです。加えて、読み取り専用の形に限ったgit(git statusやgit diffなど)も対象です。公式ドキュメントはこれらを「These include …」という例示として挙げているだけで、完全な一覧は公開されていません。これは、承認疲れの主要因になりやすい「毎回同じ調査系コマンドで確認を求められる」問題を、個別のallowルールを書かせずに解消する設計です。実務上はここまでで十分です。

この集合はハードコードされていて、settings.json側から増減させることはできません。逆に、この中の特定コマンドにだけ確認を求めたいときは、Bash(find *)のようなaskルールやdenyルールを追加すれば、その分だけプロンプトを復活させられます。

ワイルドカードは「全フラグが読み取り専用」なら展開される

引用符なしのワイルドカードパターンは、そのコマンドが受け取るフラグがすべて読み取り専用の性質を持つ場合に限り、確認なしで展開されます。ls *.tsやwc -l src/*.pyはこの条件を満たすため、シェルがグロブを展開した後の実行もそのまま通ります。

一方、書き込みや実行が可能なフラグを持つコマンド(find・sort・sed・gitなど)は事情が違います。コマンド自体は読み取り専用の使い方でも、引用符なしのグロブが含まれているとManual modeで確認プロンプトが立ちます。グロブが展開された結果に-deleteのような書き込み系フラグが紛れ込む可能性を排除できないためです。

Manual modeでも確認プロンプトが立つ5つの例外

読み取り専用コマンドの集合に含まれていても、次の5パターンはManual modeで確認プロンプトの対象になります。

これらはいずれも「コマンド名は読み取り専用の集合に入っているが、副作用や境界越えのリスクを排除しきれない」ケースです。判定はコマンド名の一致だけで終わりません。フラグや接続先まで見た上で確認要否を決めています。dockerが別のデーモンを指す設定の扱いは、Claude Codeのサンドボックス設計が扱うネットワーク分離の考え方とも重なります。

cdを含む複合コマンドで確認が必要になる2パターン

作業ディレクトリまたは追加ディレクトリの内側へ移動するcd自体も読み取り専用扱いで、cd packages/api && lsのように各部分が単独で読み取り専用と判定できる複合コマンドは確認なしで実行されます。複合コマンドの一般的な評価の仕組みはClaude CodeのBash権限ルールは複合コマンドをどう評価するかにまとめていますが、cdには単独の例外がさらに2つあります。

• cdとgitの組み合わせ: cdが異なるディレクトリへ移動する場合、移動先でgitを実行するとそのディレクトリのgit hookが動く可能性があるため確認が必要です。移動先が結局は現在の作業ディレクトリに解決されるcdは実質no-opとして扱われ、この確認は発生しません
• cdと出力リダイレクトの組み合わせ: cdの後に実行するコマンドのリダイレクト先がどのディレクトリを基準に解決されるかをClaude Codeが判定できない場合に確認が必要です。リダイレクト先が/dev/nullだけのコマンド(cd app; grep -r pattern . 2>/dev/nullなど)は、/dev/nullが作業ディレクトリに依存しないため確認なしで通ります

リダイレクトを付けると読み取り専用の扱いが変わる

ls > out.txtのように読み取り専用コマンドへ出力リダイレクトを付けると、リダイレクト先へのファイル書き込みとして別途チェックが入ります。コマンド自体が読み取り専用でも、書き込み先のパスがEdit系のdeny・askルールや保護対象パスに触れる場合は確認が必要になり、「読み取り専用コマンドだから無条件」という前提は崩れます。判定の主体はコマンド名ではなく書き込み先のパスです。この、判定の主体が書き込み先のパスである点は、次節で見るacceptEdits modeの自動承認範囲とも共通します。

acceptEdits modeでは読み取り専用集合の上に書き込み系が積まれる

ここまでの読み取り専用コマンドの集合は、全モード共通の下限です。acceptEdits modeでは、この下限の上にモード固有の自動承認集合がさらに積まれます。mkdir・touch・rm・rmdir・mv・cp・sedといった書き込み系コマンドも、確認プロンプトなしで実行されるのです。

無条件ではありません。対象は作業ディレクトリとadditionalDirectoriesで明示的に追加したディレクトリの内側に限られます。範囲の外に出た瞬間、確認プロンプトが立ちます。保護対象パス(.envや認証情報ファイルなど)への操作は対象外です。rm・rmdirがcriticalなパス(ホームディレクトリやシステムディレクトリなど)へ向かう場合も、acceptEdits modeの自動承認からは外れて確認が必要になります。

つまりモードが変わるたびに集合をゼロから覚え直す必要はありません。「読み取り専用の集合(全モード共通)+ モードごとに積み増される書き込み系の集合」という2階建てで捉えると、lsとrmが同じacceptEdits mode下でも扱いが違う理由が見えてきます。前者は下限そのもの、後者はacceptEdits mode固有の積み増し分です。

この2階建て構造は他のモードにも当てはまります。auto modeは読み取り専用の集合に加えて、分類器のレビューを経たコマンドを追加で自動承認します。bypassPermissions modeはさらに広い範囲を確認なしで通します。共通しているのは、どのモードも「読み取り専用の集合」をまず下限として持ち、その上にモードごとの追加分を重ねる設計だという点です。設定でこの下限自体を書き換えることはできません。読み取り専用の集合はいわば土台であり、各モードの違いは土台の上に何を積むかの違いに過ぎません。

plan modeでも同じ集合がそのまま使われる

plan modeはClaudeがファイルを読み、読み取り専用のシェルコマンドを実行して調査する一方、ソースファイルの編集はしないモードです。ここで判定に使われる読み取り専用コマンドの集合は、Manual modeやauto modeと共通の同じ組み込みリストです。auto modeが利用可能でplan mode中に有効になっていれば、読み取り専用の集合に含まれないコマンドも分類器のレビューを経て実行されます。ただしこの場合の判定は、読み取り専用の集合とは別の仕組みです。

よくある質問

dontAsk modeでも読み取り専用コマンドは確認なしで動きますか

動きます。読み取り専用コマンドの集合は「どのモードでも確認プロンプトなしで実行される」設計のため、事前承認されていないツールを既定で拒否するdontAsk modeでも例外的に通ります。

読み取り専用コマンドの集合に自作のコマンドを追加できますか

追加できません。この集合はハードコードされた固定リストで、settings.json側からの拡張や変更には対応していません。特定のコマンドに確認を求めたい場合は、そのコマンド用のaskルールやdenyルールを追加する形で個別に上書きします。

git logやgit showのような閲覧系コマンドはすべて読み取り専用扱いですか

読み取り専用の形として扱われるgitコマンドの範囲は公式ドキュメント上「読み取り専用の形」とまとめられているだけで、対象コマンドの網羅的な一覧は公開されていません。git statusやgit diffのような明確に閲覧目的のサブコマンドは対象に含まれますが、判定に迷うコマンドがあればCtrl+Eでリスク説明を表示してから実行判断するのが確実です。

Bash(ls *)のようなallowルールを書けば読み取り専用の集合と何が変わりますか

読み取り専用の集合に含まれるコマンドはそもそもルールなしで確認が省略されるため、Bash(ls *)のようなallowルールを重ねて書いても挙動は変わりません。allowルールが意味を持つのは、読み取り専用の集合に含まれないコマンド(npm testやgit commitなど)を確認なしで実行させたいときです。ルールの書き方や優先順位の詳細は/permissionsコマンドで権限ルールとauto mode拒否を管理するにまとめています。

まとめ

Claude Codeの読み取り専用コマンド自動承認は、ls・cat・grepなどの固定リストに対して、どのモードでも一律で確認を省略する仕組みです。ただし判定基準は「コマンド名が読み取り専用の集合に入っているか」だけではありません。引用符なしグロブの展開先・dockerの接続先・fileが開くパス・Windowsのネットワークパス・解析可否という5つの観点も、Claude Codeは追加でチェックしています。これらの例外はどれも、コマンド名だけでは判定しきれない副作用や境界越えのリスクをカバーするためのものです。承認疲れを減らす目的で読み取り専用の集合に頼るなら、この5つの例外が自分のワークフローに当てはまらないかを一度確認しておく価値があります。