最終確認日は2026年9月21日です。他社製品は変化が速いため、それらに関する記述にはすべてベンダー自身のドキュメントへのリンクを付けています。
壁はどこにあるか
執筆時点で、Claude Codeのサンドボックスの対象はシェルコマンドとその子プロセスです。ファイル操作ツールのほうは許可システムで制御され、ドキュメントにはMCPサーバーとフックはホスト上で制約なしに動くと書かれています。ai-jailはエージェント自体を壁の中で起動するので、エージェントが起動するものもすべて中に入ります。
Codexも、自分が起動するコマンドをサンドボックスに入れ、codexプロセス自体は外に残します。ローカルのMCPサーバーがどこで動くかは、ドキュメントに書かれていません。
許可プロンプトは別の種類の保護
プロンプトが尋ねる相手は人間で、人間は急かされたり騙されたりします。サンドボックスが尋ねる相手はカーネルで、答えは毎回同じです。
人間を外すモード
執筆時点で、以下のエージェントにはいずれも、確認を求めなくなるモードがあります。プロンプトがなくなれば、残る保護はサンドボックスだけです。それも、有効にしてあればの話です。
| エージェント | モード | ベンダーの説明による動作 |
|---|---|---|
| Claude Code | auto | すべてが実行され、別のモデルがあなたの代わりに操作を審査します。ドキュメントはこの分類器を操作ごとの制御であり、隔離の境界ではないと説明しています。 |
| Claude Code | bypassPermissions、または--dangerously-skip-permissions | すべてがチェックなしで実行されます。ドキュメントは、隔離されたコンテナやVMの中だけで使うよう求めています。 |
| Codex CLI | 承認ポリシーnever | エージェントは一切確認を求めません。サンドボックスモードは引き続き適用されます。承認とセキュリティを参照してください。 |
| Codex CLI | danger-full-access、または--yolo | サンドボックスが無効になります。--yoloでは承認もなくなります。 |
並べて比べる
ここに書いた内容はすべて、執筆時点の各製品のドキュメントに基づいています。私たちが読んだドキュメントに答えがなかった項目は、セルにそう記しています。
| Claude Codeのサンドボックス | Codex CLIのサンドボックス | Gemini CLIのサンドボックス | ai-jail | |
|---|---|---|---|---|
| エージェント全体を包むラッパーで加わるもの | ||||
| 壁の中に入るもの | Bash、PowerShell、Monitorのコマンドとその子プロセス。claudeプロセス、ファイル操作ツール、MCPサーバー、フックは外です。 | エージェントが起動するコマンド。codexプロセスは外です。ローカルのMCPサーバーについては記載なし。 | CLIのプロセス全体。security.toolSandboxingを使うと、シェルと書き込みツールだけになります。 | プロセスツリー全体。エージェント、ファイル操作ツール、MCPサーバー、フック、すべてのコマンドが入ります。 |
| デフォルトで有効か | いいえ。/sandboxかsandbox.enabledで有効にします。依存するものが足りないと、警告を出してサンドボックスなしでコマンドを実行します。sandbox.failIfUnavailableを設定すれば、そうなりません。 | はい。デフォルトのモードはworkspace-writeです。 | -s、GEMINI_SANDBOX、tools.sandboxのいずれかで有効にします。 | ai-jail経由でエージェントを起動すれば、常に有効です。設定が不正な場合は起動を拒否します。 |
サンドボックス内のコードはデフォルトで~/.sshを読めるか | はい。ドキュメントによると、デフォルトでは~/.aws/credentialsや~/.ssh/などの認証情報ファイルを読めます。拒否ルールはオプトインです。 | Linuxでは読めます。ファイルシステム全体が読み取り専用でマウントされるためです。拒否エントリはオプトインです。macOSのデフォルトは記載なし。 | macOSのデフォルトプロファイルpermissive-openは、広い範囲のファイル読み取りを許可します。より厳しいプロファイルはオプトインです。 | いいえ。エージェントには新しい空のホームディレクトリが渡されます。--sshはオプトインです。 |
| 環境変数 | サンドボックス内のコマンドは、デフォルトで親の環境を認証情報ごと引き継ぎます。sandbox.credentialsで拒否またはマスクできます。 | 記載なし | 記載なし | ターミナル、ロケール、ツールチェーン用の変数だけの最小限の許可リスト。ほかの変数は--envで名前を指定して追加します。 |
| モデルが使える抜け道 | モデルはdangerouslyDisableSandboxを付けてコマンドを再試行でき、その場合は通常の許可フローを通ります。allowUnsandboxedCommands: falseでこれを無効にできます。 | on-requestポリシーでは、ワークスペース外の編集やネットワークのために、エージェントがサンドボックスの外に出る許可を求めます。 | 記載なし | ありません。ポリシーはエージェントの起動前にあなたが決めます。プロジェクト側の.ai-jailファイルは、ポリシーを厳しくできても緩めることはできません。 |
| どのエージェントでも使えるか | Claude Codeのみ | Codexのみ | Gemini CLIのみ | どんなコマンドでも使えます。ポリシーファイル1つで、すべてのエージェントに対応します。 |
| 組み込みサンドボックスのほうが優れている点 | ||||
| ネットワークの扱い | ドメイン単位の許可リストを持つプロキシ。新しいドメインが出てくると確認を求めます。ドメインフロンティングで回避されうることは、ドキュメントにも書かれています。 | workspace-writeではデフォルトで無効。設定1つで有効になり、オプションのプロキシでドメイン単位の許可と拒否のルールを追加できます。 | デフォルトのプロファイルはネットワークを許可します。より厳しいプロファイルやプロキシ付きのプロファイルはオプトインです。 | 全部かゼロかです。デフォルトでは無効で、--networkで全体が開きます。ドメイン単位のフィルターは、あえて備えていません。 |
| コマンドごとの承認 | あり。許可モード、planモード、分類器モデル、組織で管理するポリシーがあります。 | あり。承認ポリシー、カテゴリ別のルール、オプションのレビュー用エージェントがあります。 | 記載なし | なし。ai-jailは個々のコマンドを見ることも、確認を求めることもありません。 |
| プロジェクト内の保護されたパス | あり。.git/hooks、.git/config、.claudeの設定、.mcp.json、シェルのrcファイルなどは読み取り専用のままです。 | あり。書き込み可能なルートの下にある.git、.agents、.codexは読み取り専用です。 | 記載なし | 組み込みではなし。プロジェクト全体が書き込み可能です。パスのマスクや拒否は、--maskとdeny_pathsで自分で指定します。 |
| 秘密情報をエージェントから隠したまま使う | 認証情報のマスク機能を使うと、本物の秘密情報をプロキシ側で注入できます。実験的な設定が必要です。 | 記載なし | 記載なし | できません。マスクされたファイルは空のファイルです。 |
| プラットフォーム | macOS、Linux、WSL2。ネイティブのWindowsとWSL1には非対応。 | macOS、Linux、WSL2、ネイティブのWindows。 | macOSのSeatbelt、DockerまたはPodman、gVisor、LXC（実験的）、ネイティブのWindows。 | LinuxとmacOS。WindowsではWSL2のみ。 |
| インストール | エージェントに同梱。Linuxではbubblewrapとsocatが必要です。 | エージェントに同梱。 | エージェントに同梱。コンテナ系のバックエンドにはDockerかPodmanが必要です。 | 別のバイナリ。Linuxではbubblewrapが必要です。 |
出典：Claude Code sandboxing、Claude Code sandbox environments、Codex approvals and security、Codex Linux sandbox、Gemini CLI sandbox。
両方使う
ネットワークが無効だと、クラウド型のエージェントは自分のモデルAPIに接続できません。実際に開けるものは2つ、ネットワークとエージェントのログイン情報です。
cd ~/Projects/my-appai-jail --network --agent-state claude
エージェント自身のチェックが引き続き担うこと
許可プロンプト、許可と拒否のルール、planモードはエージェントというプログラムの一部なので、ジェイルの中でも外と同じように動きます。あなたなら承認しなかったはずのコマンドを、ここで止められます。
その下でai-jailが保証すること
あなたが何を承認しても、エージェントとそのMCPサーバー、フックからは、ホームディレクトリも鍵もシェルのトークンも見えません。ただし、エージェントは読めるものを送れます。プロジェクト内の秘密情報はマスクしてください。
Docker、devコンテナ、仮想マシン
これらも良い選択肢で、仮想マシンのほうが境界として強くなります。違いは、何をビルドし、何を更新し続ける必要があるかです。
| 得られるもの | かかるコスト | |
|---|---|---|
| Dockerコンテナ | 専用のファイルシステム、プロセス一覧、ネットワーク。エージェントに見えるのは、あなたがマウントしたものだけです。 | イメージのビルドと保守が必要で、ツールチェーンをもう一度インストールすることになります。Dockerソケットをマウントすると、そのコンテナはホストのroot相当になります。 |
| devコンテナ | コンテナと同じ隔離。エディタが理解でき、チームで共有できるファイルに定義を書きます。 | 同じくイメージの保守が必要です。加えて、この形式に対応したエディタかツールが要ります。 |
| 仮想マシン | 専用のカーネル。この中で最も強い境界で、悪意があると考えるコードにはこれが適切です。 | 最も重い選択肢です。ゲストOSをインストールして更新し、メモリを割り当て、プロジェクトをコピーする必要があります。 |
| ai-jail | 1つのコマンドを囲むサンドボックス。マシンにすでにあるコンパイラやランタイムを使います。イメージもデーモンもrootも要りません。 | カーネルをホストと共有するので、カーネルやドライバの脆弱性を突く攻撃は守備範囲の外です。仮想マシンよりは弱い境界です。 |
ai-jail自身のドキュメントは、これを「有用な層であり、使い捨てのVMの代わりではない」と位置づけています。脅威モデルを読む。
併用についての質問
エージェント自身のサンドボックスとプロンプトは切るべきですか？
プロンプトとルールは残してください。個々のコマンドを審査するのはそちらの役目で、ai-jailはそれをしません。エージェントのOSサンドボックスは、Linuxでは事情が違います。入れ子のbubblewrapサンドボックスに必要なシステムコールをai-jailがブロックしており、この組み合わせが動くとはドキュメントに書かれていません。ジェイルの中でエージェントが「サンドボックスを利用できない」と報告しても、ジェイル自体は機能しています。
ai-jailはDockerより安全ですか？
境界としては同じ種類です。どちらもカーネルをホストと共有し、どちらも仮想マシンではありません。ai-jailはすべて閉じた状態から始まり、イメージもデーモンもrootも要りません。コンテナは指示されたものをマウントし、Dockerソケットをマウントすればホストのroot相当になります。悪意があると考えるコードには、使い捨てのVMを使ってください。
ドメイン単位のネットワーク許可リストがないのはなぜですか？
サンドボックスの中に置いたフィルターは、エージェントが使わないことを選べてしまいます。メンテナーはこの要望を対象外としてクローズしました。rootなしで実現するには、ユーザー空間のネットワークスタックが必要です。そのうえで、SNIの検査か、認証情報を含むエージェントのAPI通信に対するTLSインターセプトのどちらかも必要になります。SNIの検査は、SNIがない場合や暗号化されている場合には機能しません。フィルターは、すでに特権のある場所でかけてください。エージェントのuidに対するnftablesのルール、
IPAddressAllow=を指定したsystemdのスライス、ネットワーク名前空間を所有するコンテナやVMなどです。Claude Codeしか使いません。それでもai-jailは必要ですか？
執筆時点で選択肢は3つあります。組み込みサンドボックスはシェルコマンドをカバーします。Anthropicの
@anthropic-ai/sandbox-runtimeはベータ版のリサーチプレビューで、プロセス全体を包みます。ai-jailもプロセス全体を包みます。ホームディレクトリと環境変数を閉じた状態から始まり、後でほかのエージェントを試すときにも同じポリシーを使えます。Anthropicによるサンドボックス環境の比較も参照してください。エージェントを檻の中に
ai-jailは単一のバイナリで、デーモンもroot権限も要りません。いつものコマンドの前に1語足すだけです。
brew tap akitaonrails/tap && brew install ai-jailai-jail claude