autoMode.classifyAllShellで全shellをClaude Codeの審査対象にする設定

autoMode.classifyAllShellでできること

autoMode.classifyAllShellをtrueにすると、auto mode(自動承認モード)が有効な間、BashとPowerShellの許可ルールがすべて一時停止します。どのshellコマンドも分類器の審査に回ります。

既定では、Bash(npm test)のような狭い許可ルールに一致したコマンドは分類器を通りません。ルールの接頭辞が想定していない引数やスクリプトパスが付いても、分類器はそのコマンドを見ません。このキーは、その抜け道を塞ぐためのものです。

なぜnpm testのような許可ルールが分類器を素通りするのか

auto modeは、許可ルールを全部止めているわけではありません。既定で止まるのは、任意のコードを実行できる広いルールだけです。Bash(*)のようなツール全体のルール、Bash(python*)のようなインタープリターやシェルラッパーの接頭辞ルール、shell経由で動くMonitorを名指しするルールがこれにあたります。パッケージマネージャーの実行コマンドと、Agentの許可ルールも、auto modeに入る時点で外れます。

対照的に、Bash(npm test)のように具体的なコマンドまで指定した狭いルールは、auto mode中も残ります。

auto modeがひとつの操作をどの順で判定するかを見ると、抜け道の位置がはっきりします。

classifyAllShellが働くのは1段階目です。Bash・PowerShellの許可ルールを一時的に外すので、狭いルールに一致していたコマンドも3段階目へ流れます。

Claude Codeのauto mode分類器は何を止めているかで扱った既定の遮断範囲は、この「狭いルールは対象外」という前提の上に成り立っています。classifyAllShellは、その前提を変える設定です。

classifyAllShellを有効にする設定

設定はautoModeオブジェクトにclassifyAllShellを足すだけです。書いてよいのはユーザー設定か管理設定で、v2.1.193で追加されたキーです。

{
  "autoMode": {
    "classifyAllShell": true
  }
}

autoModeは、環境情報(environment)、許可(allow)、緩い拒否(soft_deny)、厳格な拒否(hard_deny)の4配列と、このBoolean値を持つオブジェクトです。classifyAllShellの既定値はfalseで、対象はBashとPowerShellの2ツールです。ほかのツールの許可ルールは変わりません。

書いても効かない場所はどこか

autoModeを読むのは次の3つのスコープだけです。

プロジェクトの.claude/settings.jsonと.claude/settings.local.jsonは読まれません。リポジトリに同梱された設定やビルドステップが、独自の許可ルールを注入できてしまうのを防ぐためです。.claude/settings.local.jsonは、v2.1.207より前は読まれていました。

読まれない場所に書くと、エラーも出ないまま何も変わりません。v2.1.287で、空のHOMEと空の設定ディレクトリを使った一時環境で試すと次のとおりでした。claude auto-mode configは、各スコープの設定を反映した実効ルールをJSONで出すコマンドです。

# プロジェクトの .claude/settings.json に environment を1件書いた状態
claude auto-mode config | jq -c 'map_values(length)'
{"allow":17,"soft_deny":72,"hard_deny":1,"environment":21}
 
# 同じ内容を個人設定(settings.json)に書いた状態
claude auto-mode config | jq -c 'map_values(length)'
{"allow":17,"soft_deny":72,"hard_deny":1,"environment":1}

プロジェクト側に書いたenvironmentは件数に現れず、既定の21件のままです。個人設定に書いたときは、件数が1件に変わりました。--settingsで渡したJSONも同じく反映されます。

後者の「1件」にも注意が要ります。environment・allow・soft_deny・hard_denyは、配列に"$defaults"を含めない限り、組み込みの既定ルールを丸ごと置き換えます。既定の21件を残して足すなら、次のように書きます。

{
  "autoMode": {
    "environment": ["$defaults", "my-registry.example.com"]
  }
}

この書き方では、実効件数が22件(既定21件+追加1件)になりました。

各スコープの配列は結合されます。個人がエントリを足すことはできますが、managed settingsが配布したエントリは個人が削除できません。

有効化すると、分類器に届くコマンドはどう変わるか

適用範囲はauto modeが有効なセッションだけです。他の権限モードでは、許可ルールはこれまでどおり動きます。

代わりに払うコストはレイテンシです。許可ルールで即時に実行されていたコマンドが分類器の判定を待つようになり、shellコマンド1件ごとに分類器の呼び出しが1回数えられます。

呼び出しの課金には条件があります。サーバー側のチェックがセッションに届いていれば無料です。LLMゲートウェイやプロキシがその通信を落とすと、Claude Code自身が分類器へリクエストを送る形に切り替わり、Pro・Max・Team以外のアカウントではトークン使用量に計上されます。

それでも分類器を通らないコマンド

classifyAllShellをtrueにしても、分類器に届かない経路が残っています。

• rm・rmdirがrm -rf /やrm -rf ~のようなクリティカルパス(ルート直下・ホーム・作業ディレクトリとその親など)を対象にする場合。許可ルールは承認できず、分類器もこの種の削除を既定では見ません。auto modeでは、v2.1.281以降、端末なら2分のカウントダウン付きで承認を求めます。非対話実行・VS Code・Desktopでは、承認を求めずに拒否します。カウントダウンが答えのないまま3回時間切れになると、そのセッションでは以後のクリティカルパス削除を即座に拒否します。新しいメッセージを送ると数え直しです。環境変数CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT=1を起動環境に設定すると、auto modeのクリティカルパス削除は分類器に回ります
• permissions.denyに一致する操作。分類器に相談される前にブロックされ、classifyAllShellの値に左右されません
• permissions.askに一致する操作。Bash(git push *)のようにコマンドの内容で一致するルールは、auto mode中も権限プロンプトに回ります
• skillやスラッシュコマンドの中にあるインラインの!shellコマンド(v2.1.271以降)。分類器ではなく、defaultモードの権限ルールに従います。どのルールも決めないコマンドは、審査付きのツール呼び出しとして実行されます

逆に、既定のfalseでも分類器に回るケースがあります。サンドボックス実行で、Claudeがコマンドに「そのコマンドだけが使うホスト」を添えたとき(v2.1.271以降)です。ホスト付きのコマンドは、許可ルールに一致していても分類器で審査されます。

Claude Code auto modeブロック一覧にある既定の拒否ルール自体は変わりません。広がるのは、そのルールに届くコマンドの入り口です。

「allow」が指す仕組みは2つある

ここまでの「許可ルール」は、permissions.allow(Bash(npm test)のようにツールパターンで書く、分類器より手前で解決される許可)のことです。別にautoMode.allowという配列があり、こちらは分類器の内部でsoft_denyへの例外を自然文で書くものです。

分類器内部の優先順位は4段です。hard_denyは無条件でブロックし、次にsoft_denyが原則ブロックします。autoMode.allowはその例外として働き、最後に、ユーザーがメッセージで具体的に指示した操作は残るsoft_denyを上書きします。classifyAllShellが止めるのは前者のpermissions.allowだけで、autoMode.allowに書いた例外は有効化後も分類器の判断材料に残ります。

自分の環境で有効にするか迷ったとき

迷ったら、先に自分の許可ルールの広さを見ます。Bash(*)のような広いルールしか使っていない環境は、既定のままでも大半のコマンドが分類器に回るので、有効化しても差はほとんど出ません。npm testやnpm run buildのように限定したルールを多数登録している環境ほど、有効化で審査されるコマンドが増えます。

有効化後に拒否が増えたときの対処

審査対象が増えると、見慣れない拒否も増えます。拒否されたコマンドは/permissionsのRecently deniedタブに記録されます。拒否された操作でrキーを押すと再試行のマークが付き、ダイアログを閉じるとClaudeに「再試行してよい」と伝えるメッセージが送られて、会話が再開します。

ただし、分類器が判定そのものを出せなかった場合は別扱いです。分類器へのリクエストが別の安全チェックに拒否されたときや、応答を解釈できなかったときは、操作は拒否されますが、通知もRecently deniedへの記録も出ません。

拒否の原因によって、直し方は3つに分かれます。

同じ送信先への拒否が繰り返されるのは、分類器が文脈を持っていないためです。autoMode.environmentにその送信先を足すか、/auto-mode-setupで下書きを作らせます。

/auto-mode-setupはCLAUDE.mdと直近のセッションからエントリを起こすコマンドです。Pro / Max / Teamプランかつv2.1.228以降(Windowsはv2.1.233以降)が必要で、Claude Code on the Webでは実行できません。フラグ取得(feature-flag fetching)を切ったセッションでも使えません。条件を満たさない環境では、autoMode.environmentへの手書きが選択肢になります。

コマンドの中身をプログラムで受け取りたいときはPermissionDeniedフックを使います。

拒否の数にも上限があります。分類器が連続3回、またはセッション累計20回でブロックすると、auto modeは一時停止してプロンプトに戻ります。プロンプトの操作を承認すると再開します。この閾値は変更できません。審査対象を広げるほど、カウントに乗るコマンドも増えます。

累計のカウンターはセッション中ずっと残り、累計20回の上限で一時停止が起きたときだけリセットされます。auto modeとは別の安全チェックが分類器自身のリクエストを拒否した場合は、どちらの閾値にも数えません。-pの非対話実行(--permission-prompt-toolなし)では実行を止めず、その操作が実行されないだけでClaudeの作業は続きます。

設定が効いているかを確認する方法

確認の入口は2つあります。1つ目はコマンドラインです。

claude auto-mode config

出力はallow / soft_deny / hard_deny / environmentの4配列だけを持つJSONで、v2.1.287ではclassifyAllShellのキー自体が出ません。Boolean値そのものは、設定ファイルを直接見て確かめます。

2つ目は/permissionsのAuto modeタブです。Claude Codeの/permissionsコマンドで権限ルールとauto mode拒否を管理するで扱ったこの画面では、設定ファイルを開かずにルールを見たり編集したりできます。managed settingsや--settingsで渡された項目は読み取り専用で表示され、編集内容は~/.claude/settings.jsonに保存されます。v2.1.246以降が必要で、auto modeが使える状態のセッションにしか出ません。Claude Code v2.1.246でタブが追加されています。

claude auto-modeには、設定を扱うサブコマンドがほかに3つあります。v2.1.287の--helpでは、次のように説明されています。

resetが変えるのは~/.claude/settings.jsonだけです。managed settingsや--settingsで渡したautoModeは残ります。いずれもclassifyAllShell単体の値を出すものではありません。

まとめ

classifyAllShellの効き目は、登録済みの狭い許可ルールの数でほぼ決まります。代償は、判定待ちのレイテンシと、連続3回・累計20回の停止カウントに乗るコマンドが増えることです。