サンドボックス
ChatGPT と Codex クライアント全体におけるサンドボックスの仕組み
サンドボックスは、エージェントにマシンへの無制限のアクセスを与えることなく、自律的に動作させるための境界です。ローカルチャットが ChatGPT デスクトップアプリ、Codex CLI、または IDE 拡張機能でコマンドを実行すると、デフォルトでは完全なアクセス権を持つのではなく、制約された環境内で実行されます。
この環境は、変更できるファイルや、コマンドによるネットワーク利用の可否など、エージェントが自力で実行できる操作を定義します。タスクがその境界内に収まっていれば、エージェントは確認のために停止せず、作業を続行できます。境界を越える必要がある場合は、承認フローに切り替わります。
サンドボックスの役割
サンドボックスは、組み込みのファイル操作だけでなく、起動されたコマンドにも適用されます。エージェントが git、パッケージマネージャー、テストランナーなどのツールを実行すると、それらのコマンドにも同じサンドボックス境界が引き継がれます。
Codex は、各 OS でプラットフォーム固有の仕組みを使用して制限を適用します。実装は macOS、Linux、WSL2、ネイティブ Windows で異なりますが、すべての利用形態で考え方は同じです。エージェントに境界の明確な作業場所を提供し、日常的なタスクを明確な制限内で自律的に実行できるようにします。
重要である理由
サンドボックスは、承認による負担を軽減します。リスクの低いコマンドを一つひとつ確認する代わりに、エージェントはあらかじめ承認された境界内でファイルを読み取り、編集し、日常的なプロジェクトコマンドを実行できます。
また、エージェントによる作業について、より明確な信頼モデルが得られます。信頼するのはエージェントの意図だけではありません。エージェントが強制された制限内で動作していることも信頼できます。これにより、いつ停止して支援を求めるかを把握しながら、エージェントに独立して作業させやすくなります。
はじめに
デフォルトの権限モードでは、サンドボックスが自動的に適用されます。
前提条件
macOS では、組み込みの Seatbelt フレームワークにより、追加設定なしでサンドボックスを利用できます。
Windows では、PowerShell で実行する場合、Codex はネイティブの Windows サンドボックスを使用し、 WSL2 で実行する場合は Linux のサンドボックス実装を使用します。
Linux および WSL2 では、まずパッケージマネージャーで bubblewrap をインストールします。
Ubuntu/Debian
sudo apt install bubblewrapFedora
sudo dnf install bubblewrapCodex は、PATH で最初に見つかった bwrap 実行ファイルを使用します。bwrap
実行ファイルがない場合、Codex は同梱のヘルパーにフォールバックしますが、このヘルパーを利用するには、非特権ユーザー名前空間の作成がサポートされている必要があります。
bwrap を提供するディストリビューションパッケージをインストールすると、この設定を安定して利用できます。
bwrap がない場合や、ヘルパーが必要なユーザー名前空間を作成できない場合、Codex は起動時に警告を表示します。この
AppArmor 設定を制限しているディストリビューションでは、制限をシステム全体で無効にせずに
bwrap を動作させ続けられるよう、bwrap AppArmor プロファイルを読み込むことを推奨します。
権限の仕組み
利用している環境の権限制御を使用して、Codex がローカル操作を処理する方法を変更します。
承認は、Codex が操作前に一時停止するタイミングを決定し、サンドボックスはコマンドがアクセスできるファイルとネットワークリソースを決定します。1 回のみ、またはセッション中など、承認時に複数の適用範囲が提示された場合は、タスクを続行できる最小限の範囲を選択してください。プロジェクト境界をデフォルトとして維持し、無関係なリポジトリ全体へアクセスを拡大する代わりに、別のプロジェクトや作業ツリーを使用してください。
ChatGPT デスクトップアプリでは、入力欄の下にある権限制御を使用します。設定によっては、メニューに 承認を求める、対象となる承認リクエストに対する 自動で承認、フルアクセス、および名前付きまたはカスタムの権限プロファイルが表示されます。
デフォルトを設定する
毎回同じ動作で開始するには、config.toml でデフォルトを設定します。
設定の基本では仕組みを説明し、
設定リファレンスでは
sandbox_mode、approval_policy、approvals_reviewer、
sandbox_workspace_write.writable_roots の正確なキーについて説明しています。これらの設定を使用して、エージェントにデフォルトで与える自律性、書き込み可能なディレクトリ、承認のために一時停止するタイミング、対象となる承認リクエストの確認者を決定します。
一般的なサンドボックスモードは次のとおりです。
read-only: エージェントはファイルを確認できますが、承認なしではファイルを編集したり、コマンドを実行したりできません。workspace-write: エージェントはファイルを読み取り、ワークスペース内で編集し、その境界内で日常的なローカルコマンドを実行できます。これは、ローカル作業向けのデフォルトの低負担モードです。danger-full-access: エージェントはサンドボックスの制限なしで動作します。ファイルシステムとネットワークの境界が取り除かれるため、エージェントをフルアクセスで動作させたい場合にのみ使用してください。
一般的な承認ポリシーは次のとおりです。
untrusted: エージェントは、信頼済みセットに含まれないコマンドを実行する前に確認を求めます。on-request: エージェントはデフォルトでサンドボックス内で作業し、その境界を越える必要がある場合に確認を求めます。never: エージェントは承認プロンプトのために停止しません。
承認が対話形式の場合、approvals_reviewer で確認者を選択することもできます。
user: 承認プロンプトをユーザーに表示します。これがデフォルトです。auto_review: 対象となる承認プロンプトをレビュー担当エージェントに送ります( 自動レビューを参照)。
フルアクセスとは、sandbox_mode = "danger-full-access" と
approval_policy = "never" を組み合わせて使用することです。一方、リスクを抑えたローカル自動化のプリセットは、sandbox_mode = "workspace-write" と
approval_policy = "on-request"、または対応する CLI フラグ
--sandbox workspace-write --ask-for-approval on-request の組み合わせです。そのうえで、手動承認には approvals_reviewer = "user" を維持し、自動承認レビューには
approvals_reviewer = "auto_review" を設定できます。
エージェントが複数のディレクトリをまたいで作業する必要がある場合、書き込み可能なルートを使用すると、サンドボックス全体を解除せずに変更可能な場所を拡張できます。信頼境界を広げたり狭めたりする必要がある場合は、一時的な例外に頼るのではなく、デフォルトのサンドボックスモードと承認ポリシーを調整してください。
ワークフローに特定の例外が必要な場合は、ルールを使用します。ルールでは、サンドボックス外のコマンドプレフィックスを許可するか、確認を求めるか、禁止するかを指定できます。多くの場合、アクセスを広範囲に拡大するより適しています。IDE 固有の設定へのアクセス方法については、Codex IDE 拡張機能の設定を参照してください。
自動レビューを利用できる場合でも、サンドボックス境界は変わりません。これは、サンドボックス権限の昇格、ブロックされたネットワークアクセス、承認が引き続き必要な副作用を伴うツール呼び出しなど、境界上の承認リクエストに指定できる approvals_reviewer の一つです。サンドボックス内ですでに許可されている操作は、追加レビューなしで実行されます。レビュー担当のライフサイクル、トリガーの種類、拒否時の動作、設定の詳細については、
自動レビューを参照してください。
プラットフォームの詳細については、各プラットフォーム固有のドキュメントを参照してください。ネイティブ Windows の設定、動作、トラブルシューティングについては、Windowsを参照してください。サンドボックスと承認に関する管理者向けの要件および組織レベルの制約については、 エージェントの承認とセキュリティを参照してください。