（更新: ）

Codexの承認・sandbox・YOLOの違いを整理する

この記事は、Codex CLI を途中で止めにくく運用したい開発者向けです。AGENTS.md、承認方針、sandbox、web search がそれぞれ何を決めるのかを分けて整理します。読了後には、安全性を崩しすぎずに自分に合う自動化レベルを選べるようになります。

2026年3月31日時点の OpenAI Developers の公式ドキュメントをベースに、設定手順ではなく考え方とトレードオフに絞ってまとめます。

TL;DR

  • Codex が止まる理由は、会話上の確認と実行環境側の承認・制約で別物です
  • AGENTS.md で減らせるのは主に前者です
  • OpenAI の公式ドキュメントでは、ローカル既定は「workspace-write + network access off + approval policy」です
  • web_search はネットワーク許可と別で考える必要があります。最新情報重視なら live、安定性重視なら cached が向きます
  • 実務では「完全に止めない」より「どこで止まるべきかを設計する」ほうが失敗しにくいです

Codex が止まる理由は 2 種類ある

結論として、Codex が止まる理由は 1 つではありません。方針の確認で止まる場合と、実行権限の境界で止まる場合を分けて考えると整理しやすくなります。

レイヤー何が原因か典型例AGENTS.md で減らせるか
会話上の確認エージェントが方針を決めきれないどこまで直すか、破壊的変更を含めるか、関連ドキュメントまで更新するか減らしやすい
実行環境側の承認・制約sandbox / approval policy / network の境界workspace 外への書き込み、ネットワーク利用、危険なコマンド原則として減らせない

OpenAI Developers の Agent approvals & security では、Codex の安全制御は sandbox mode と approval policy の 2 層で説明されています。前者は「技術的に何ができるか」、後者は「いつ人に聞くか」です。

会話上の確認は、依頼の曖昧さが原因になりやすい

この層で止まる場合は、Codex が慎重すぎるというより、判断材料が不足しています。たとえば次のようなケースです。

  • どの案を採用すべきか決めきれない
  • 変更範囲が Issue 本文だけでは読めない
  • テストやドキュメント更新をどこまで含めるか不明
  • 既存スタイルより新しい案を優先してよいか不明

この種の停止は、依頼文と AGENTS.md を整えるだけでかなり減ります。

実行環境側の停止は、設定を変えない限り残る

一方で、sandbox や承認設定による停止は、プロンプトだけでは消えません。2026年3月31日時点の公式ドキュメントでは、ローカル実行時は 既定で network access が off で、書き込みは通常 workspace に制限 されます。

つまり、次のような操作は AGENTS.md を丁寧に書いても止まるか、失敗として返る可能性があります。

  • workspace 外への書き込み
  • ネットワークを使うコマンドの実行
  • 権限昇格や破壊的な操作
  • side effect を持つ connector / MCP tool の実行

ここで重要なのは、確認を減らすことと権限を増やすことは別だという点です。

AGENTS.md でできること、できないこと

結論として、AGENTS.md は強力ですが、役割は「行動方針の固定」であって「権限の変更」ではありません。

OpenAI Developers の AGENTS.md ガイド では、Codex は作業開始前に AGENTS.md を読み、グローバル設定とプロジェクト設定を順に重ねると説明されています。つまり AGENTS.md は、毎回の細かな確認を減らすための共通ルール置き場として有効です。

AGENTS.md が効く範囲

たとえば、次のようなルールは実務で効きやすいです。

  • 不明点は合理的に仮定して進める
  • 最小差分で変更する
  • 実装後に lint やテストまで進める
  • 既存スタイルを優先する
  • 破壊的変更だけ確認する

この種のルールがあると、軽微な判断で毎回止まりにくくなります。

AGENTS.md では消せない範囲

一方で、AGENTS.md に「確認せず進めてよい」と書いても、sandbox や approval policy の境界は変わりません。

よくある誤解実際
AGENTS.md を書けば Yes / No が全部消える消えません
プロンプトで「外にも書いてよい」と伝えれば権限が増える増えません
ネットワークを使ってよいと会話で伝えれば常に通る設定次第で止まるか失敗します

ここは、OpenAI Developers の説明を踏まえると、AGENTS.md は判断の一貫性を作るもの、approval policy と sandbox は実行境界を作るものと覚えると混乱しません。

自動化レベルは 3 段階で考えると整理しやすい

結論として、Codex の運用は「安全寄り」「バランス型」「YOLO 相当」の 3 段階で考えると判断しやすいです。

--yolo は --dangerously-bypass-approvals-and-sandbox の公式エイリアスで、sandbox と approval policy の両方を同時に無効化します。この記事では、それに準ずる --sandbox danger-full-access（sandbox のみを danger 設定）も含め、強い自動化寄り構成を「YOLO 相当」とまとめて呼びます。

レベル典型構成のイメージ向いている用途主な注意点
安全寄りread-only、または approval 多め初期導入、検証、共有 PC中断が多くなりやすい
バランス型--full-auto（workspace-write + on-request）を起点に確認を減らす日常開発の多くworkspace 外や network が必要な処理は止まる
YOLO 相当--yolo（--dangerously-bypass-approvals-and-sandbox）など隔離された検証環境、高速試行誤操作時の被害範囲が広い

多くの人に現実的なのはバランス型

普段の開発でいちばん扱いやすいのは、sandbox を残したまま会話上の確認を減らすバランス型です。リポジトリ内の編集、テスト、軽い調査を自動で進めやすく、それでいて被害範囲も限定しやすいからです。

公式には --full-auto という convenience alias があり、--sandbox workspace-write と --ask-for-approval on-request を同時に設定します。バランス型を試す出発点として扱いやすい構成です。

一方で、この構成は「何でも自動化できる」わけではありません。workspace 外に出る処理や network が必要な処理は、承認か失敗のどちらかになります。

YOLO 相当は、速さより隔離のほうが重要

YOLO 相当を選ぶなら、設定より先に環境分離を考えるべきです。壊れても困らない worktree、使い捨てコンテナ、検証用 VM のように、外側で安全境界を作れる前提 が必要です。

強い設定そのものより、強い設定を置く場所のほうが重要です。

web_search=live とネットワーク許可は別で考える

結論として、web_search と network_access は似ていますが別物です。最新情報が要る場面では web_search=live が有効ですが、ローカルコマンドの通信可否までは同時に決まりません。

OpenAI Developers の Agent approvals & security では、workspace-write の既定では network access は off のままで、必要なら次のように有効化すると説明されています。

[sandbox_workspace_write]
network_access = true

同じページでは、web_search は OpenAI-maintained index を使う cached が既定 で、必要に応じて live や disabled を選べると説明されています。なお、--yolo や danger-full-access モードを使っている場合、web_search は自動的に live に切り替わります。

何が違うのか

項目影響するもの向いている場面
network_accessエージェントが実行するコマンドの通信可否パッケージ取得、API 検証、外部サービス接続
web_searchWeb 検索ツールの結果取得方式仕様確認、価格、最新リリースの確認

この違いを理解していないと、「検索はできるのに curl は失敗する」「ネットワークを許可したのに Web 検索は cached のまま」という挙動が分かりにくくなります。

live が向く場面と不利な場面

live が向くのは、日付依存で古い情報が危険な場面 です。

  • 直近のリリースや更新履歴
  • 料金やプラン
  • 仕様変更が早いサービス
  • 障害情報や現在ステータス

一方で、毎回 live が最適とは限りません。

  • 取得のたびに遅くなりやすい
  • 結果のぶれが出やすい
  • ノイズが増えやすい
  • ローカル repo 中心の作業では不要なことが多い

つまり、live は「強い」設定ではなく、鮮度を優先する設定 と考えると実務で扱いやすいです。

実務では「止めない」より「止まる場所を選ぶ」が大事

結論として、完全無停止を目指すより、どこでは止まり、どこでは止まらなくてよいかを決める ほうが運用は安定します。

おすすめは次の順番です。

  1. まず AGENTS.md で会話上の確認を減らす
  2. 次に approval policy と sandbox の役割を分けて理解する
  3. 必要な場合だけ network_access を有効にする
  4. 最新情報が重要な作業だけ web_search=live を使う
  5. それでも足りない場合にだけ YOLO 相当を検討する

この順番なら、安全境界を一気に崩さずに、詰まりやすい場所だけを順に解消できます。

前提別のおすすめ

前提向いている選択
まずは安心して試したい安全寄り
普段の開発を快適にしたいバランス型
隔離環境で高速に試行したいYOLO 相当
最新仕様の確認が多いweb_search=live を検討
repo 内編集が中心web_search=cached でも十分なことが多い

まとめ

  • Codex の停止要因は、会話上の確認と実行環境側の承認・制約で分けて考える
  • AGENTS.md で減らせるのは主に前者で、後者は approval policy や sandbox の役割
  • network_access と web_search は別の設定で、用途も違う
  • 多くの実務では、sandbox を残したバランス型が扱いやすい
  • 完全無停止より、止まる場所を設計するほうが安全で快適

次に試すなら、自分の運用で次の 2 点だけを先に決めると整理しやすいです。

  • 「どの操作だけは必ず止まるべきか」
  • 「最新情報が必要な作業はどれか」

この 2 つが決まると、AGENTS.md、approval policy、sandbox、web search の線引きがかなり明確になります。

参考リンク