Claude Code には**「承認を自動化する」ように見える仕組みが複数あり、名前も似ているため混同されがちです——パーミッションモード(Manual / acceptEdits / plan / bypassPermissions)、auto mode、そしてサンドボックスの auto-allow モード**。「auto」だらけで、どれがどれを制御しているのか分かりにくい。実はこの 3 つは制御している対象がそれぞれ違い、独立して組み合わせられます。本記事では、これまで個別に扱った内容を踏まえて、3 者をきれいに区別します。
到達点
- 3 つの「自動化」がそれぞれ何を制御するかを 1 枚で把握する
- 「プロンプトの代わりに何が働くか」で 3 者を見分ける
- サンドボックス auto-allow でも確認が出るケースを知る
- escape hatch と strict モードの位置づけ
- 3 者を独立して組み合わせる考え方
まず 1 枚で区別する
公式の整理に沿うと、要点は 「何を制御するか」 と 「プロンプトの代わりに何が働くか」 の 2 軸です。
| 仕組み | 何を制御するか | プロンプトの代わりに働くもの |
|---|---|---|
| パーミッションモード | 各ツール呼び出しを実行するか・確認するか | モードごとの規則(Manual は確認、acceptEdits は編集自動 等) |
| auto mode | 各ツール呼び出しを実行してよいか | classifier(安全性を審査) |
| サンドボックス auto-allow | Bash コマンドが実行後に何にアクセスできるか | サンドボックスの境界そのもの(OS が封じ込め) |
ポイントは、**パーミッションモードと auto mode は「その呼び出しを走らせるか」**を、サンドボックスは「走った Bash が何に触れるか」を制御している、というレイヤーの違いです。前者は実行前の判断、後者は実行中の OS 強制。
① パーミッションモード
「その操作を実行するか、まず確認するか」を切り替えます。詳細は 別記事 のとおり。
- Manual(旧 default):承認が要る操作ごとに都度確認
- acceptEdits:ファイル編集は自動、それ以外は確認
- plan:読み取り専用で計画のみ
- bypassPermissions:確認をすべてスキップ
これは人間(またはモード規則)が実行可否を決める層です。
② auto mode
各ツール呼び出しを、classifier(分類器)が審査して可否を判断します。人間の都度確認の代わりに、モデルとは別の審査が入るのが特徴。ここに自然言語ルール(environment / allow / soft_deny / hard_deny)で方針を与えられます(auto mode の hard_deny)。
パーミッションモードが「モードで一律に決める」のに対し、auto mode は「呼び出しごとに審査する」——プロンプトの代わりが classifier なのが違いです。
③ サンドボックス auto-allow
ここが最も混同されます。サンドボックスの auto-allow モードは、Bash コマンドをサンドボックスの境界内で走らせるから自動承認する、という仕組みです。「審査して OK」ではなく、「OS が封じ込めているから、暴れても外に影響しない → だから確認不要」という発想。
auto-allow は [auto mode] とは別物。auto-allow はサンドボックスの境界がコマンドを封じ込めるから Bash を自動承認する。auto mode は classifier がアクションを審査する。両者は独立して働き、組み合わせられる。
auto-allow でも確認が出るケース
「auto-allow = 全部素通り」ではありません。境界の外に出うる危険は、auto-allow でも確認が出ます。
- 明示的な deny ルールは常に尊重される
/・ホームディレクトリ・重要システムパスを狙うrm/rmdirは確認が出るBash(git push *)のような content-scoped な ask ルールは、サンドボックス化されていても確認を強制する- 一方、素の
Bash(=Bash(*))の ask ルールは、サンドボックス化されたコマンドではスキップされる(境界があるため)。fallback したコマンドには適用
escape hatch と strict モード
サンドボックスで走れないコマンド(非対応ツールや未許可ホストが必要なもの)は、失敗するだけでなく:
- Claude が失敗を分析し、
dangerouslyDisableSandboxパラメータでリトライすることがある。これはサンドボックス外で走るので、**通常の権限フロー(=確認)**を通る - この escape hatch を無効化するのが
allowUnsandboxedCommands: false(/sandboxの Overrides で Strict sandbox mode)。設定するとdangerouslyDisableSandboxは完全に無視され、すべて sandbox 内で走るかexcludedCommandsに明示しない限り実行されない
3 者は独立・組み合わせ可能
重要なのは、3 つが別レイヤーなので組み合わせられること。たとえば:
- auto mode + サンドボックス auto-allow:classifier が呼び出しの可否を審査し、通った Bash は OS 境界で封じ込めて自動実行——「審査 × 封じ込め」の二段
- acceptEdits + サンドボックス:編集は自動承認しつつ、Bash は境界内で走らせる
「auto mode を使えばサンドボックスは要らない」わけでも、その逆でもありません。実行前の判断(モード/classifier)と、実行中の封じ込め(サンドボックス)は役割が違うので、無人度・リスクに応じて重ねます。
どう選ぶか
- 手元で普通に使う:Manual(都度確認)。安全側の既定
- 編集を任せたい:acceptEdits + サンドボックス(境界内で Bash 自動)
- 無人・CI で回す:auto mode(classifier 審査)+ サンドボックス auto-allow +
hard_denyで危険を封じる - 厳格に締める:Strict sandbox(
allowUnsandboxedCommands: false)+ 読み取り/ネットワークの締め(credentials / network)
まとめ
Claude Code の「自動で進む」は 3 レイヤーに分かれます——パーミッションモード(実行するか/確認するか)、auto mode(classifier が可否を審査)、サンドボックス auto-allow(OS 境界で封じ込めて自動承認)。見分ける鍵は 「プロンプトの代わりに何が働くか」:モード規則か、classifier か、サンドボックスの境界か。
勘所は 3 つ — 実行前の判断(モード/auto mode)と実行中の封じ込め(サンドボックス)は別レイヤーと理解する、auto-allow でも危険操作は確認が出る、無人度に応じて 3 者を重ねる。名前の「auto」に惑わされず、どのレイヤーで何を自動化しているかを意識できると、Claude Code を安全に・不要な確認なく回せます。