サンドボックス

ChatGPT デスクトップアプリ

サンドボックスは、マシンへの無制限のアクセスを与えずに、エージェントが自律的に動作できるようにする境界です。ローカルチャットが ChatGPT デスクトップアプリ、Codex CLI、または IDE 拡張機能 でコマンドを実行するとき、そのコマンドはデフォルトでフルアクセスを持つのではなく、制限された環境内で実行されます。

この環境は、変更できるファイルやコマンドによるネットワークの利用可否など、エージェントが自力でできることを定めます。タスクがこの境界内に収まる場合、エージェントは確認のために停止せず、作業を続けられます。境界を越える必要がある場合は、承認フローに移ります。

サンドボックスの役割

サンドボックスは、組み込みのファイル操作だけでなく、起動されるコマンドにも適用されます。エージェントが git、パッケージマネージャー、テストランナーなどのツールを実行すると、それらのコマンドにも同じサンドボックスの境界が適用されます。

Codex は、各 OS に備わった仕組みを使って制限を適用します。実装は macOS、Linux、WSL2、ネイティブ Windows で異なりますが、どの利用環境でも考え方は同じです。エージェントに範囲の定まった作業場所を与え、日常的なタスクを明確な制限の中で自律的に実行できるようにします。

サンドボックスが重要な理由

サンドボックスは、繰り返し承認を求められる負担を減らします。低リスクのコマンドを実行するたびに確認を求める代わりに、エージェントは、すでに承認された境界内でファイルの読み取りや編集、日常的なプロジェクトコマンドの実行を行えます。

また、エージェントによる作業を信頼するための考え方も明確になります。エージェントの意図だけを信頼するのではなく、エージェントが強制的に適用される制限の中で動作していることを信頼できます。そのため、エージェントがいつ停止して助けを求めるかを把握しながら、安心して自律的に作業を進めてもらえます。

はじめに

デフォルトの権限モードでは、サンドボックスが自動的に適用されます。

前提条件

macOS では、組み込みの Seatbelt フレームワークを使用するため、サンドボックスは追加設定なしで動作します。

Windows では、PowerShell で実行する場合、Codex はネイティブの Windows サンドボックスを使用し、 WSL2 で実行する場合は Linux のサンドボックス実装を使用します。

Linux と WSL2 では、まずパッケージマネージャーで bubblewrap をインストールしてください。

sudo apt install bubblewrap

sudo dnf install bubblewrap

Codex は、PATH 上で最初に見つかった bwrap 実行ファイルを使用します。bwrap の実行ファイルが利用できない場合、Codex は同梱のヘルパーにフォールバックしますが、そのヘルパーには非特権ユーザー名前空間を作成できる環境が必要です。 bwrap を提供するディストリビューションのパッケージをインストールすると、この構成を安定して利用できます。

bwrap が見つからない場合や、ヘルパーが必要なユーザー名前空間を作成できない場合、Codex は起動時に警告を表示します。この AppArmor 設定で制限を課しているディストリビューションでは、bwrap AppArmor プロファイルを読み込む方法を推奨します。これにより、bwrap はシステム全体の制限を無効にせずに動作し続けられます。

Ubuntu の AppArmor に関する注意: Ubuntu 25.04 では、Ubuntu のパッケージリポジトリから bubblewrap をインストールすれば、AppArmor の追加設定なしで動作するはずです。 bwrap-userns-restrict プロファイルは apparmor パッケージに含まれており、 /etc/apparmor.d/bwrap-userns-restrict に配置されます。

Ubuntu 24.04 では、bubblewrap をインストールした後も、必要なユーザー名前空間を作成できないという警告が Codex に表示される場合があります。追加のプロファイルをコピーして読み込んでください。

sudo apt update
sudo apt install apparmor-profiles apparmor-utils
sudo install -m 0644 \
  /usr/share/apparmor/extra-profiles/bwrap-userns-restrict \
  /etc/apparmor.d/bwrap-userns-restrict
sudo apparmor_parser -r /etc/apparmor.d/bwrap-userns-restrict

apparmor_parser -r は、再起動せずにプロファイルをカーネルに読み込みます。すべての AppArmor プロファイルを再読み込みすることもできます。

sudo systemctl reload apparmor.service

そのプロファイルが利用できない場合や、問題が解決しない場合は、次のコマンドで AppArmor の非特権ユーザー名前空間の制限を無効にできます。

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

Work Cloud によるローカルコンピューターへのアクセス

Work Cloud によるローカルコンピューターへのアクセスを使用するタスクでは、OpenAI のクラウドが会話を調整します。サンドボックスの制限は、各ステップがどこで実行されるかによって異なります。

クラウドでの実行: Work のクラウドコンテナーには、既存の Work Cloud ポリシーが適用されます。デスクトップブラウザーのサイトルールは、クラウドブラウザーには自動的に適用されません。
ローカルでの実行: 接続されたコンピューター上のステップには、サポートされているローカル実行要件が適用されます。

ローカルアクセスを伴う Work と dots では、管理ポリシーが有効な場合、サポートされている Global ポリシーが共有クラウドオーケストレーターに適用されます。Work のクラウドコンテナーと dots のクラウドコンピューターは、独自の実行設定と要件を使用します。ローカルとクラウドの実行を個別にテストし、各環境でどの制御が適用されるかを確認してください。ある環境のポリシーによって、別の環境へのアクセスが許可されることはありません。

同じポリシー内での優先順位は、高い順に OS 固有の環境の上書き設定 → すべての OS に共通する環境の上書き設定 → Global です。優先順位が低いポリシーのほうが具体的であっても、優先順位が高いポリシーが優先されます。ローカルでの実行では、MDM と従来の管理対象デバイスの要件が Agent Security より優先され、Agent Security はデバイスのシステム要件ファイルより優先されます。

フィールド固有のマージルールと実行時の制限については管理対象の設定を参照し、実際に適用されるファイルとネットワークの制限については Work のローカルセキュリティと Work のクラウドセキュリティを確認してください。

権限の仕組み

利用環境の権限コントロールを使って、Codex がローカル操作を扱う方法を変更できます。

承認は、Codex が操作の前にいつ一時停止するかを決めます。一方、サンドボックスは、コマンドがアクセスできるファイルとネットワークリソースを決めます。承認時に「今回のみ」や「セッション全体」などの範囲を選べる場合は、タスクを続行できる最小限の範囲を選んでください。デフォルトではプロジェクトの境界を維持し、無関係なリポジトリにまでアクセスを広げるのではなく、別のプロジェクトやワークツリーを使ってください。

ChatGPT デスクトップアプリでは、入力欄の下にある権限コントロールを使用します。構成に応じて、メニューには承認を求める、対象となる承認リクエスト向けの代わりに承認、フルアクセス、名前付きの権限プロファイルやカスタム権限プロファイルが表示されます。

Codex に何でも聞いてください。

承認を求める

Codex は、現在のワークスペース内のファイルを読み取り、編集し、日常的なローカルコマンドを実行できます。インターネットを利用する前や、ワークスペースの境界を越える前に確認を求めます。

サンドボックスworkspace-write承認ポリシーon-requestレビュー担当user

デフォルトの設定

毎回同じ動作で開始するには、config.toml でデフォルトを設定します。設定の基本ではその仕組みを説明し、設定リファレンスでは、 sandbox_mode、approval_policy、approvals_reviewer、および sandbox_workspace_write.writable_roots の正確なキーを説明しています。これらの設定で、エージェントにデフォルトでどの程度の自律性を与えるか、どのディレクトリに書き込めるか、いつ承認のために一時停止するか、対象となる承認リクエストを誰がレビューするかを決めます。

代表的なサンドボックスモードの概要は次のとおりです。

read-only: エージェントはファイルを調べられますが、承認なしにファイルを編集したり、コマンドを実行したりすることはできません。
workspace-write: エージェントはファイルを読み取り、ワークスペース内で編集し、その境界内で日常的なローカルコマンドを実行できます。ローカル作業を円滑に進めるためのデフォルトのモードです。
danger-full-access: エージェントはサンドボックスの制限なしで動作します。ファイルシステムとネットワークの境界が取り除かれるため、エージェントにフルアクセスを与えて動作させたい場合にのみ使用してください。

代表的な承認ポリシーは次のとおりです。

on-request: エージェントはデフォルトでサンドボックス内で作業し、その境界を越える必要があるときに確認を求めます。
never: エージェントは承認プロンプトのために停止しません。

Codex と ChatGPT Work では、選択可能な承認ポリシーとして untrusted をサポートしなくなりました。既存の構成でこの値を使用している場合は、廃止された untrusted 承認ポリシーからの移行を参照してください。

承認が対話形式の場合は、レビュー担当も 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を参照してください。サンドボックスと承認に関する管理者向けの要件や組織レベルの制約については、エージェントの承認とセキュリティを参照してください。

最近の検索

おすすめの検索

ドキュメントナビゲーション