サンドボックス

サンドボックスは、マシンへの無制限のアクセスを許可せずに、 エージェントを自律的に動作させるための境界です。 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 実行可能ファイルを利用できない場合は、代わりに同梱のヘルパーを使用しますが、 このヘルパーには、非特権ユーザーによるユーザー名前空間の作成がサポートされている必要があります。 bwrap を提供するディストリビューションのパッケージをインストールすると、この構成を安定して利用できます。

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

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

sudo systemctl reload apparmor.service

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

利用環境の権限設定から、Codex によるローカル操作の扱いを変更できます。

承認は、Codex が操作の前に一時停止するタイミングを決定し、サンドボックスは、コマンドがアクセスできるファイルとネットワークリソースを決定します。1 回限りの承認やセッション全体の承認など、複数の範囲を選択できる場合は、タスクを続行できる最小限の範囲を選んでください。デフォルトではプロジェクトの境界を維持し、無関係なリポジトリにまでアクセスを広げるのではなく、プロジェクトや Worktree を分けて使用してください。

ChatGPT Work は、管理された隔離環境でコードとシェルコマンドを実行します。 利用できる機能は、ワークスペースのポリシーとツール固有の制御によって決まります。 この設定を利用できる場合は、 設定 > データコントロール > Work のネットワークアクセス で、コードとシェルコマンドのネットワークアクセスを管理します。 公開インターネットへのアクセスを許可 をオンにすると、これらのコマンドから公開インターネットにアクセスできます。 オフの場合、コマンドからアクセスできるのは、 管理された許可リストに含まれる必要なホスト名だけです。

ウェブ検索、プラグイン、リモートブラウザには、それぞれ個別の制御があります。変更は、実行中のコードまたはシェルコマンドの処理が終了し、Work が実行環境を更新した後に反映されます。ChatGPT の Web 版には、ローカルの Codex サンドボックスや承認モードの選択機能はありません。

ChatGPT デスクトップアプリでは、コンポーザーの下にある権限設定を使用します。 構成によっては、メニューに 承認を求める、 対象となる承認リクエスト用の自分に代わって承認 、 フルアクセス、 名前付きまたはカスタムの権限プロファイルが表示されます。

CLI では、 /permissions を入力して権限の選択画面を開き、有効な権限プロファイルを変更します。

IDE 拡張機能では、コンポーザーの下にある権限設定を使用します。 構成によっては、メニューに 承認を求める、 対象となる承認リクエスト用の自分に代わって承認 、 フルアクセス、 名前付きまたはカスタムの権限プロファイルが表示されます。

デフォルトの設定

毎回同じ動作で開始するには、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 の選択肢の 1 つです。 対象には、サンドボックスの権限昇格、ブロックされたネットワークアクセス、 引き続き承認が必要な副作用を伴うツール呼び出しなどがあります。サンドボックス内ですでに許可されている操作は、 追加のレビューなしで実行されます。レビュー担当エージェントのライフサイクル、トリガーの種類、 拒否時の動作、設定の詳細については、 自動レビューを参照してください。

プラットフォームごとの詳細は、各プラットフォームのドキュメントに記載されています。 ネイティブ Windows のセットアップ、動作、トラブルシューティングについては、Windows を参照してください。 サンドボックスと承認に関する管理者向けの要件や組織レベルの制約については、 エージェントの承認とセキュリティを参照してください。