AIコーディングエージェントのサンドボックス実装比較 — Claude Code・Codex・Cursor・Devin

AIコーディングエージェントのサンドボックスは何を止めるためにあるか

Claude Code・Codex CLI・Cursor・Devinはいずれも、エージェントが実行するシェルコマンドをOSレベルで隔離する仕組みを持ちます。承認プロンプトが「実行前に人間が止める」層だとすれば、サンドボックスは「承認をすり抜けたコマンドが暴走しても被害を局所化する」層です。この2層は別物で、権限モデル(誰が承認するか)の比較はAIコーディングエージェントの権限モデル比較にまとめています。本記事はその先、サンドボックスの実装そのもの — どのOS機能を使い、ファイルとネットワークをどう制限し、隔離に失敗したときに何が起きるか — をツール別に突き合わせます。

4ツールを並べると、実装は大きく2系統に分かれます。Claude Code・Codex CLI・Cursorはローカルマシン上でOSのセキュリティ機構を直接呼び出す方式です。Devinは既定がクラウドVM上のセッションで、CLIのローカルサンドボックスは別に用意されています。Claude CodeとCursorにもクラウド実行はありますが、ここで比べるのはローカル側の隔離です。

結論: 4ツールのサンドボックスを一覧で見る

ネットワークの既定値は、Devin CLIだけが制限なし(network_modeはfull)です。他の3ツールは閉じた状態か承認制から始まります。各項目の根拠は以降の節にあります。

比較する4つのツールとサンドボックスの位置づけ

比較対象を先に固定します。いずれも「エージェントが実行するコマンドの読み書き範囲と通信先を制限する」機構ですが、動く場所と管理の主体が異なります。

Claude Codeのサンドボックスは/sandboxコマンドで有効化するBash・PowerShell・Monitorのコマンドを囲う隔離層です。Read・Edit・フック・MCPは対象外です。macOS・Linux・WSL2で動き、ネイティブWindowsは非対応です。Codex CLIはOpenAIが提供するCLIで、sandbox_modeの設定値(read-only・workspace-write・danger-full-access)に連動してOSレベルの隔離を切り替えます。Cursorはエディタ本体に組み込まれたサンドボックスで、Run Modesという承認方式の内部で「サンドボックス実行できるコマンドは自動許可する」という形で使われます。Devinは管理下のクラウドVM上でセッションが動くのが既定で(自前インフラのアウトポストもあります)、CLIには別途--sandboxフラグによるローカルOS隔離があります。

サンドボックスを比較する5つの評価軸

比較軸は次の5つです。①どのOS機能を使うか(プラットフォームごと) ②ファイルシステムの既定の読み書き範囲 ③ネットワークの既定値と許可リストの与え方 ④隔離に失敗したときに実行を続けるか止めるか ⑤隔離の単位がローカルプロセスかクラウドVMか。

とくに④は見落とされがちですが、運用上の意味が大きく異なります。「使えなければ非サンドボックスで実行する」設計と、「使えなければ起動を拒否する」設計とでは、CI環境やコンテナ内でツールを動かしたときの安全側の挙動が逆になります。

OSプリミティブとプラットフォーム対応の比較表

ネイティブWindows上でOSレベルの隔離を持つのはCodex CLIだけです。WSL2に加えて、専用のWindowsサンドボックス実装([windows] sandbox = "unelevated"または"elevated")を持つ点が独自です。なおWSL1は0.115以降で非対応です。

Claude CodeはネイティブWindowsでは非サンドボックスで動くため、隔離したければWSL2で実行します。CursorはWSL2の中でLinux版サンドボックスを動かし、ネイティブ実装ではありません。Devin CLIはWindowsで--sandboxを付けるか、管理者がRequiredに設定していると、起動に失敗します。

隔離できないときの既定挙動は、ツールごとに大きく割れます。

Codex CLIはコンテナ内でbwrap/seccompが動かないことがあります。その場合はコンテナ側で隔離し、--sandbox danger-full-accessに切り替えるのが運用者側の対処です。

サンドボックス必須ポリシーを敷く管理者にとっては、止める側の挙動が「ポリシーが黙って無効化される事故」の防止策になります。

サンドボックスの外へ意図的に逃がす仕組みにも違いがあります。Claude CodeはexcludedCommandsで特定コマンドをあらかじめサンドボックス外に出せるほか、dangerouslyDisableSandboxパラメータによる再試行が通常の権限フローに戻ります。Bash(dangerouslyDisableSandbox:true)のaskルールを置けば、再試行のたびに確認を求められます。Devin CLIはsandbox.excludedのallow/ask/denyルールで対象コマンドを指定し、どのルールにも一致しないコマンドはサンドボックス内に留まります(fail-closed)。Cursorはサンドボックス外で実行するコマンドをその場で明示し、承認プロンプトで確認を求めます。dockerなど非対応コマンドの設定例はsandbox.excludedCommandsの使い方にまとめています。

ファイルシステムの既定範囲とプロテクトパス

読み取り範囲を既定でほぼ全体に開けたまま書き込み先だけを絞っているのはClaude CodeとDevin CLIで、Cursorは.git/configなどの保護パスへの書き込みを制限します。

Claude Codeは既定で書き込みを作業ディレクトリ・追加ディレクトリ・セッション一時ディレクトリに限定する一方、読み取りはホームディレクトリの認証情報ファイル(~/.aws/credentialsや~/.ssh/)を含め、コンピューター全体にほぼ開いています。読み取りを絞りたい場合はsandbox.filesystem.denyReadやsandbox.credentialsを明示的に設定する必要があります。Cursorは.git/config・.git/hooks・.vscode・.cursorignore・Cursorの機密設定ファイルを保護パスとして既定で守ります。.cursorignoreの対象はLinuxで読み取りも変更もできません。Devin CLIは書き込み可能な範囲をワークスペースとWrite(...)スコープに絞る一方、読み取りはRead(...)のdenyルールで指定したパスを除きほぼ全体に開いています。既定の広さはClaude Codeと同じ発想で、隠したいパスをdenyルールで明示する方式です。

Codex CLIはworkspace-writeモードでも書き込み可能なルート配下の.git・.agents・.codexディレクトリを読み取り専用として保護します。この保護は書き込み許可パスの内側にも及ぶため、「作業ディレクトリを丸ごと書き込み可にしたのに.gitだけは触れない」という挙動になります。

ネットワーク制御の実装比較

既定でネットワークを開いているのはDevin CLIだけで、Codex CLIとCursorは閉じた状態から許可リストで開き、Claude Codeは未許可ドメインへの初回アクセスで承認を求めます。

Cursorの組み込みデフォルトは実装の癖が出ている部分です。npmjs.com・pypi.org・crates.io・docker.io・github.comなど、主要言語のパッケージレジストリとOSディストリビューションのミラーをまとめて許可する一覧をあらかじめ持っており、「サンドボックス設定を書かなくてもよくあるビルドコマンドは動く」ことを優先した設計です。Claude Codeの許可ドメインは空から始まり、初めて必要になった時点で承認を求められます。自動モードでは、コマンド自身が必要なホストを申告して分類器が審査する流れです。

承認ダイアログを挟みたくない運用では、Claude CodeのstrictAllowlistが有効です。trueにすると、許可リストの外のホストへの接続をプロンプトなしで拒否します。逆にbypassPermissionsモードでは、許可リスト外のホストにも通信できます。止めるにはstrictAllowlistかallowManagedDomainsOnlyをオンにするか、deniedDomainsで拒否します。

公式ドキュメントが「現状不安定な機能」と明記しているのはDevinのネットワークフィルタリングです。安定運用が必要ならアカウント担当者に確認するよう案内されています。

Devinはクラウド上のセッションをセキュリティプロファイルで統制する

Devinの実行環境は、CLIの--sandboxフラグによるローカルOS隔離だけでは説明できません。本来のセッションはクラウドVM上で動きます。Claude Codeにも、Anthropicがホストするフルのオペレーティングシステムで動くクラウドセッションがあります。Cursorにも、専用マシンで動くCloud Agentsがあります。

Devinは「セキュリティプロファイル」を組織・自動化・セッション単位で割り当てます。中身は、ネットワークポリシー・MCPサーバーの許可リスト・Gitアクセスレベル(読み取り専用/フル)・GitHub CLIトークンの有無です。

プロファイルには「推奨(下位が上書き可能)」と「必須(下位は交差方向にしか変更できない)」の2段階があり、必須プロファイルではセッション中に承認したネットワークアクセスさえ、プロファイルが許可する範囲との交差に自動的に絞り込まれます。ファイルとネットワークをOSプリミティブで直接絞るローカル側の隔離に対し、Devinのプロファイルはポリシー合成による多段防御という設計です。

設定を書く前に動作確認する手段の差

サンドボックス設定は「書いたつもりで効いていない」事故が起きやすい領域なので、実際にコマンドを1つ試して確認できる手段があるかどうかも実務では重要です。ここでも4ツールの用意は揃っていません。

Codex CLIはcodex sandboxというサブコマンドを持ち、指定したコマンドを実際にサンドボックス内で動かして結果を確認できます。プラットフォームごとにエイリアスがあり、macOSではcodex sandbox seatbelt、Linuxではcodex sandbox landlockとも呼べます。

# Linux環境でechoコマンドをサンドボックス越しに実行して確認する
codex sandbox linux -- echo hello

Claude Codeは/sandboxコマンドでパネルを開き、Configタブで解決済みの設定(拒否パスや許可ドメインの一覧)を確認できますが、任意のコマンドを試し打ちする専用サブコマンドは持ちません。実際にコマンドが通るかどうかは、Claudeに実行させて結果を見るのが基本です。

Cursorには試し打ち専用のコマンドがありません。環境変数CURSOR_SANDBOX(macOSではseatbelt、Linuxではnative)が設定されているかで、そのコマンドがサンドボックス経由だったかを事後に見分けます。CursorのCLIには、設定を開く/sandboxと、モードを指定する--sandbox <mode>があります。

Claude Codeで隔離失敗時に起動を止めるまで

Claude Codeの既定は「隔離できなくても続行」なので、強制したい場合は設定を足します。設定は3段階です。手順1・2は/sandboxのパネルか--settings、手順3は設定ファイルか--settingsで指定します。

claude --settings '{"sandbox": {"enabled": true, "allowUnsandboxedCommands": false, "failIfUnavailable": true}}'

allowUnsandboxedCommands: falseを管理設定か--settingsで入れると、サンドボックスは管理者必須の扱いになります。リポジトリ側の設定ファイルがサンドボックスを緩める項目(excludedCommandsを含む)は無視されます。設計の詳細はClaude Codeのサンドボックス設計、ファイル隔離だけを外す設定はsandbox.filesystem.disabledの使い方にあります。

CLI自身が「サンドボックスの中で使う」前提を示している箇所

v2.1.287のclaude --helpでは、権限チェックを全部飛ばすフラグに次の注意書きが付いています。

--dangerously-skip-permissions  Bypass all permission checks.
                                Recommended only for sandboxes with no
                                internet access.

--allow-dangerously-skip-permissionsにも同じ文言が付きます。「サンドボックス」の語はここでは、OSプリミティブによる隔離というより、外部と通信できない隔離環境全般を指すものと読めます。--helpにはサンドボックス専用のフラグは出ず、有効化は/sandboxか設定ファイル経由になります。

使い分け早見表 — どの評価軸を優先するか

隔離の強さだけを見れば4ツールに優劣は付けにくく、どの評価軸を自分のチームが優先するかで選択が変わります。

まとめ

ツール選びの分かれ目は、隔離の強さよりも「隔離できないときに止まるか、続行するか」にあります。CI・コンテナ・共有マシンで動かすなら、最初に確かめるのはこの挙動です。

クラウドで実行する設計はDevin以外にも見られ、AmpのOrbはスレッドごとに新しいクラウド環境を立てます。Claude CodeとAmpの違いはこの比較記事にあります。非コーディング業務のエージェントにも同じ対立軸があります。Claude CoworkはLinux版でQEMU・KVMを使い、Google AntigravityはmacOS・LinuxでOS機構だけを使います。両者の比較はCoworkとAntigravityの比較で読めます。