Claude Code Sandbox（サンドボックス）モードの安全な使い方【6つの隔離方式徹底比較・2026】

Claude Code を本番環境や重要なリポジトリで使い始めると、すぐに「どこまでエージェントに自律実行させるか」という問いにぶつかります。ファイルを読むだけなら問題ないが、rm -rf を含む Bash コマンドや外部ネットワーク通信を自動承認するのは別の話です。Claude Code の /sandbox コマンドは、Claude が実行するシェルコマンド（Bash など）を、OS が強制する境界の中で動かす「サンドボックス」を設定するコマンドです。有効にすると、コマンドが書き込める場所は作業フォルダなどに限られ、ネットワークは許可したドメインにしか出られなくなります。境界の外に出られないぶん、コマンド1つずつの確認を省くこともできます。本記事では、サンドボックスの設計思想から具体的な設定方法、CI/CD 連携、既知の限界まで実用的な視点で解説します。

権限設定の詳細は 権限設定／セキュリティ全般は セキュリティにまとめています。本記事はサンドボックスモードの使い方に絞ります。

Claude Code /sandbox コマンドとは——設計思想とパーミッション評価フロー

/sandbox コマンドは、サンドボックスの設定画面を開くコマンドです。サンドボックスは既定ではオフで、有効にすると、Claude が実行するシェルコマンド（Bash・PowerShell・Monitor と、そこから起動されるプロセス）が、OS の強制する境界の中で動きます。制限をかけるのは Claude Code ではなく OS なので、モデルがどんなコマンドを選んでも、許可された以上のことはできません。そのため、サンドボックスの中で動くコマンドは確認なしで実行させる設定（auto-allow）も選べます。確認が増えるのではなく、減らせるのがこの機能の特徴です。

/sandbox の始め方（3ステップ）

1. Claude Code の中で /sandbox を実行する：設定画面が開き、Mode・Overrides・Config の3つのタブが表示されます。Linux で任意の部品（seccomp フィルター）が入っていないときは Dependencies タブも出ます。Dependencies タブしか表示されない場合は、必須のパッケージが足りていません（下の「対応OSと Linux・WSL2 の準備」を参照）。
2. Mode タブでモードを選ぶ：auto-allow（サンドボックスの中で動くコマンドは確認なしで実行）か、regular permissions（サンドボックスの中でも通常どおり確認する）を選びます。
3. Claude にコマンドを実行させる：ビルドやテストを頼みます。許可していないドメインに接続しようとすると、通常の権限モード（Manual・acceptEdits・plan）では承認を求められます。auto モードや dontAsk モードでは、確認なしで拒否されます。

画面で選んだ内容は、そのプロジェクトの .claude/settings.local.json に保存されます。すべてのプロジェクトで有効にするには、~/.claude/settings.json に "sandbox": { "enabled": true } を書きます。

実際に Mode タブを開くと、選べるのは「Sandbox BashTool, with auto-allow」「Sandbox BashTool, with regular permissions」「No Sandbox」の3つです（既定は No Sandbox）。タブの見出しから選択肢へ入るには、↓キーを押します。

1番を選ぶと「Sandbox enabled with auto-allow for bash commands」と表示されます。このとき、そのプロジェクトの .claude/settings.local.json には "sandbox": { "enabled": true, "autoAllowBashIfSandboxed": true } が書かれました（この端末で確認した内容です）。

Overrides タブでは、サンドボックス内で失敗したコマンドを外で再試行できるかどうかを選びます。既定は「Allow unsandboxed fallback」（再試行できる）で、もう一方の「Strict sandbox mode」を選ぶと再試行を禁止できます。

サンドボックスが制限するもの

読み取りは既定では制限されない点に注意が必要です。認証情報のファイルを読ませたくない場合は、sandbox.credentials か denyRead を設定します（設定例は後半の節にあります）。

書き込みを許している場所の中でも、Claude Code の設定ファイル（.claude の settings ファイルや hooks・skills・agents・commands のフォルダ、.mcp.json）や .bashrc・.zshrc などは、サンドボックスの中のコマンドから書き換えられません。コマンドが自分で権限を広げたり、フックを仕込んだりするのを防ぐためで、allowWrite に書いても外せません（公式ドキュメントの「Protected paths」）。自分の環境でどのパスが対象かは、/sandbox の Config タブの「Denied within allowed」で確認できます。

サンドボックスの外で動くもの

サンドボックスが包むのはシェルコマンドだけです。次のものは外で動きます。

• ファイルと Web のツール：Read・Edit・Write・WebFetch・WebSearch は、サンドボックスではなく権限ルールに従います。denyRead を書いても Read ツールは止まらず、allowedDomains は WebFetch を制限しません。
• Claude Code が起動するほかのプロセス：フック、ローカルの MCP サーバー、ステータスラインのコマンドなどは、あなたと同じ権限で動きます。
• 自分で打ったコマンド：入力欄で ! を付けて自分で実行するコマンドは、ほとんどのセッションでサンドボックスの外で動きます。
• 除外したコマンドと、外での再試行：excludedCommands に一致するコマンドと、サンドボックス内で失敗したあとに Claude が「外で実行したい」と求めて承認されたコマンドです。

これらもまとめて境界の内側に置きたい場合は、Claude Code そのものをコンテナ・仮想マシン・sandbox runtime の中で動かします（次の節の比較表を参照）。

2つのモードと、サンドボックスの外での再試行

auto-allow と regular permissions のどちらを選んでも、ファイルとネットワークの制限は同じです。違うのは確認の有無だけです。auto-allow でも、次のものは確認や拒否の対象のままです。

• Deny ルールに一致するコマンドは常に拒否されます。
• 重要なパスを対象にした rm・rmdir は通常の確認に回ります。
• Bash(git push *) のように内容を指定した Ask ルールは、サンドボックス内のコマンドにも確認を出します。

サンドボックスと相性の悪いツールなどでコマンドが失敗すると、Claude はサンドボックスの外での再試行（dangerouslyDisableSandbox）を求めることがあります。通常のモードでは「Bash command (unsandboxed)」という確認が出るので、内容を見て判断します。この再試行そのものを禁止するには、"allowUnsandboxedCommands": false を設定します（/sandbox の Overrides タブでは「Strict sandbox mode」と表示されます）。

対応OSと Linux・WSL2 の準備

• macOS：OS に組み込まれた Seatbelt を使うため、追加のインストールは不要です。
• Linux・WSL2：bubblewrap（ファイルの隔離）と socat（通信をプロキシへ中継）が必要です。Ubuntu・Debian は sudo apt-get install bubblewrap socat、Fedora は sudo dnf install bubblewrap socat で入れます。インストール後は Claude Code を再起動します。
• Windows：Windows でそのまま動かした場合、コマンドはサンドボックスなしで実行されます。Windows で使うには、WSL2 の中で Claude Code を動かします。WSL1 では使えません（「Sandboxing requires WSL2」と表示されます）。

Ubuntu 24.04 以降では、標準の AppArmor の設定が bubblewrap の動作を止めることがあります。sysctl kernel.apparmor_restrict_unprivileged_userns が 1 を返す場合は、公式ドキュメントの手順で bwrap 用の AppArmor プロファイルを追加します。足りない部品は、下の画面のように /sandbox の Dependencies タブで確認できます。seccomp フィルターは任意の部品で、入れると Unix ドメインソケットの接続も止められます（npm install -g @anthropic-ai/sandbox-runtime で入ります）。必須の部品がそろったあとの再起動で、Dependencies タブは表示されなくなります。

なお既定では、部品が足りない・対応していない OS であるなどの理由でサンドボックスを起動できないと、コマンドはサンドボックスなしで実行されます。それを避けて起動自体を止めたい場合は、sandbox.failIfUnavailable を true にします。

サンドボックスが効いているかを確かめる

次の2つのコマンドを、Claude に実行させます。自分で ! を付けて打つとサンドボックスの外で動くため、確認になりません。

Claude が「サンドボックスの外で再試行したい」と求めてきたら、断ります。

次の画面は、この端末（Linux）でサンドボックスを有効にしたあと、2つのコマンドを Claude に実行させた結果です。touch は「Read-only file system」、curl は「Could not resolve host」で、どちらも表のとおりに失敗しました（ホームのパスはぼかしてあります）。

パーミッションルールとの関係：評価の順番

サンドボックスは OS の層で、パーミッション（権限）ルールは Claude Code の層で働きます。権限ルールは、ツールを実行する前に評価されます。Agent SDK の公式ドキュメントによると、評価は Hooks → Deny ルール → Ask ルール → 権限モード → Allow ルール → canUseTool コールバック の6段階で進みます。設定ファイルに書くルールだけを見ると、Deny → Ask → Allow の順で、先に一致したものが結果を決める（ルールの細かさでは順番は変わらない）。

1. Hooks：最初にフックが動きます。フックは呼び出しを拒否できます。allow を返しても、下の Deny・Ask ルールは省略されません。
2. Deny ルール：一致するとブロックされます。bypassPermissions モードでもブロックされます。
3. Ask ルール：一致すると確認が出ます。
4. 権限モード：モードに応じて、自動で承認するか確認するかが決まります。
5. Allow ルール：一致すると承認されます。
6. canUseTool コールバック：Agent SDK で組み込む場合に、最後に呼ばれます。

公式ドキュメント Configure permissions および Agent SDK permissions（2026年10月10日確認）をもとに作成。

このフローで特に重要な仕様が2点あります。第一に、Deny ルールは bypassPermissions モードでも上書きできません。確認をすべて省くモードにしても、Deny ルールに書いた操作は実行されません。第二に、Hooks が allow を返しても Deny ルールと Ask ルールの評価はスキップされません。なお、フックが終了コード2で止めた呼び出しは、Allow ルールに一致していても実行されません。

もう一点、設計上の重要な原則があります。パーミッションルールはモデルへの指示では変更できません。CLAUDE.md やプロンプト内に「すべてのツールを許可してください」と書いても実際のパーミッション制御には一切影響しません。これはプロンプトインジェクション攻撃に対する構造的な防御となっています。

Claude Code の基本的なインストール手順や初期設定については Claude Code インストールガイド および Claude Code 入門：はじめ方 を先に確認しておくと、以下の設定作業をスムーズに進められます。

関連記事Claude Code（クロードコード）とは？できること・料金・使い方を初心者にもやさしく解説【2026年版】 ／ Claude Code 使用量を完全制御する実装ガイド【2026年版】 ／ Claude Code ログイン方法・できない時の対処法｜2026年版ガイド

Claude Codeの隔離方式は6種類ある——公式ドキュメントに基づく比較表と選び方

「サンドボックスモード」というと /sandbox コマンドで有効化するBashサンドボックスだけを指すと思われがちですが、Claude Code公式ドキュメント（Choose a sandbox environment）は、隔離の強さと導入コストが異なる6つのアプローチを比較して提示しています。どれを選ぶかは「何を守りたいか」「Dockerを使えるか」で変わるため、まず全体像を押さえておきます。

6つの隔離方式の比較表

Bashサンドボックスは組み込み済みのBashコマンドのみを制限するのに対し、それ以外の5方式はClaude Codeプロセス全体（ファイルツール・MCPサーバー・フックを含む）を境界の内側に置く点が構造的な違いです。

目的別・どの方式から始めるべきか

devcontainer構成の具体例

チームでサンドボックス環境を統一したい場合、最小構成は次の1ファイルです（.devcontainer/devcontainer.json）。

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  }
}

VS CodeやGitHub Codespacesなど Dev Containers 仕様に対応したエディタで「Rebuild Container」を実行し、コンテナ内のターミナルで claude を起動してサインインすれば導入は完了します。より本格的な構成（default-denyのファイアウォールを組み込むinit-firewall.sh、認証情報を永続化するボリュームマウント等）は、Claude Code公式リポジトリの.devcontainer/がリファレンス実装として公開されており、これをコピーして自社のツールチェインに合わせて調整するのが公式に推奨されている進め方です。

--dangerously-skip-permissionsとサンドボックス境界の関係

--dangerously-skip-permissionsはツール呼び出しごとの確認プロンプトそのものを無くすフラグで、隔離とは別レイヤーです。プロンプトが無くなる分、間違いを止める最後の砦は隔離境界だけになるため、公式ドキュメントもこのフラグを使うセッションは必ずコンテナ・VM・sandbox runtimeのいずれかの内側で動かすことを推奨しています。なお、root権限やsudo経由でこのフラグを使うことはLinux/macOSでは拒否される仕様になっており（root権限＋無確認の組み合わせが最もリスクが高いため）、Dev containerでは非rootユーザーで動かす設計がこの制約を回避する形になっています。組織としてこのフラグ自体を禁止したい場合は、managed settingsのpermissions.disableBypassPermissionsModeで無効化できます。

1年以上の実運用でsandbox・パーミッション周りにハマった経験

監修者の河合継は1年以上Claude Codeを日常的に使用していますが、パーミッションを広く許可するほど「確認プロンプトが減って作業は速くなるが、想定外の変更が入るリスクを人間側で監視しづらくなる」というトレードオフに直面します。/sandboxや--dangerously-skip-permissionsで確認を減らす設定は便利な一方、それだけに頼るとファイルの誤編集や意図しない削除に気づくのが遅れる場面があり得ます。

この経験から、開発現場では権限モードの設定変更だけで終わらせず、Edit/Writeツールの実行前に自動でファイルをバックアップするPreToolUse Hook（2025年11月実装、.claude/backups/YYYY-MM-DD/にタイムスタンプ付きで保存）を運用に組み込み、「サンドボックス／パーミッションモードで実行を軽くする」ことと「フックで変更履歴を機械的に残す」ことを両輪にする多層防御の形に落ち着いています。サンドボックスは”コマンドが触れられる範囲”を制限する仕組みであって”実行された結果を後から追える”仕組みではないため、この2つは代替ではなく併用が前提になる、というのが実運用から得た実感です。

サンドボックスに関わるパーミッションモードの種類と選択基準

先に整理しておくと、/sandbox は権限モード（パーミッションモード）ではありません。公式ドキュメントも「/sandbox is not a permission mode」と明記しています。権限モードは「ツールの呼び出しを実行するか、先に確認するか」を決め、サンドボックスは「実行された Bash コマンドが何に触れられるか」を制限します。2つは別の層で、組み合わせて使います。権限モードは次の6種類です。

Claude Code パーミッションモード比較（公式ドキュメント Choose a permission mode をもとに作成・2026年10月13日確認）

モード名	確認なしで実行されるもの	向いている場面
default（画面上の表示は Manual）	読み取りだけ	すべての操作を自分で確認したいとき・重要な作業
acceptEdits	読み取り、ファイル編集、よく使うファイル操作のコマンド（mkdir・touch・mv・cp など）	自分でレビューしながらコードを直していくとき
plan	読み取り（編集は計画を承認するまで行わない）	コードを変える前に調べて計画を立てるとき
auto	すべて。ただし別のモデル（分類器）が操作を裏で確認する	長い作業・確認の回数を減らしたいとき
dontAsk	読み取りと、あらかじめ許可したツール。確認が必要になるものはすべて拒否	絞り込んだ CI やスクリプト
bypassPermissions	すべて（確認も安全チェックも行わない）	隔離されたコンテナ・仮想マシンの中だけ

dontAsk モードと bypassPermissions モードの使い分けは実装上の重要なトレードオフです。dontAsk は、確認が必要になる呼び出しをすべて自動で拒否します。実行されるのは、読み取りと、allow ルールに一致するものだけです。一方 bypassPermissions は確認と安全チェックを無効にしてすぐ実行するため、Deny ルールに書いていない操作はそのまま通ります。公式ドキュメントは、このモードをコンテナや仮想マシンなど隔離された環境だけで使うよう求めています。

サンドボックスとして安全に機能させるには、CI/CD パイプラインのような非対話環境では dontAsk と明示的な allow ルールの組み合わせが原則です。bypassPermissions は Docker コンテナなどで分離された実行環境において、かつ Deny ルールが厳密に設計されている場合にのみ検討します。手元のパソコンで確認の回数を減らしたいだけなら、公式ドキュメントが挙げている組み合わせは「default モードのまま /sandbox で auto-allow を選ぶ」です。Bash コマンドはサンドボックスの中で確認なしに動き、Deny ルールと、コマンドを指定した Ask ルールはそのまま効きます。

設定は settings.json の permissions の中に書きます。モードは defaultMode、ルールは allow と deny です。

{
  "permissions": {
    "defaultMode": "dontAsk",
    "allow": ["Bash(npm test)", "Bash(npm run lint)"],
    "deny": ["Bash(rm *)", "Bash(curl *)", "Bash(wget *)"]
  }
}

上記は CI 用途の典型的な設定例です。allow でテストとリントのみを許可し、deny でファイル削除と外部通信を明示的にブロックしている（作業フォルダの中の読み取りは、どのモードでも確認なしで実行される）。コマンドラインで指定する場合は --permission-mode dontAsk と --allowedTools を使う。Claude Code のスラッシュコマンド全般については Claude Code スラッシュコマンド完全ガイド を参照してください。

実運用のための設定チェックリストとCI/CDワークフロー連携

ここまでの内容を踏まえ、実際に Claude Code をチームや CI/CD パイプラインに導入する際の設定フローを整理します。

ローカル開発環境の設定手順

1. 初期モードは default で起動し、Claude がどのツールをどの頻度で呼び出すかを確認します。
2. /permissions コマンドで現在の allow/deny ルール一覧を確認します。初期状態ではほぼ空のはずです。
3. 繰り返し承認を求められる操作（例：npm test の実行）を allow ルールに追加します。「Yes, and don’t ask again」を選ぶと、そのルールはリポジトリの .claude/settings.local.json に保存され、以後そのリポジトリでは確認が出なくなります。
4. Bash コマンドの確認が多い場合は、/sandbox で auto-allow を選びます。サンドボックスの中で動くコマンドは確認なしになります。
5. 絶対に実行させたくない操作（例：Bash(git push *)）は、deny または ask のルールに書きます。auto-allow でもこのルールは効きます。
6. 認証情報のファイルや環境変数を、サンドボックス内のコマンドから見えないようにする（下の設定例）。

サンドボックスの設定例

サンドボックスの設定は settings.json の sandbox の中に書きます。次の例は、サンドボックスを有効にし、~/.kube への書き込みと2つのドメインへの通信を許可し、AWS と SSH の認証情報を読めなくし、docker compose だけをサンドボックスの外で動かす設定です（各キーは公式ドキュメントの例をもとに組み合わせたもの）。

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.kube"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    },
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ]
    },
    "excludedCommands": ["docker compose *"]
  }
}

• allowWrite：作業フォルダの外で書き込みを許す場所。kubectl や terraform のように決まった場所へ書くツールは、サンドボックスから外すより、ここで場所を足すほうが安全です。パスは /tmp/build（絶対パス）や ~/.kube（ホームからの相対）と、ふつうの書き方をします。
• allowedDomains：サンドボックス内のコマンドが接続してよいドメイン。github.com のような広いドメインを許可すると、そこを経由してデータを持ち出す経路になりうると公式ドキュメントは注意しています。
• excludedCommands：サンドボックスの外で動かすコマンド。一致したコマンドは、ファイルの制限もネットワークの制限も受けません。信頼できるツールに限り、パターンはできるだけ狭く書きます。

CI/CDで使うときの設定

公式ドキュメントが挙げている組み合わせは次の2つです。

1つ目の組み合わせ（dontAsk と --allowedTools）を、この端末で実際に実行した結果が次の画面です。許可した npm test は実行され、許可していない touch notes.txt は拒否されました（作業フォルダのファイルは作られていません）。

CI でサンドボックスを安全の条件にするなら、sandbox.failIfUnavailable を true にして「サンドボックスを起動できないときは実行しない」ようにし、sandbox.allowUnsandboxedCommands を false にして外での再試行を止めます。1回の実行だけ設定を変えるには、claude --settings '{"sandbox": {"enabled": true, "allowUnsandboxedCommands": false}}' のように --settings で渡します。組織の全員に必須にする場合は、同じキーを managed settings で配ります。

サンドボックスの中でコマンドが失敗するとき

サンドボックスの限界

公式ドキュメントは、サンドボックスはリスクを減らすが完全な隔離ではないとして、次の点を挙げています。

• 通信の中身は見ていない：プロキシは接続先のホスト名で許可・拒否を決めるだけで、暗号化された通信の内容は調べません。広いドメインを許可すると、持ち出しの経路になりえます。
• Unix ソケットの許可：/var/run/docker.sock を許可すると、Docker 経由でホスト全体に触れられるのと同じになります。
• 広すぎる書き込み許可：$PATH にある実行ファイルのフォルダや .bashrc・.zshrc への書き込みを許すと、別の経路でコードを実行される余地ができます。
• 対象はシェルコマンドだけ：ファイルツール・MCP サーバー・フックは対象外です。画面を操作する機能（computer use）も、隔離された環境ではなく実際のデスクトップで動きます。
• ファイルとネットワークの両方が要る：ネットワークの制限が無ければ SSH 鍵などを外へ送れてしまい、ファイルの制限が無ければ仕組みを書き換えてネットワークに出られてしまいます。設定を広げるときは、片方を無効にしていないかを確認します。

Claude Codeの全体像・仕組み・始め方は、Claude Codeとはでまとめて解説しています。

よくある質問

Q. /sandboxコマンドは何をしますか？
A. Claude Codeが実行するシェルコマンド（Bashなど）を、OSが強制する境界の中で動かす「サンドボックス」の設定画面を開きます。サンドボックスを有効にすると、コマンドが書き込める場所は作業フォルダなどに限られ、ネットワークは許可したドメインにしか出られなくなります。既定ではオフです。

Q. サンドボックスを有効にすると、確認は増えますか？減りますか？
A. 減らせます。/sandbox の Mode タブで auto-allow を選ぶと、サンドボックスの中で動くコマンドは確認なしで実行されます。境界の外に出られないことをOSが保証するためです。確認を残したい場合は regular permissions を選びます。どちらを選んでも、ファイルとネットワークの制限は同じです。

Q. /sandbox は権限モード（パーミッションモード）の一種ですか？
A. 違います。公式ドキュメントは「/sandbox は権限モードではない」と明記しています。権限モードは「ツールの呼び出しを実行するか、先に確認するか」を決め、サンドボックスは「実行されたBashコマンドが何に触れられるか」を制限します。両方を組み合わせて使います。

Q. サンドボックスはどのOSで使えますか？Windowsでも使えますか？
A. macOS・Linux・WSL2で使えます。macOSは追加のインストールが不要で、LinuxとWSL2では bubblewrap と socat を入れます。Windowsでそのまま動かした場合はサンドボックスなしで実行されるため、Windowsで使うにはWSL2の中でClaude Codeを動かします。WSL1では使えません。

Q. サンドボックスで守られないものは何ですか？
A. サンドボックスが包むのはシェルコマンドだけです。Read・Edit・Writeなどのファイルツール、WebFetch、MCPサーバー、フック、ステータスラインのコマンドは外で動き、権限ルールのほうで制御します。また既定では読み取りは制限されず、~/.ssh などの認証情報も読めるため、必要なら sandbox.credentials や filesystem.denyRead で読めなくします。

Q. サンドボックスの中で docker や jest が失敗します。どうすればいいですか？
A. docker はサンドボックスと両立しないため、sandbox.excludedCommands に “docker compose *” のようなパターンを書いて、そのコマンドだけ外で動かします。jest は watchman が両立しないので jest –no-watchman で実行します。許可していないホストへの接続で失敗する場合は、確認が出たときに承認するか、sandbox.network.allowedDomains に追加します。

Q. Claude Codeのパーミッション評価はどのような順序で行われますか？
A. Agent SDKの公式ドキュメントでは、Hooks → Denyルール → Askルール → 権限モード → Allowルール → canUseToolコールバック の6段階です。Denyルールに一致した呼び出しは、bypassPermissionsモードでもブロックされます。フックがallowを返しても、DenyルールとAskルールの評価は省略されません。

Q. Claude Codeの隔離方式は何種類ありますか？
A. 公式ドキュメントによれば6種類あります。Sandboxed Bash tool（/sandbox）、Sandbox runtime、Dev container、Custom container、Virtual machine、Claude Code on the webです。

Q. Bashサンドボックスと他の5方式の構造的な違いは何ですか？
A. Bashサンドボックスは組み込み済みのBashコマンドのみを制限するのに対し、それ以外の5方式（Sandbox runtime、Dev container、Custom container、Virtual machine、Claude Code on the web）はClaude Codeプロセス全体（ファイルツール・MCPサーバー・フックを含む）を境界の内側に置きます。

Q. –dangerously-skip-permissionsフラグとサンドボックス境界の関係はどうなっていますか？
A. このフラグはツール呼び出しごとの確認プロンプトを無くすもので、隔離とは別レイヤーです。公式ドキュメントは、このフラグを使うセッションは必ずコンテナ・VM・sandbox runtimeのいずれかの内側で動かすことを推奨しています。root権限やsudo経由での使用はLinux/macOSでは拒否される仕様です。

Q. パーミッションルールはCLAUDE.mdやプロンプトで変更できますか？
A. できません。パーミッションルールはモデルへの指示では変更できず、CLAUDE.mdやプロンプト内に「すべてのツールを許可してください」と書いても実際のパーミッション制御には一切影響しません。これはプロンプトインジェクション攻撃に対する構造的な防御となっています。

Q. dontAskモードとbypassPermissionsモードの違いは何ですか？
A. dontAskは、確認が必要になる呼び出しをすべて自動で拒否し、読み取りと、あらかじめ許可したルールに一致するものだけを実行します。bypassPermissionsは確認と安全チェックを無効にしてすぐ実行するモードで、公式ドキュメントはコンテナやVMなど隔離された環境だけで使うよう求めています。

Q. 組織として–dangerously-skip-permissionsフラグ自体を禁止するにはどうすればよいですか？
A. managed settingsのpermissions.disableBypassPermissionsModeを “disable” に設定します。サンドボックスを全員に必須にしたい場合は、managed settingsで sandbox.enabled・sandbox.failIfUnavailable を true、sandbox.allowUnsandboxedCommands を false にします。

---