Codexサンドボックス：モード、--yolo、Docker、クラウド

Codexのサンドボックスは、コマンドの書き込み先とネットワークへのアクセスを制限します。ローカル作業ではworkspace-writeから始めます。--yoloはCodexのサンドボックスと承認プロンプトを両方とも無効にするため、外部サンドボックス内でのみ使用してください。

macOS上とDocker内でCodex CLI 0.162.1をテストし、Lizard SandboxesでもCodexのタスクを実行しました。このガイドでは、その結果、重要な設定、構成の選び方を説明します。

例ではテストしたバージョンを使用します。2026年10月21日の情報源の確認では、最新の安定版は0.163.0でした。別のリリースの設定を適用する前に、インストール済みのバージョンを確認してください。リリース一覧を参照してください。

Codexの組み込みサンドボックスは何を保護するか

Codexは、テストランナー、Git、パッケージマネージャーなど、起動するコマンドにオペレーティングシステムの制限を適用します。この制限はファイルへの書き込みとネットワークアクセスを制御します。MCPサーバー、コネクター、ブラウザツールは独自の制御を使用します。コマンドサンドボックスは、接続するすべてのツールを封じ込めるものではありません。OpenAIのサンドボックスの適用範囲とツールの制御を参照してください。

macOSでのworkspace-writeの検証では、プロジェクトへの書き込みは成功し、ホームディレクトリへの書き込みは失敗しました。.git/は読み取り専用のままでした。/tmpと$TMPDIRへの書き込みは成功しました。~/.zshrcの読み取りも成功しました。workspace-writeは読み取りをプロジェクト内に限定しません。

ドキュメントでは、書き込み可能なルート内にある既存の.codex、.agents、.awsディレクトリも保護対象としています。保護はその内容にも及び、.gitの保護にはリンク先のgitdirも含まれます。私たちは.gitを検証しました。他の保護対象パスについてはOpenAIのドキュメントに基づいています。

Codexのサンドボックスモードを有効にする

プロジェクト内で対話型セッションを開始します。

codex --sandbox workspace-write --ask-for-approval on-request

これでAutoを選択します。ワークスペースの編集と通常のコマンドは実行でき、より広いアクセスには承認が必要です。対話型のCodexは、バージョン管理下のフォルダではAuto、それ以外では読み取り専用を推奨します。フォルダを信頼するまでは、読み取り専用で起動する場合があります。一方、codex execはデフォルトで読み取り専用です。編集を許可するには、次を実行します。

codex exec --sandbox workspace-write "<task>"

<task>を依頼内容に置き換えます。対話型のデフォルト設定とexecの権限を参照してください。codex execのガイドでは、スクリプトによるタスクを説明しています。

macOSでは、CodexはSeatbeltを使用します。LinuxとWSL2では、ファイルシステムの分離にbubblewrap、システムコールのフィルタリングにseccompを使用します。bubblewrapは0.115.0でデフォルトになりました。DebianまたはUbuntuでは、次のようにインストールします。

sudo apt install bubblewrap

PATHにbwrapがない場合、Codexは同梱のヘルパーを使用できます。このヘルパーには非特権ユーザー名前空間が必要です。Ubuntu 24.04では、AppArmorのbwrap-userns-restrictプロファイルも必要な場合があります。前提条件に従ってください。

ネイティブWindowsはMXCをサポートします。対応するWindows 11のビルド、24H2のビルド26100.9278または25H2のビルド26200.9278以降では、MXCを推奨します。従来の代替手段はelevatedとunelevatedです。WSL2はLinuxのサンドボックスを使用します。Windowsの要件を参照してください。

ネットワークと書き込みアクセスを設定する

workspace-writeでは、ネットワークアクセスは初期状態で無効です。Codexの設定で有効にするには、次を指定します。

[sandbox_workspace_write]
network_access = true

1回の実行だけ上書きする指定は-c sandbox_workspace_write.network_access=trueです。私たちのネットワーク検証では、この設定でDNSエラーからHTTP 200に変わりました。この設定は外向きのアクセスを有効にします。ドメインルールには別のネットワークプロキシが必要です。ネットワーク設定を参照してください。

これらはコマンドのネットワーク制御です。Codexのモデルへのリクエストと認証リクエストは別の経路を使用します。そのため、curlリクエストのブロックは、CLIがモデルに接続できないことを意味しません。プロキシはMCP接続やブラウザの通信もフィルタリングしません。コマンドプロキシ外の通信を参照してください。

別のフォルダへの書き込みを許可するには、--add-dirに必要なパスを指定します。

codex --add-dir <DIR>

<DIR>をそのフォルダに置き換えます。タスクに必要なのがそれだけなら、OpenAIはディレクトリの追加を推奨します。

長時間の実行前に境界を確認する

プロジェクトフォルダから次の4つの検証を実行しました。

codex sandbox -c sandbox_mode="workspace-write" -- sh -c 'touch ./inside && echo inside-ok || echo inside-blocked'
codex sandbox -c sandbox_mode="workspace-write" -- sh -c 'touch ~/codex-probe-outside && echo outside-ok || echo outside-blocked'
codex sandbox -c sandbox_mode="workspace-write" -- sh -c 'curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com || echo net-blocked'
codex sandbox -c sandbox_mode="workspace-write" -c sandbox_workspace_write.network_access=true -- sh -c 'curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com || echo net-blocked'

この順に、inside-ok、outside-blocked、net-blocked（curl: (6) Could not resolve host: example.comの後）、200が返りました。

一部のドキュメントにはcodex sandbox macos|linuxと記載されています。バージョン0.162.1はこれらをOSサブコマンドとして受け付けません。ホストがバックエンドを選択します。上記のサブコマンドなしの形式を使用してください。リリースのソースコードでも確認できます。

エージェントのシェルツールを通じても確認してください。エージェント経由では次のように呼び出しました。

codex exec -s workspace-write -c approval_policy="never" \
  --ephemeral --json \
  "Run exactly these three shell commands, one at a time, with your shell tool, and report the exit code and output of each. Do not retry, do not use workarounds, do not ask for approval: 1) touch ./agent-inside  2) touch ~/codex-agent-probe  3) curl -sS -m 5 -o /dev/null -w '%{http_code}' https://example.com"

このプロンプトで、次の3つのコマンドを実行しました。

touch ./agent-inside
touch ~/codex-agent-probe
curl -sS -m 5 -o /dev/null -w '%{http_code}' https://example.com

テストでは、プロジェクトへの書き込みは終了コード0を返しました。ホームディレクトリへの書き込みはOperation not permittedで失敗し、curlは終了コード6とCould not resolve hostを返しました。ホームディレクトリにファイルは作成されませんでした。サンドボックス外の別のターミナルでこれらのコマンドを実行しても、エージェントの制限は検証できません。

サンドボックスモードと承認ポリシー

サンドボックスモードはコマンドの制限を設定します。承認ポリシーは、Codexがその制限を超える許可をいつ求められるかを決めます。

0.162.1では、対話型の承認フラグはon-requestとneverを受け付けます。前者はより広いアクセスが必要なときに承認を求めます。後者は選択したサンドボックスの制限を維持したまま、プロンプトを出さなくします。設定では細かいポリシーテーブルもサポートします。codex execのデフォルトはneverで、対話型の-aフラグは受け付けません。承認の選択肢とexecのデフォルトを参照してください。

古い例には注意が必要です。untrustedは0.149.0で廃止され、on-failureは非推奨です。--full-autoは0.147.0でcodex execから削除されました。私たちの0.162.1での実行も--full-autoを拒否しました。編集が必要なexecタスクには--sandbox workspace-writeを使用します。

Codexの--yoloモードは何をするか

--yoloは--dangerously-bypass-approvals-and-sandboxの別名です。両方の制御を無効にし、danger-full-accessと承認ポリシーneverを組み合わせた効果を持ちます。OpenAIは、外部サンドボックスで隔離した環境内でのみ使用するよう案内しています。フラグの警告を参照してください。

次のコマンドでエージェントの検証を繰り返しました。

codex exec --yolo \
  --ephemeral --json \
  "Run exactly these two shell commands, one at a time, with your shell tool, and report the exit code and output of each. Do not retry and do not run anything else: 1) touch ~/codex-agent-probe  2) curl -sS -m 5 -o /dev/null -w '%{http_code}' https://example.com"

2つのコマンドは、先ほどのホームディレクトリへの書き込みとcurlリクエストです。今回はホームディレクトリにファイルが作成され、リクエストはHTTP 200を返しました。その後、検証用ファイルを削除しました。Codexのyoloモードは、プロジェクトの外へのアクセスを許可します。

LizardとDocker Sandboxesはどちらも、microVM内で長いバイパスフラグを付けてCodexを起動します。これは想定した使い方に沿っています。VMが外側の境界を提供します。ただし、そのVM内のファイルをエージェントから保護するわけではありません。Docker SandboxesはデフォルトのCodexコマンドを公開しています。Lizardのコマンドはテスト中に確認しました。

DockerでCodexを実行する

次のDockerfileをテストしました。

FROM node:22-bookworm-slim
RUN apt-get update && apt-get install -y --no-install-recommends git python3 ca-certificates curl \
 && rm -rf /var/lib/apt/lists/*
RUN npm install -g @openai/codex@0.162.1
WORKDIR /workspace

codex-sandbox-testとしてビルドします。私たちのプロジェクトはローカルのappフォルダにありました。CODEX_DIRは、ChatGPTのログイン情報のコピーを保存した、別の既存フォルダを指していました。次を実行しました。

docker run --rm \
  -v "$PWD/app:/workspace/app" \
  -v "$CODEX_DIR:/codex-home" \
  -e CODEX_HOME=/codex-home \
  -w /workspace/app \
  codex-sandbox-test codex exec -s workspace-write --ephemeral \
  "Run python3 -m unittest. Fix the failing test with the smallest reasonable change to the code under test, not the test. Run the tests again and report what changed."

テスト用コードのadd(a, b)は入力値を引き算していました。Codexはreturn a - bをreturn a + bに変更しました。Codexのテスト実行と、ホストでの独立したテスト実行は両方とも成功しました。書き込み可能なプロジェクトマウントにより、その編集がホストに反映されました。

この標準設定のDocker Desktopコンテナでは、追加のケーパビリティやbubblewrapパッケージのインストールなしでLinuxサンドボックスも動作しました。Codexに同梱されたヘルパーはプロジェクトへの書き込みを許可し、/rootへの書き込みをRead-only file systemでブロックしました。ネットワークアクセスもブロックしました。

この結果はすべてのホストに当てはまるものではありません。OpenAIは、Dockerの設定がCodexに必要な名前空間、setuid bubblewrap、seccompの操作をブロックする場合があると警告しています。内側のサンドボックスを実行できない場合は、コンテナを境界として構成してから、次を使用します。

codex --sandbox danger-full-access

先にマウント、権限、ネットワークポリシーを確認してください。OpenAIのコンテナのガイドは、悪意のあるプロジェクトが、Codexの認証情報を含め、dev container内で利用できるものを外部に送信できると警告しています。

コンテナ内で認証する

自動化では、CODEX_API_KEYが非対話型のCodexプロセスにキーを渡します。必要な実行だけに使用を限定してください。既存の環境変数からAPIキーによるログインを保存するには、次を実行します。

printenv OPENAI_API_KEY | codex login --with-api-key

デバイスコードでログインする場合：

codex login --device-auth

アカウントまたはワークスペースの設定でデバイスログインを有効にする必要があります。テストで行ったように、ログイン済みのマシンからauth.jsonをコピーする方法もあります。auth.jsonはパスワードと同様に扱ってください。アクセストークンを保持しています。キーリングを使用するログインでは、コピーに使えるファイルが残らない場合があります。認証とCODEX_API_KEYを参照してください。

DockerコンテナとDocker Sandboxesの違い

Docker Sandboxesは、別のCLIであるsbxを使用します。

sbx run codex ~/my-project

各サンドボックスは独自のLinuxカーネルと専用のDocker Engineを持ちます。ホストのプロキシがモデルの認証情報をVMの外に保持し、外向きのリクエストに追加します。ネットワークルールは、許可のない通信を拒否します。初回起動時のプリセットはOpen、Balanced、Locked Downです。Balancedは一般的な開発サイトを許可します。Locked Downにはモデルプロバイダーの明示的なルールが必要です。分離、認証情報の扱い、プリセットを参照してください。

ローカルでの要件は、Apple silicon上のmacOS Sonoma 14+、Windows Hypervisor Platformを備えたIntel/AMD上のWindows 11、またはKVMを備え、kvmグループに所属するx86-64/arm64上のUbuntu 24.04+です。Docker Desktopは不要です。VM内でsbxのローカルサンドボックスを実行するには、ネストされた仮想化が必要です。インストールガイドを確認してください。

Docker Sandboxesはテストしていません。デフォルトのバイパスフラグは、Gitフックを含むマウント済みのプロジェクトファイルを書き込み可能なままにします。実行後に確認してください。

クラウドサンドボックスが役立つ場合

リモートコンピューティングは、ラップトップの切断後もタスクを続ける必要がある場合や、複数のエージェントに別々のワークスペースが必要な場合に役立ちます。各タスクに必要なコードと認証情報だけを共有してください。

Codex Cloudの現在のドキュメントでは、タスクごとにVMを用意すると説明しています。環境単位のインターネット設定では、パッケージマネージャーとドメインの許可リスト、または無制限のアクセスを選べます。環境変数はプログラムに直接渡ります。ネットワークシークレットにはプレースホルダーを使用し、プロキシがポート443の許可済みHTTPS宛先に対してそれを置き換えます。クラウド機能には、対応するChatGPTプランのPlus、Pro、Business、Enterpriseが必要です。APIキー認証には含まれません。Codex Cloudはテストしていません。クラウド環境、プラン、Codex Cloudのガイドを参照してください。

Lizard Sandboxesは、独自のカーネルを持つFirecracker microVMでタスクを実行します。私たちはLizard Sandboxesを販売しています。CLIから作成、実行、一時停止できるリモートワークスペースが必要な場合に推奨します。ローカル作業では、Codexの組み込みサンドボックスから始めてください。

Lizard SandboxesでCodexを実行する

Lizard CLIをインストールし、サインインしてプロジェクトを選択します。ChatGPTサブスクリプションを接続します。

lizard agents login chatgpt

または、OpenAI APIキーを登録します。

lizard agents add openai

接続を確認します。

lizard agents status

テストでは接続済みのChatGPTサブスクリプションを使用しました。サインインは繰り返していません。

プロジェクトを作成してコピーする

プロジェクトのプレースホルダーを置き換えます。

lizard sandbox create --project YOUR_PROJECT_ID --template codex --size small --timeout 3600000 --json

返されたサンドボックスIDをSBに、既存のローカル一時フォルダをBUNDLE_DIRに設定します。このタイムアウトにより、ワークスペースの有効期間は1時間になります。デフォルトは5分で、コマンドを実行しても延長されません。

ローカルリポジトリから実行します。

git bundle create "$BUNDLE_DIR/app.bundle" HEAD
lizard sandbox files put "$SB" "$BUNDLE_DIR/app.bundle" /workspace/app.bundle
lizard sandbox exec "$SB" -- git clone /workspace/app.bundle /workspace/app

バンドルにはコミット済みの履歴と、その中のシークレットも含まれます。未コミットのファイルは含まれません。送信する内容を確認してください。

タスクを実行する

lizard sandbox prompt "$SB" --agent codex --cwd /workspace/app "Run the tests. Fix one failing test with the smallest reasonable change. Report what changed and which tests passed."

--agent codexを明示してください。テスト中のプロセス一覧には、次のコマンドが表示されました。

codex exec --json --skip-git-repo-check --dangerously-bypass-approvals-and-sandbox -C /workspace/app "<prompt>"

Codex自体のサンドボックスと承認は無効で、Firecracker microVMが分離を提供していました。内部のコードは、プロセスが利用できる認証情報にアクセスできます。その権限範囲を狭くしてください。VMはこれらの認証情報をエージェントから隠しません。

確認、ダウンロード、一時停止

差分を確認し、プロジェクトのテストを再実行して、最後の一時停止コマンドの前に必要なファイルを保存します。

lizard sandbox exec "$SB" -- git -C /workspace/app status --short
lizard sandbox exec "$SB" -- git -C /workspace/app diff
lizard sandbox files get "$SB" /workspace/app/calc.py ./calc.py.review
lizard sandbox pause "$SB"

テスト用コードではcalc.pyを使用しました。同じ手順を行う際は、自分の変更したファイルを選択してください。Codexは引き算のバグを修正し、別途実行したunittestはOKを出力しました。ダウンロードしたファイルも一致しました。ステータスがpausedであることを確認しました。

期限切れの前に結果を保存してください。一時停止が成功するとコンピューティングの課金が止まります。Persistent Volumesのストレージ料金は別です。ライフサイクルの詳細は、クイックスタートとサンドボックスCLIリファレンスを参照してください。

クラウドワークスペースのコスト

2026年10月21日時点のLizardのコンピューティング料金です。

コンピューティングは、アイドル時間を含む実行中の時間に対して秒単位で課金します。一時停止が成功するとコンピューティング料金が止まります。Persistent Volumesのストレージは別途課金します。

Lizard Proは月額$19（税込み）で、$19分の使用量が含まれます。追加の使用量はpay as you goです。新規アカウントには$5分の使用量が含まれる7日間のトライアルを提供します。カードの登録が必要です。ChatGPTまたはOpenAI APIの料金は別です。実行前に料金を確認してください。

よくある設定の問題

テスト内容

2026年10月21日に、Apple silicon（arm64）のmacOS 26.6.2上で、npmのCodex CLI 0.162.1をテストしました。ホームディレクトリ配下の新規Gitリポジトリを使用しました。ChatGPTログインでサンドボックスコマンドとエージェントのシェル呼び出しを確認し、バイパスした場合との比較も行いました。

Dockerのテストでは、Docker Desktop、Docker Engine 28.1.1、arm64、LinuxKitカーネル6.10を使用しました。サンドボックスの制限とPythonテストの修正を確認し、ホストでもテストを再実行しました。

LizardのテストではLizard CLI 4.0.65を使用しました。codexテンプレートには、Codex CLI 0.159.2、Node.js 22.23.2、Python 3.11.2、git 2.39.5が含まれていました。バンドルのアップロード、クローン作成、タスク、別途実行するテスト、差分の確認、ダウンロード、一時停止を検証しました。

Docker Sandboxes、Codex Cloud、ネイティブWindows/WSL2、OpenAIのrun_in_container.sh、新規アカウント登録はテストしていません。これらの確認は記録した構成を対象とするもので、セキュリティ監査ではありません。

どの設定を選択すべきか

既知のファイルとツールを使うローカル作業にはworkspace-writeを使用します。再現可能なランタイムにはDockerを選び、Codexの内側のサンドボックスがそこで動作するかをテストしてください。ローカルのmicroVM分離とホストでの認証情報の保持にはDocker Sandboxes、ChatGPT内のタスクにはCodex Cloudを検討します。

Lizard CLIを通じてリモートワークスペースを使いたい場合は、Lizard Sandboxesを選択します。小さなテスト修正を1つ行うところから始め、差分を確認し、結果をダウンロードしてワークスペースを一時停止してください。