Sandbox

概要

エージェントにマシンへの無制限アクセスを与えずに自律動作させるための境界。ChatGPT desktop app / Codex CLI / IDE extension でローカルのチャットがコマンドを実行するとき、既定でフルアクセスではなく制約された環境の中で走る。

仕様

適用範囲

sandbox は組み込みのファイル操作だけでなく spawn されたコマンドにも適用される。git、パッケージマネージャ、テストランナーを走らせた場合も同じ境界を継承する
各 OS のネイティブな機構で強制する。実装は macOS / Linux / WSL2 / Windows ネイティブで異なるが、考え方は共通
sandbox と approvals は別々の制御。sandbox が技術的な境界を定め、approval policy が境界を越える前に停止して確認するかどうかを決める

前提条件

OS	前提
macOS	組み込みの Seatbelt フレームワークでそのまま動く
Windows	PowerShell 上ではネイティブの Windows sandbox、WSL2 上では Linux sandbox 実装
Linux / WSL2	パッケージマネージャで `bubblewrap` を先に入れる（`sudo apt install bubblewrap` / `sudo dnf install bubblewrap`）

PATH 上で最初に見つかった bwrap を使う。bwrap が無い場合はバンドルされたヘルパーにフォールバックするが、そのヘルパーは非特権 user namespace の作成に対応している必要がある
bwrap が無い、またはヘルパーが必要な user namespace を作れない場合、起動時に警告が出る
この AppArmor 設定を制限するディストリビューションでは、制限をグローバルに無効化するのではなく bwrap の AppArmor プロファイルを読み込むことが推奨されている
Ubuntu 25.04 では、Ubuntu のパッケージリポジトリから bubblewrap を入れれば追加の AppArmor 設定なしで動くはずとされている。bwrap-userns-restrict プロファイルは apparmor パッケージの /etc/apparmor.d/bwrap-userns-restrict に入る
Ubuntu 24.04 では bubblewrap を入れても user namespace を作れないと警告が出ることがある。追加プロファイルをコピーして読み込む

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 は再起動なしでプロファイルをカーネルに読み込む。sudo systemctl reload apparmor.service で全プロファイルを再読み込みしてもよい
そのプロファイルが無い、または問題が解決しない場合の最終手段として sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0 がある

sandbox mode

モード	挙動
`read-only`	ファイルの調査はできるが、承認なしに編集もコマンド実行もできない
`workspace-write`	読み取り、ワークスペース内の編集、その境界内での日常的なローカルコマンド実行ができる。ローカル作業向けの既定の低摩擦モード
`danger-full-access`	sandbox 制限なしで動く。ファイルシステムとネットワークの境界が外れる

approval policy

ポリシー	挙動
`untrusted`	trusted な集合に無いコマンドの実行前に確認する
`on-request`	既定では sandbox 内で作業し、境界を越える必要が出たときに確認する
`never`	承認プロンプトで止まらない

approvals_reviewer

承認が対話的なとき、誰がレビューするかを選べる。

値	挙動
`user`	承認プロンプトをユーザーに出す。既定
`auto_review`	対象の承認プロンプトを reviewer agent に回す

full access とは 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）
automatic review は sandbox の境界を変えない。境界での承認要求（sandbox escalation、ブロックされたネットワークアクセス、承認の要る副作用付きツール呼び出し）に対する approvals_reviewer の選択肢の 1 つ。sandbox 内で既に許可されているアクションは追加レビュー無しで走る

サーフェスごとの permissions 操作

サーフェス	操作方法
ChatGPT desktop app	composer 下の permissions コントロール。設定によってメニューに Ask for approval、対象の承認要求に対する Approve for me、Full access、名前付き／カスタムの permissions profile が並ぶ
Codex CLI	`/permissions` で permissions picker を開き、有効な permissions profile を変える
IDE extension	composer 下の permissions コントロール。app と同じ選択肢
ChatGPT Work（web）	管理された隔離環境でコードと shell コマンドを実行する。ローカルの Codex sandbox や approval-mode セレクタは公開されない

ChatGPT Work（web）の補足:

ワークスペースポリシーとツール個別の制御が、使える機能を決める
設定が利用可能な場合、Settings > Data controls > Work network access でコードと shell コマンドのネットワークアクセスを管理する。Allow public internet access を on にするとパブリックインターネットに到達できる。off のときは managed allowlist にある必要なホスト名にのみ到達できる
web search、plugin、remote browser は別の制御を持つ
変更は、現在のコード／shell 実行が終わって Work が実行環境をリフレッシュした後に反映される

既定の設定

config.toml で sandbox_mode、approval_policy、approvals_reviewer、sandbox_workspace_write.writable_roots を設定する
複数ディレクトリで作業させたい場合、writable roots によって sandbox を丸ごと外さずに変更可能な場所を広げられる
特定のワークフローだけ例外が必要なときは rules を使う。rules は sandbox の外のコマンド接頭辞を allow / prompt / forbid でき、アクセスを広く広げるより適していることが多い

設定

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"

制約・注意点

承認が「1 回だけ」「セッション中」など異なるスコープを提示する場合、タスクが進む最も狭いスコープを選ぶことが推奨されている
プロジェクト境界を既定に保ち、無関係なリポジトリ間でアクセスを広げる代わりに別プロジェクトや worktree を使う
信頼境界を広げたい／狭めたいときは、単発の例外に頼らず既定の sandbox mode と approval policy を調整する

Sandbox

概要

仕様

適用範囲

前提条件

sandbox mode

approval policy

approvals_reviewer

サーフェスごとの permissions 操作

既定の設定

設定

制約・注意点

関連