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はこれに加えて、CLIのローカルサンドボックスとは別にクラウドVM上でセッションを丸ごと隔離する構成を持ちます。

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

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

Claude Codeのサンドボックスは/sandboxコマンドで有効化するBashツール専用の隔離層です。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")を持つ点が独自です。Claude CodeはWSL2内での実行が既定で、Cursorは公式ドキュメントがmacOS/Linuxしか記載しておらず、Devin CLIはWindowsでは起動そのものができません。

隔離できないときの既定挙動もツールごとに割れています。Claude Codeは依存パッケージが足りない・プラットフォームが非対応といった理由でサンドボックスを作れないとき、既定では警告を出して非サンドボックスのまま実行を続けます(failIfUnavailableを設定すれば拒否に変えられます)。Codex CLIはDockerなどのコンテナ内でbwrap/seccompが使えず動かないケースを文書化しており、その場合はコンテナ側で隔離した上で--sandbox danger-full-accessを指定するよう案内しています。Devin CLIは--sandboxフラグを渡した時点で、隔離できなければセッションそのものを起動しません(fail-closed)。エンタープライズ管理者がサンドボックス必須ポリシーを敷いている組織では、Devinの起動拒否とClaude CodeのfailIfUnavailableが「ポリシーが黙って無効化される事故」を防げます。

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

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

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

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

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

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

既定でネットワークを開いているのはDevin CLIだけで、他の3ツールは閉じた状態から許可リストで開きます。

Cursorの組み込みデフォルトは実装の癖が出ている部分です。npmjs.com・pypi.org・crates.io・docker.io・github.comなど、主要言語のパッケージレジストリとOSディストリビューションのミラーをまとめて許可する一覧をあらかじめ持っており、「サンドボックス設定を書かなくてもよくあるビルドコマンドは動く」ことを優先した設計です。Codex CLIとClaude Codeは、こうした組み込み許可リストを持たず、必要なドメインをユーザーまたは分類器の承認で都度追加する方式を取ります。

公式ドキュメントが「現状不安定な機能」と明記しているのはDevinのネットワークフィルタリングだけです。安定運用が必要ならアカウント担当者に確認するよう案内されており、Claude Code・Codex・Cursorのように標準機能として組み込み済みの状態ではありません。

Devinだけが持つクラウドVM隔離という第2の層

Devinの実行環境は、CLIの--sandboxフラグによるローカルOS隔離だけでは説明できません。本来のセッションはクラウドVM上で動き、Claude Code・Codex・Cursorのようにローカルでコマンドを直接隔離する3ツールとは隔離の単位そのものが違います。Devinはネットワークポリシー・MCPサーバーの許可リスト・Gitアクセスレベル(読み取り専用/フル)・GitHub CLIトークンの有無をまとめた「セキュリティプロファイル」を組織・自動化・セッション単位で割り当てる運用になっています。

プロファイルには「推奨(下位が上書き可能)」と「必須(下位は交差方向にしか変更できない)」の2段階があり、必須プロファイルではセッション中に承認したネットワークアクセスさえ、プロファイルが許可する範囲との交差に自動的に絞り込まれます。ファイルとネットワークをOSプリミティブで直接絞る他3ツールに対し、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はCLI側に相当する確認コマンドを公開しておらず、環境変数CURSOR_SANDBOX(macOSではseatbelt、Linuxではnative)がプロセス内に設定されているかどうかで、そのコマンドが実際にサンドボックス経由で動いたかを事後的に見分けられるにとどまります。Devin CLIも同様に、動作確認は実行ログとエラーメッセージに頼る形です。

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

隔離の強さだけを見れば4ツールに優劣は付けにくく、どの評価軸を自分のチームが優先するかで選択が変わります。CI環境やコンテナ内でエージェントを動かす構成では④の失敗時挙動が実運用上の分岐点になりやすく、社内の共有マシンで複数人がエージェントを使う場合はDevinのプロファイル型が管理コストを下げます。

まとめ

Claude Code・Codex CLI・Cursorは、macOS・Linux(・一部Windows)のOSプリミティブを直接呼び出してBashコマンドを隔離するという設計思想を共有しつつ、既定のファイル読み取り範囲・ネットワーク許可リストの持ち方・隔離失敗時の挙動で差が付いています。Devinだけは、CLIのローカルサンドボックスに加えて、本来の実行単位であるクラウドVMをセキュリティプロファイルで統制する層をもう一段持っています。自分の運用がローカル端末中心かCI・共有環境中心かで、比較すべき評価軸の重みは変わります。Claude Code自身のサンドボックス実装の詳細はClaude Codeのサンドボックス設計、ファイル隔離だけを外す設定はsandbox.filesystem.disabledの使い方にまとめています。クラウドVMを既定の実行単位にする設計はDevin以外にも見られ、AmpのOrbも同じ発想でスレッドごとに使い捨てのクラウドマシンを立てます。Claude CodeとAmpの権限モデル・実行環境の違いはこの比較記事にまとめています。非コーディング業務のエージェントにも同じ対立軸が表れています。Claude CoworkはLinux版デスクトップアプリでQEMU・KVMによるハードウェア仮想化を使います。一方、Google AntigravityはmacOS・Linuxで仮想マシンを使わずOSネイティブ機構だけでコマンドを隔離します。権限モデル・料金まで含めた両者の比較はCoworkとAntigravityの比較にまとめています。