autoMode.classifyAllShellで全shellをClaude Codeの審査対象にする設定
autoMode.classifyAllShellは、npm testのような狭い許可ルールが分類器を素通りする抜け道を塞ぎ、auto mode中の全shellコマンドを審査対象にする設定です。
autoMode.classifyAllShellでできること
autoMode.classifyAllShellをtrueにすると、auto mode(自動承認モード)が有効な間、BashとPowerShellのコマンドがすべて分類器の審査に回ります。既定では、Bash(npm test)のような狭い許可ルールに一致したコマンドは分類器を素通りします。そのルールが想定していない引数やスクリプトパスが紛れ込んでも、チェックされません。
このキーは、その素通りの経路を塞ぐためのものです。1文で言えば、auto mode中は自分の許可ルールを一時的に全部止めて、どのshellコマンドも分類器に見せる設定です。
なぜnpm testのような許可ルールが分類器を素通りするのか
auto modeは、既定ではすべての許可ルールを止めているわけではありません。中断対象になるのは、任意のコードを実行できる広いルールだけです。Bash(*)のようなツール全体を許可するルールや、Bash(python *)のようなインタープリター・シェルラッパーの接頭辞ルールがこれにあたります。加えて、shell経由で動くMonitorを名指しするルールも同様に中断されます。
一方、Bash(npm test)のように具体的なコマンドまで指定した狭いルールは、分類器より先に解決されます。ここが抜け道です。ルールの接頭辞が想定していない引数やフラグが実行時に付いても、分類器はそのコマンドを見ません。既存の許可ルールを丁寧に書いていても、書いた時点で想定できなかった実行パスまでは守れないということです。
Claude Codeのauto mode分類器は何を止めているかで扱った既定の遮断範囲は、この「狭いルールは対象外」という前提の上に成り立っています。classifyAllShellは、その前提そのものを変える設定です。
対象はBashとPowerShellの2ツールに限られます。ほかのツールに対する許可ルールは、classifyAllShellを有効にしても影響を受けません。shell経由でコマンドを実行するツールだけが、この設定の対象になると考えるとわかりやすくなります。
classifyAllShellを有効にする設定
設定はユーザー設定または管理設定の autoMode オブジェクトに classifyAllShell を追加するだけです。
{
"autoMode": {
"classifyAllShell": true
}
}autoModeは環境情報(environment)、許可(allow)、緩い拒否(soft_deny)、厳格な拒否(hard_deny)の各配列と、このBoolean値を持つオブジェクトです。classifyAllShellはそのうちの1キーで、既定値はfalseです。設定はautoModeが読み込まれるスコープならどこでも有効になります。
どの設定ファイルに書けば読み込まれるか
classifyAllShellを含むautoModeブロックは、書く場所によって読み込まれるかどうかが変わります。分類器がautoModeを読むスコープは次の3つです。
| スコープ | ファイル | 用途 |
|---|---|---|
| 個人 | ファイル~/.claude/settings.json | 用途自分だけの信頼済みインフラ・個人設定 |
| 組織全体 | ファイルManaged settings | 用途全開発者への配布 |
| 実行ごと | ファイル--settingsフラグ / Agent SDKのインラインJSON | 用途自動化呼び出しごとの上書き |
プロジェクト側の.claude/settings.jsonや.claude/settings.local.jsonには書いても読み込まれません。リポジトリに同梱された設定やビルドステップが独自の許可ルールを注入できてしまうのを防ぐためです。v2.1.207より前は.claude/settings.local.jsonも読んでいましたが、この抜け道も塞がれました。classifyAllShellをプロジェクト単位で試したいだけのつもりで.claude/settings.jsonに書くと、何も変わらないまま気づかないという事態になります。
各スコープの値は結合されます。個人がenvironment / allow / soft_deny / hard_denyに項目を足すことはできますが、managed settingsが配布した項目を個人が削除することはできません。
classifyAllShellが変えないもの
classifyAllShellは許可ルールの扱いを変える設定であり、分類器より手前で効く仕組みまでは変えません。permissions.denyに一致する操作は、分類器に相談される前にブロックされます。この判定はclassifyAllShellの値に関わらず常に最優先です。同様に、permissions.askに一致する操作はauto mode中でも必ずプロンプトを出します。分類器が自動承認できる余地はありません。
つまりclassifyAllShellが広げるのは「分類器がどこまでのコマンドを見るか」であって、「分類器より上位の拒否・確認ルールをどう扱うか」ではないということです。恒久的に止めたい操作はpermissions.deny、毎回確認したい操作はpermissions.askに書くのが本筋で、classifyAllShellはその外側にある狭い許可ルールの抜け道を塞ぐための補完です。
「allow」という言葉が指す仕組みは2つある点にも注意します。ここまでの「許可ルール」はpermissions.allow(Bash(npm test)のようにツールパターンで書く、分類器より手前で解決される許可)を指しています。これとは別にautoMode.allowという配列があり、こちらは分類器の内部でsoft_denyルールへの例外を自然文で記述するものです。分類器内部の優先順位は、hard_denyが無条件のブロック、次にsoft_denyが原則ブロック、autoMode.allowがその例外、最後にユーザーの明示的な意図が残るsoft_denyをなお上書きする、という4段構成になっています。classifyAllShellが一時停止するのは前者のpermissions.allow側だけで、autoMode.allowに書いた例外は有効化後も分類器の判断材料として働き続けます。
有効化で何が変わるか
適用範囲はauto modeが有効なセッションに限られます。他の権限モードでは、許可ルールはこれまでどおり動きます。
| 状態 | 分類器を通るコマンド | 素通りするコマンド |
|---|---|---|
既定(false) | 分類器を通るコマンドBash(*)等の広いルール・インタープリターのラッパー・Monitorを名指しするルール | 素通りするコマンドBash(npm test)のような具体的な許可ルールに一致するコマンド |
classifyAllShell: true | 分類器を通るコマンドauto mode中のBash・PowerShellコマンドすべて | 素通りするコマンドなし(セッション中の全shell許可ルールを一時停止) |
代わりに支払うコストはレイテンシです。これまで許可ルールで即時実行されていたコマンドも分類器の判定を待つようになり、shellコマンド1件ごとに分類器呼び出しが1回増えます。カバレッジとレイテンシのトレードオフだと捉えるのが実態に近い設定です。
Claude Code auto modeブロック一覧で触れた既定の拒否ルール自体は変わりません。変わるのは「そのルールにどのコマンドが到達するか」という入り口の広さです。
classifyAllShellが向く場面、向かない場面
| 場面 | 有効化の目安 | 理由 |
|---|---|---|
| 外部リポジトリや未検証のスクリプトを扱うセッション | 有効化の目安◎ | 理由許可ルールが想定していない引数を拾える価値が大きい |
| CIやバッチで決まったコマンドしか流さない環境 | 有効化の目安△ | 理由許可ルールの棚卸しが先。分類器呼び出しの増加が効きにくい |
| 個人環境で応答速度を優先したい作業 | 有効化の目安△〜✕ | 理由shellコマンドのたびに判定待ちが入り、体感速度が落ちる |
判断に迷うときは、まず自分の許可ルールがどれだけ広いかを見直すのが順番として先です。Bash(*)のような広いルールしか使っていないなら、既定のままでもほとんどのコマンドは分類器に回ります。逆にnpm testやnpm run buildのように限定した許可ルールを多数登録している環境ほど、classifyAllShellを有効にする効果は大きくなります。
有効化後に増える分類器の判定への対処
classifyAllShellを有効にすると、これまで許可ルールで素通りしていたコマンドも分類器の判定対象になります。判定は許可・拒否だけでなく「保留」も返るため、見慣れない拒否や保留が増えることがあります。
拒否されたコマンドは/permissionsのRecently deniedタブで確認できます。denyされた操作にrキーを押すと再試行としてマークされ、ダイアログを閉じるとClaudeへ再試行してよいと伝えるメッセージが送られてセッションが再開します。対処の選択肢は3つです。
- タスク全体を通して必要になる送信先(パッケージレジストリ・内部ドメイン・リポジトリホストなど)は
autoMode.environmentに追加する - 今後もレビューなしで実行したいコマンドは
allowルールに追加する - 今回だけ意図した一回限りの操作なら、次のメッセージでその意図を伝えて再試行させる
同じ送信先への拒否が繰り返されるなら、たいてい分類器が文脈を持っていないだけです。autoMode.environmentにその送信先を足すか、/auto-mode-setupを実行すると、プロジェクトのCLAUDE.mdや直近セッションのコマンド履歴からエントリの下書きを作ってくれます。ただし/auto-mode-setupはPro / Max / Teamプランかつv2.1.228以降(Windowsはv2.1.233以降)が必要で、Claude Code on the Webでは実行できません。条件を満たさない環境では、autoMode.environmentへの手書き追加が唯一の選択肢になります。プログラムから拒否に反応したい場合はPermissionDeniedフックを使います。
設定が効いているかを確認する方法
設定ファイルを保存したら、autoModeまわりの実効設定を確認する手段が2つあります。1つはコマンドラインです。
claude auto-mode configこのコマンドは、allow / soft_deny / hard_deny / environmentの実効ルールをJSONで表示します。classifyAllShellのような単一のBoolean値そのものの確認は、設定ファイルの中身を直接見るほうが確実です。
もう1つは/permissionsのAuto modeタブです。Claude Codeの/permissionsコマンドで権限ルールとauto mode拒否を管理するで扱ったこの画面から、設定ファイルを開かずにルールを見たり編集したりできます。ただしこのタブはv2.1.246以降が必要で、auto modeがセッションで使える状態のときにしか表示されません。Claude Code v2.1.246でauto modeの可視化が強化されたのは、このタブの追加が背景にあります。
関連コマンドとして、claude auto-mode defaultsは組み込みルールをJSONで表示し(--labelでの絞り込みはv2.1.208以降)、claude auto-mode critiqueは自作したallow / soft_deny / hard_denyルールをAIがレビューします。設定を初期状態へ戻したいときはclaude auto-mode reset(v2.1.212以降)がユーザー設定ファイルからautoModeセクションを削除します。いずれもclassifyAllShell単体の値を直接表示するものではなく、周辺のルール群を確認・管理するための道具です。
まとめ
autoMode.classifyAllShellは、auto mode中に狭い許可ルールが分類器を素通りする抜け道を塞ぎたいときに有効にする設定です。外部のリポジトリや未検証のスクリプトを扱うセッションでは効果が大きく、決まったコマンドしか流さない自動化環境では、まず許可ルールそのものの見直しを先にする価値があります。有効化にはv2.1.193以降が必要で、適用はauto modeが有効な間だけです。設定を書く場所は~/.claude/settings.jsonかManaged settingsに限られ、プロジェクト側の設定ファイルには効きません。設定後はclaude auto-mode configや/permissionsのAuto modeタブで、狙いどおりの実効ルールになっているかを確認します。