Codex のサンドボックス3モードと承認設定の使い分け方
Codex にコードの修正やコマンド実行を任せるとき、どのファイルまで触れてよいか、ネットワークに出てよいかを決めるのがサンドボックスだ。境界が緩すぎれば思わぬ書き換えや外部通信につながり、厳しすぎれば「確認待ち」で作業が止まる。隔離して安全に走らせるという論点は、2026年6月に各社が足並みをそろえて整備を進めた主題でもある。本記事では Codex の3つのサンドボックスモードと承認設定の関係を、公式ドキュメントに沿って使い分けの観点から整理する。
Codex の実行範囲は sandbox_mode という一つの設定で大きく決まる。値は read-only・workspace-write・danger-full-access の3つで、読み取りだけを許す、作業フォルダ内の書き込みとコマンド実行まで許す、制限なしで全アクセスを許す、と段階が上がる。ローカル作業の既定は workspace-write で、書き込みは作業フォルダに閉じ、ネットワークは既定で遮断される（出典: https://developers.openai.com/codex/concepts/sandboxing ）。
サンドボックスと対になるのが approval_policy（承認ポリシー） だ。untrusted は安全な読み取りだけを通し、状態を変える操作には確認を求める。on-request はサンドボックス内で進め、その外に出るときだけ確認する。never は確認を一切挟まない。Codex はこの2軸を プリセットとして束ね、Read Only・Auto・Full Access という分かりやすい単位で選べるようにしている（出典: https://developers.openai.com/codex/agent-approvals-security ）。
恒常的に固定したいときは ~/.codex/config.toml に sandbox_mode と approval_policy を書き、[sandbox_workspace_write] の network_access でネットワーク可否まで調整できる。隔離の実体は OS の仕組みが担い、macOS は Seatbelt、Linux / WSL2 は bubblewrap を使う。隔離と遠隔実行の整備が各社で進む今、どこまで任せるかを最初に決めておくことが、事故と手戻りの両方を避ける近道になる（出典: https://developers.openai.com/codex/config-reference ）。
目次 (14)
- Codex のサンドボックスとは — 実行境界を一つの設定で決める
- なぜ今サンドボックスなのか — 隔離実行が各社の主題に
- 3つのサンドボックスモード — read-only / workspace-write / danger-full-access
- 既定が workspace-write である意味 — 攻めと守りの中間点
- 承認ポリシーの3段階 — untrusted / on-request / never
- サンドボックスと承認は別の軸 — 混同しないための整理
- プリセットで選ぶ — Read Only・Auto・Full Access の使い分け
- Full Access を選ぶ前に確認したいこと
- config.toml で固定する — sandbox_mode と [sandbox_workspace_write]
- writable_roots とネットワークを「必要な分だけ」開ける
- OS ごとの隔離の実体 — Seatbelt・bubblewrap・Windows Sandbox
- 隔離が効かない環境での挙動を見落とさない
- 安全に任せるための選び方
- まとめ — 最初に「どこまで」を決める
Codex のサンドボックスとは — 実行境界を一つの設定で決める
サンドボックスは、Codex が実行するファイル操作やコマンドを「ここまで」と囲う安全柵だ。Codex はモデルが判断して自分でファイルを編集したりコマンドを走らせたりするため、その範囲を人が事前に決めておかないと、意図しないディレクトリの書き換えや外部への通信が起こりうる。公式ドキュメントは実行範囲を sandbox_mode という設定で表し、ローカル作業の既定を workspace-write、つまり「読み取りと、作業フォルダ内での編集・通常のローカルコマンドの実行」までに置いている（出典: https://developers.openai.com/codex/concepts/sandboxing ）。重要なのは、サンドボックスが「何ができるか」を、承認ポリシーが「いつ人に確認するか」を担い、この2軸の組み合わせで実際の振る舞いが決まるという点だ。片方だけを緩めても、もう片方が締まっていれば確認待ちで止まる。両者をセットで理解しておくことが、過不足のない権限設計の出発点になる。
なぜ今サンドボックスなのか — 隔離実行が各社の主題に
権限境界の話題が一段と前面に出たのは、ごく最近の動きと無関係ではない。2026年6月2日には GitHub が Copilot のクラウド／ローカルのサンドボックスをパブリックプレビューに乗せ、エージェントを隔離環境で安全に走らせる方向を打ち出した（出典: https://github.blog/changelog/label/copilot/ ）。OpenAI 側でも Codex CLI が 0.137.0 へ到達し、遠隔クライアントとのペアリングなど「どこで実行させるか」の幅が広がっている（出典: https://developers.openai.com/codex/changelog ）。エージェントを任せる範囲が端末をまたいで広がるほど、その実行がどの境界の内側で動いているのかを把握しておく価値は高まる。常緑のテーマに見えて、いま改めて設定を見直す理由がそろっている。
3つのサンドボックスモード — read-only / workspace-write / danger-full-access
サンドボックスの中身は3段階だ。read-only は「Codex はファイルを調べられるが、承認なしには編集もコマンド実行もできない」モードで、調査や読解だけを任せたい場面に向く。workspace-write は「ファイルを読み、作業フォルダ内で編集し、その境界内で通常のローカルコマンドを実行できる」モードで、ローカル開発の既定でもある。ここでは書き込みが作業フォルダに閉じ、ネットワークアクセスは既定で遮断される。danger-full-access は「サンドボックスの制限なしで動く」モードで、ファイルシステムとネットワークの境界がともに外れる。公式ドキュメントは、このモードは Codex に全アクセスで動いてほしいときに限って使うべきだと明記している（出典: https://developers.openai.com/codex/concepts/sandboxing ）。三者の違いを整理すると次のとおりだ。
sandbox_mode |
ファイル読み取り | 作業フォルダ内の編集・実行 | ネットワーク | 主な用途 |
|---|---|---|---|---|
read-only |
可 | 不可（承認が必要） | 不可 | 調査・読解・レビュー |
workspace-write（既定） |
可 | 可 | 既定で不可 | 通常のローカル開発 |
danger-full-access |
可 | 制限なし | 可 | 全アクセスが必要な特殊作業 |
既定が workspace-write である意味 — 攻めと守りの中間点
ローカル作業の既定が workspace-write に置かれているのは、実用とのバランスの結果だ。read-only では編集のたびに承認を挟むため自律的な作業が進みにくく、danger-full-access では守りが薄くなる。その中間として、書き込みを作業フォルダに閉じ、ネットワークを既定で断った workspace-write が「日常的に任せても事故が起きにくい」既定として選ばれている。逆に言えば、外部 API を叩く検証など作業フォルダの外やネットワークが要る作業では、既定のままだと境界に阻まれる。そのときに初めて、後述の network_access や承認ポリシーで境界を一段だけ緩める、という考え方が筋になる。
承認ポリシーの3段階 — untrusted / on-request / never
承認ポリシー（approval_policy）は「Codex がコマンドを実行する前に、どこで人に確認を求めるか」を決める。公式ドキュメントが挙げる値は3つだ。untrusted は、既知の安全な読み取り操作だけをそのまま通し、状態を変える操作や外部実行を伴う操作には承認を求める、もっとも慎重な設定にあたる。on-request は、Codex がサンドボックス内では確認なしに進め、その境界の外に出る必要が生じたとき（書き込み先の拡大やネットワークアクセスなど）にだけ承認を求める。never は承認プロンプトを一切出さない設定で、--ask-for-approval never（短縮形 -a never）で指定する。さらに細かく制御したい場合は approval_policy = { granular = { ... } } の表形式で、承認を挟むカテゴリと自動的に拒否するカテゴリを個別に決められる（出典: https://developers.openai.com/codex/agent-approvals-security ）。
サンドボックスと承認は別の軸 — 混同しないための整理
ここで取り違えやすいのが、「サンドボックスを緩める」と「承認を省く」が別物だという点だ。サンドボックスは物理的に何ができるかの天井を決め、承認ポリシーはその天井に達する前に人へ確認するかどうかを決める。例えば workspace-write に on-request を合わせると、作業フォルダ内なら確認なしで進み、ネットワークに出る段になって初めて確認が入る。一方で never を選べば、サンドボックスの天井までは確認なしで進む。天井そのものは sandbox_mode が決めているので、承認を省いても危険な全アクセスにはならない。2軸を分けて捉えると、「どこまで許すか」と「いつ口を挟むか」を独立に調整できるようになる。
プリセットで選ぶ — Read Only・Auto・Full Access の使い分け
毎回2軸を手で組むのは煩雑なので、Codex はよく使う組み合わせをプリセットとして用意している。公式ドキュメントが示す対応は次のとおりだ。Auto は --sandbox workspace-write --ask-for-approval on-request に相当し、作業フォルダ内での読み書きと通常のコマンド実行までを確認なしで任せ、その外へ出るときだけ確認する標準的な使い方になる。Read Only は --sandbox read-only --ask-for-approval on-request で、編集や実行の前に必ず確認が入る安全寄りの構成だ。CI などノンインタラクティブな実行では --sandbox read-only --ask-for-approval never を使い、確認を待たずに読み取りだけで走らせる。全アクセスが要るときは --dangerously-bypass-approvals-and-sandbox（別名 --yolo）で、サンドボックスと承認の両方を外す（出典: https://developers.openai.com/codex/agent-approvals-security ）。
| プリセット | sandbox_mode |
approval_policy |
指定するフラグ |
|---|---|---|---|
| Read Only | read-only |
on-request |
--sandbox read-only --ask-for-approval on-request |
| Read Only（CI 向け） | read-only |
never |
--sandbox read-only --ask-for-approval never |
| Auto | workspace-write |
on-request |
--sandbox workspace-write --ask-for-approval on-request |
| Full Access | danger-full-access |
（バイパス） | --dangerously-bypass-approvals-and-sandbox（--yolo） |
Full Access を選ぶ前に確認したいこと
Full Access はファイルシステムとネットワークの境界をともに外すため、便利な反面リスクも最大になる。設定上は sandbox_mode = "danger-full-access" と approval_policy = "never" の組み合わせに相当し、Codex が確認なしで全アクセスのコマンドを走らせられる。公式ドキュメントも、このモードは全アクセスで動いてほしいと明確に意図したときに限る、という位置づけにしている。実務では、信頼できる隔離されたコンテナの中など「外に影響が漏れない場所」でのみ使い、手元のマシンや本番に近い環境では避けるのが無難だ。日常はあくまで Auto を基準にし、どうしてもネットワークや作業フォルダ外が要る局面だけ、範囲と時間を限って引き上げる運用が安全側に倒れる。
config.toml で固定する — sandbox_mode と [sandbox_workspace_write]
フラグを毎回付けるのではなく既定を固定したいときは、~/.codex/config.toml に設定を書く。トップレベルの sandbox_mode（"read-only" / "workspace-write" / "danger-full-access"）と approval_policy を指定すれば、起動時の既定がそのまま決まる。さらに workspace-write の細部は [sandbox_workspace_write] セクションで詰められる。ここには、外向きのネットワークアクセスを許すかを決める network_access、追加で書き込みを許可するルートを並べる writable_roots、$TMPDIR を書き込み可能ルートから外す exclude_tmpdir_env_var、/tmp を同様に外す exclude_slash_tmp といったキーがある（出典: https://developers.openai.com/codex/config-reference ）。既定では workspace-write のネットワークは閉じているので、外部取得を伴う作業を恒常的に行うなら network_access を明示的に開ける必要がある。
writable_roots とネットワークを「必要な分だけ」開ける
設定を詰めるときの勘どころは、全部を一度に緩めないことだ。例えばビルド成果物を作業フォルダの外に書きたいだけなら、danger-full-access に切り替えるのではなく writable_roots にそのパスを足すほうが影響範囲は小さい。同様に、外部のパッケージ取得が要るだけなら network_access を開ければ十分で、書き込み境界まで緩める理由にはならない。exclude_tmpdir_env_var や exclude_slash_tmp は、共有の一時領域を経由した予期しない書き込みを避けたいときに効く。こうして「足りない一手だけを開ける」発想で設定すると、利便性を確保しつつ守りの面積を最小限に保てる。最新のキー仕様は版によって増減があるため、openai/codex の公式ドキュメントとリポジトリ（https://github.com/openai/codex ）を起点に確認しておくと取り違えを防げる。
OS ごとの隔離の実体 — Seatbelt・bubblewrap・Windows Sandbox
サンドボックスは Codex 独自の仕掛けではなく、OS が備える隔離の仕組みに支えられている。公式ドキュメントによれば、macOS では組み込みの Seatbelt フレームワークを使い、Linux と WSL2 では bubblewrap（ユーザー名前空間を使った隔離ツール）を用いる。bubblewrap が使えない環境では、特権なしのユーザー名前空間が有効であることを前提とした同梱のヘルパーにフォールバックする。Windows では PowerShell 上でネイティブの Windows Sandbox を使い、WSL2 側では Linux のサンドボックス実装が用いられる（出典: https://developers.openai.com/codex/concepts/sandboxing ）。つまり、同じ sandbox_mode = "workspace-write" でも、隔離を実際に強制しているのは下回りの OS 機能だ。この前提を知っておくと、特定の環境で隔離が効かない・起動しないといった事象に出くわしたとき、どの層を疑えばよいかの当たりがつけやすくなる。
隔離が効かない環境での挙動を見落とさない
注意したいのは、OS の機能が前提を満たさない環境では、隔離そのものが立ち上がらない場合があることだ。特権なしユーザー名前空間が無効化されたコンテナや、サンドボックス機構を欠く実行基盤では、フォールバックも含めて期待どおりの境界が張れないことがある。そうした環境で workspace-write を指定しても、設定の見た目とは裏腹に守りが薄くなる可能性がある。隔離が効かない場でエージェントを走らせるなら、コンテナ自体を使い捨てにする、ネットワークを基盤側で遮断する、といった一段外側の対策を併用するのが現実的だ。設定値だけでなく、それを支える土台が機能しているかまで含めて確認する姿勢が安全につながる。
安全に任せるための選び方
最後に、過不足のない設定にたどり着くための順序を整理する。次の流れで一段ずつ緩めると、守りを保ったまま必要な自由度だけを足せる。
- 既定の Auto から始める: まずは
workspace-write＋on-request（Auto）を基準にする。作業フォルダ内の読み書きと実行は任せ、その外へ出るときだけ確認が入るため、多くの開発作業はこれで足りる。 - 足りない一手だけを開ける: 外部取得が要るなら
network_access、作業フォルダ外への書き込みが要るならwritable_rootsと、欠けている権限だけをピンポイントで足す。モードごとdanger-full-accessに上げない。 - 確認の頻度を用途で調整する: 慎重に進めたい初回や未知のコードでは
untrusted、流れを止めたくない定型作業ではon-requestと、承認ポリシーを場面で切り替える。 - 全アクセスは隔離環境に限定する:
Full Access（danger-full-access＋never）は、外部に影響が漏れない使い捨てのコンテナ内などに限り、手元や本番に近い環境では避ける。 - 常用する組み合わせは config.toml に固定する: 毎回フラグを付け直す手間を省くため、定まった設定は
~/.codex/config.tomlに書き出し、プロジェクトの性格に合わせて既定化する。
この順序の利点は、「困ったら全部開ける」ではなく「足りない分だけ開ける」発想が自然に身につくことだ。境界を一段ずつ緩めれば、どの操作のためにどの権限を足したのかが明確になり、後から設定を読み返したときにも意図を追いやすい。
まとめ — 最初に「どこまで」を決める
Codex のサンドボックスは、read-only・workspace-write・danger-full-access の3モードで「何ができるか」を、untrusted・on-request・never の承認ポリシーで「いつ確認するか」を決める2軸の仕組みだ。両者は Read Only・Auto・Full Access のプリセットとして束ねられ、フラグや ~/.codex/config.toml で選べる。既定の workspace-write ＋ on-request を基準に、network_access や writable_roots で足りない一手だけを開け、全アクセスは隔離環境に限る——この使い分けを最初に決めておくことが、事故と手戻りの両方を避ける最短ルートになる。隔離と遠隔実行の整備が各社で進む今こそ、自分のサンドボックス設定を一度見直しておきたい。
