サンドボックス

サンドボックスは、マシンへの無制限のアクセスを許可せず、 エージェントを自律的に動作させるための境界です。ローカルチャットから 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 は、bwrap 実行可能ファイルを PATH で検索し、最初に見つかったものを使用します。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：エージェントはサンドボックスによる制限なしで動作します。 ファイルシステムとネットワークの境界がなくなるため、 エージェントにフルアクセスを許可して動作させる場合にのみ使用してください。

主な承認ポリシーは次のとおりです：

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

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