サンドボックスが実際に制限しているのは何で、権限モードとの違いはどこにありますか？
公式ドキュメントは両者の分業を明確に示している：権限ルールはあらゆるツールが実際に実行される前に評価され、Bash、Read、Edit、WebFetch、MCPなどほぼすべてのツールタイプに適用され、「このツール呼び出しがそもそも実行を許可されるべきか」を決める。一方サンドボックスは、OSレベルで強制される境界であり、Bash、PowerShell、Monitorといった子プロセスを生成するコマンドにのみ適用され、「そのコマンドが実際に実行される際、どのファイルシステムパスとネットワークドメインに到達できるか」を決める。
両者は強制の仕方も異なる：権限の判断はコマンドが実行される前に、コマンド文字列そのものと（Auto Modeでは）クラシファイアの判断に基づいて行われる。サンドボックス境界はオペレーティングシステムが実行中のプロセスに直接強制するものであり、モデルが何を実行しようと選んだかに関係なく、プロセスが実際に何に触れたかだけを見る——承認されたコマンドが予想以上のことをしても、サンドボックスはそれでも有効に機能する。
サンドボックスはデフォルトでどの範囲のアクセスを許可し、それが足りない場合は拡大できますか？
デフォルトでは、サンドボックス化されたコマンドは現在の作業ディレクトリ、ユーザーごとの一時ディレクトリ、そして--add-dir、/add-dir、またはpermissions.additionalDirectoriesで追加されたディレクトリに書き込める。サブプロセス（kubectl、terraform、npmなど）がこの範囲外のパスに書き込む必要がある場合、sandbox.filesystem.allowWriteで特定のパスへのアクセスを許可できる。これらはOSレベルで強制され、サンドボックス内で実行されるすべてのコマンドとその子プロセスに適用される。
ネットワークアクセスの設計ロジックも似ている：コマンドが初めて新しいドメインへの接続を必要とするとき、Claude Codeは承認を求めるプロンプトを表示する。Auto Modeでは、Claudeはコマンドが必要とするホスト名をコマンド自体に直接添付し、クラシファイアがそれと一緒に審査する。サンドボックス化できないコマンド（許可されていないホストへの接続が必要な場合など）は通常の権限フローにフォールバックし、インターフェースはそのプロンプトのタイトルを通常の「Bash command」ではなく「Bash command (unsandboxed)」と表示するため、どのコマンドがサンドボックス外で実行されたかを区別できる。
サンドボックスには2つのモードがありますが、auto-allowと通常の権限モードはどう違いますか？
Auto-allowモード：コマンドがサンドボックス化できる限り、Claude Codeはそれをサンドボックス内で実行し、確認を求めずに自動的に承認する。サンドボックス化できないコマンドのみ通常の権限フローにフォールバックする。このモードでも、いくつかのケースでは依然として通常のフローが強制される：明示的なdenyルールは常に優先される。クリティカルパスを対象とするrmやrmdirコマンドは依然として通常の審査を受ける。Bash(git push *)のような内容を限定したaskルールは、コマンドがサンドボックス化されていても確認プロンプトを強制する。
通常の権限モード：すべてのBashコマンドは、サンドボックス化されていても通常の権限フローを通る——より強い制御力を持つが、より多くの承認が必要になる。ここで混同しやすいのは、サンドボックスのauto-allowと権限レイヤーのAuto Modeが完全に独立した2つのメカニズムであることだ：auto-allowがコマンドを通過させるのは、サンドボックス境界がすでにそれを封じ込めているからであり、Auto Modeがコマンドを通過させるのは、クラシファイアがその動作内容を安全と判断したからだ。両者は同時に有効化できるが、互いに代替するものではない。
サンドボックスを設定する際、最もよくある実際の誤設定の組み合わせは何ですか？
コミュニティ記事「Claude Code Permission Modes in 2026」は、直接的な失敗事例を記録している：ある設定がrun_commandというツールの呼び出しを許可したが、サンドボックスを安全なディレクトリツリーに制限することを忘れていた——結果として、エージェントはrm -rf /のようなコマンドを何の抵抗もなく実行できてしまった。ここでの重要な点は、「このツールの呼び出しを許可する」ことと「サンドボックスが実際に封じ込める範囲」は完全に別々の設定項目であり、前者を許可したからといって後者が絞られているとは限らないことだ。
同じ記事は別の事例も記録している：あるチームがコードレビューに毎回確認を求めるPromptモードを設定し、npm audit fixのリクエストを承認したが、サンドボックス設定では/node_modulesがroot権限で読み書き可能としてマウントされていた。権限審査は問題なく通過したが、サンドボックス分離はパッケージインストール時に発生しうる悪意ある挙動を、あるべき範囲内に封じ込めることができなかった。
公式ドキュメントが示す正当な使用例：LinuxまたはWSL2では、サンドボックスはファイルシステムの分離とネットワーク中継を強制するためにbubblewrapとsocatという2つのパッケージに依存するが、macOSは組み込みのSeatbeltフレームワークを直接使用し、追加のインストールは不要だ。依存パッケージの欠落やプラットフォームの非対応によりサンドボックスが起動できない場合、デフォルトの挙動は警告を表示してサンドボックスなしでコマンドを実行することだ。これを静かにサンドボックスなしへフォールバックさせるのではなく、明確に失敗させるには、別途sandbox.failIfUnavailableをtrueに設定する必要がある——これは通常、セキュリティゲートとしてサンドボックス化を強制する必要がある管理されたデプロイ環境で使われる設定だ。
利点は、OSレベルで強制される境界であり、モデルが何を実行しようと選んだかではなく、プロセスが実際に何に触れたかだけを見るため、承認されたコマンドが予想以上のことをしても止められる、コマンド文字列を審査するだけよりも硬い防御線になることだ。代償はカバー範囲の限界であり、子プロセスを生成するツールタイプしか管理できず、その設定項目（ファイルシステム、ドメイン、モード）は複数の独立したスイッチに分散している。本当に保護を強化するには、サンドボックス設定と権限ルールの両方を同時に確認する必要があり、サンドボックスを導入しただけで一度に完結するものではない。