Codex CLIの承認モードとサンドボックスの使い分けと安全な設定

Codex CLIを安全に自動実行させる設定の要点は、承認ポリシー（いつ人に確認するか）とサンドボックス（技術的に何ができるか）を別々のつまみとして決めることです。OpenAI公式のドキュメントでも、この2つは「サンドボックスモード」と「承認ポリシー」という別の層として説明されています。公式の Agent approvals & security ページには、読み取り専用、ワークスペース書き込み、承認なしといった組み合わせの早見表も載っています。

この記事は、設定ファイルの全項目やconfig.tomlの優先順位を解説する記事とは角度を変え、「どの場面でどの組み合わせを選ぶか」に絞ります。公式ページに書かれているモード名・フラグ名・設定値だけを使い、書かれていないオプションは扱いません。コマンド例はすべて「仮の例」で、実際のプロジェクトに合わせて読み替えてください。

先に結論を3つ並べます。ひとつ目は、迷ったら workspace-write と on-request の組み合わせから始めることです。ふたつ目は、承認を止める never を使うなら、サンドボックスは狭いまま残すことです。みっつ目は、サンドボックスごと外す設定は、隔離された環境の中だけに限ることです。以降は、この3点を公式の記述に沿って具体的に確かめていきます。

承認ポリシーとサンドボックスの役割の違い

サンドボックスは「実行されたコマンドが技術的に触れる範囲」を決める仕組みで、承認ポリシーは「その範囲を超える前や特定の操作の前に人へ確認する条件」を決める仕組みです。

公式ページは、Codexのセキュリティ制御が2つの層で成り立つと説明しています。ひとつはサンドボックスモードで、モデルが生成したコマンドを実行するときに、どこへ書き込めるか、ネットワークに届くかといった技術的にできることを決めます。もうひとつは承認ポリシーで、サンドボックスの外へ出る、ネットワークを使う、信頼済みの範囲外のコマンドを実行するといった行動の前に、Codexがユーザーへ確認しなければならない条件を決めます。

層	決めること	主な設定名	たとえる場面
サンドボックス	触れる範囲（書き込み先・ネットワーク）	sandbox_mode / --sandbox	作業部屋の壁と鍵
承認ポリシー	確認が入るタイミング	approval_policy / --ask-for-approval	部屋を出るときの声かけルール

この2層を混同すると、設定の意図がずれます。たとえば「承認を求められるのが煩わしい」という理由だけで承認を切ると、確認なしで進む度合いが上がります。公式は、承認プロンプトを無効にする never がすべてのサンドボックスモードと組み合わせられ、Codexは設定した制約の範囲内でベストエフォートに動くと説明しているため、サンドボックス側の範囲は別に決めておく必要があります。逆に「危険だから」と読み取り専用に絞っても、承認ポリシーを緩めているとどこまで進むかが読みにくくなります。2つを別々に決めて、最後に組み合わせとして読む習慣が、設定ミスを防ぎます。

公式ページは、ローカルで使うCodex CLIとIDE拡張ではOSレベルの仕組みでサンドボックスが強制されると説明しています。既定ではネットワークなし、書き込みは現在のワークスペースに限定された状態から始まり、リスク許容度に合わせて、サンドボックス・承認ポリシー・ネットワーク設定を調整できます。この記事の残りは、その調整をどの順で考えるかの整理です。

サンドボックスモードの3つの値と選び方

サンドボックスモードは read-only、workspace-write、danger-full-access の3つで、左から順にCodexが触れる範囲が広がります。

公式のConfiguration Referenceでは、sandbox_mode の値として read-only、workspace-write、danger-full-access の3つが示されています。説明は「コマンド実行中のファイルシステムとネットワークへのアクセス方針」です。

値	性格	向く場面（筆者の整理）
read-only	読み取り中心。変更を伴わない調査向け	初めて触るリポジトリの把握、設計の相談、レビューの下見
workspace-write	ワークスペース内で編集とコマンド実行ができる	日常の実装、テスト実行、リファクタリング
danger-full-access	サンドボックスによる制限なし	外側の隔離環境が別にある場合に限る

右の列の「向く場面」は公式の文言ではなく、公式の挙動の説明から筆者が整理したものです。公式ページの事実としては、workspace-write は既定でネットワークがオフのままで、有効にするには設定で明示する必要があります。設定名は [sandbox_workspace_write] テーブルの network_access です。ワークスペースには現在のディレクトリと /tmp のような一時ディレクトリが含まれ、どのディレクトリが含まれるかは /status で確かめられます。詳細は公式ページの「Defaults and recommendations」の節にあります。

仮の例として、手元のアプリケーションのリポジトリで機能追加を頼む場面を考えます。編集とテスト実行はワークスペース内で完結するので workspace-write で足ります。外部のパッケージ取得が必要になった時点で、ネットワークの許可が別の判断として浮かび上がります。この「ファイル操作の範囲」と「ネットワークの範囲」を分けて考えられることが、workspace-write を起点にする利点です。

承認ポリシーの値｜on-request・never・granular

現行の承認ポリシーは on-request、never、そして項目ごとに制御する granular の3系統で、untrusted は使えなくなっています。

Configuration Referenceの approval_policy の型は on-request | never | { granular = { ... } } と示されています。説明には、untrusted は非対応で、on-failure は非推奨であり、対話的な実行には on-request、非対話的な実行には never を使う、と書かれています。

また、公式のAgent approvals & securityページの移行案内では、CodexとChatGPT Workが approval_policy = "untrusted" をもうサポートせず、残していると起動できなくなる場合があると注意しています。ユーザー設定、プロジェクト設定、プロファイルファイル、起動スクリプト、管理側の既定値を見直して取り除くよう案内されています。古いブログ記事や共有された設定の断片に untrusted が残っていないか、まず確認してください。

値	公式の位置づけ	使いどころ
on-request	対話的な実行向け	人が画面の前にいて、必要なときだけ判断する場面
never	非対話的な実行向け	CIなど、承認を待つ人がいない場面。サンドボックスを狭く保つ前提
granular	承認プロンプトの種類ごとに表示か自動拒否かを選ぶ	一部の確認だけ人に残したい中間的な運用

3行目の granular は、5つのキーで確認の種類ごとに制御します。詳しくは後の節で扱います。ここで押さえておきたいのは、承認ポリシーは「自動化の度合い」を調整するつまみであって、安全性そのものを保証するつまみではないという点です。安全性の土台はサンドボックスの範囲で決まり、承認はその上に重なる確認の仕組みです。

公式の組み合わせ早見表と初期設定の考え方

公式は「意図」ごとにフラグの組み合わせを表にしており、日常の標準は --sandbox workspace-write --ask-for-approval on-request のAutoプリセットです。

公式ページの「Common sandbox and approval combinations」から、この記事で使う組み合わせを抜き出して整理します。

意図	フラグ	公式の説明の要点
Auto（プリセット）	フラグ不要、または --sandbox workspace-write --ask-for-approval on-request	ワークスペースで読み取り・編集・コマンド実行ができ、ワークスペース外の編集やネットワークには承認が必要
読み取り専用で安全に見る	--sandbox read-only --ask-for-approval on-request	読み取り専用サンドボックス内でファイル閲覧とコマンド実行ができ、外へ出る操作には承認が必要になりうる
読み取り専用の非対話実行（CI）	--sandbox read-only --ask-for-approval never	読み取りとサンドボックス内のコマンド実行ができ、承認は求めない
自動承認レビュー	--sandbox workspace-write --ask-for-approval on-request -c approvals_reviewer=auto_review	境界は通常のon-requestと同じで、対象の承認要求をレビュー担当が確認する
危険なフルアクセス	--dangerously-bypass-approvals-and-sandbox（別名 --yolo）	サンドボックスも承認もなし。公式は推奨していない

初期設定の挙動も押さえておきましょう。公式ページによると、起動時にCodexはフォルダがバージョン管理されているかを検出し、バージョン管理されたフォルダにはAuto（ワークスペース書き込みとon-request承認）、バージョン管理されていないフォルダには read-only を推奨します。信頼するまで read-only で始まる場合があること、既定のまま使うなら codex を実行するだけでよいことも書かれています。明示したい場合は、codex --sandbox workspace-write --ask-for-approval on-request と codex --sandbox read-only --ask-for-approval on-request の2通りの書き方が例示されています。

この早見表から読み取れる設計思想は、「承認ポリシーを動かす前に、まずサンドボックスの範囲で受け止める」ということです。Autoは範囲の中を自動にし、範囲の外を人に聞くという役割分担になっています。提供形態ごとの違いはOpenAI Codexの提供形態の違いで整理されています。この記事で扱う設定は、そのうちローカルのCLIとIDE拡張の話です。

場面別の選び方①｜初めてのリポジトリを読むだけの調査

変更を伴わない調査では、read-only と on-request を選ぶと、読むだけの作業が編集に変わる前に人の目を通せる構えになります。

ここからは筆者の整理による場面別の使い分けです。根拠となる公式の事実は、各節で公式ページのリンクとともに示します。公式は、バージョン管理されていないフォルダに read-only を推奨しており、変更せずに会話や計画だけをしたいときは /permissions コマンドで read-only に切り替えられると書いています。

仮の例として、引き継いだばかりのリポジトリで「このプロジェクトのディレクトリ構成と、テストの実行方法を説明して」と頼む場面を考えます。次のように起動します。

# 仮の例：読み取り専用で起動する
codex --sandbox read-only --ask-for-approval on-request

この構成では、Codexはファイルを読み、読み取り専用サンドボックスの中でコマンドを実行できます。ファイルを書き換えたり、サンドボックスの外へ出たりする必要が生じたときは、承認の要求が出る可能性があります。そこで人が判断します。「構成の説明だけが欲しいのに書き換えようとしている」と気づけること自体が、調査の場面での安全装置です。

調査から実装へ移るときは、セッションを切らずに /permissions でプリセットを切り替えられます。公式のCLIリファレンスでは、/permissions はCodexが確認なしでできることを設定するコマンドで、AutoとRead Onlyの切り替えが例として挙がっています。切り替え後は、変更するまで更新した承認モードが適用されます。AGENTS.mdの活用ガイドのように、調査で分かった前提をプロジェクトの指示ファイルにまとめてから実装へ進む流れとも相性がよいです。

場面別の選び方②｜日常の実装を任せる

日常の実装では、バージョン管理されたフォルダで workspace-write と on-request のAutoを使い、承認が出た操作だけを丁寧に読むのが基本です。

公式ページは、Autoプリセットで、Codexが作業ディレクトリ内のファイルを読み、編集し、コマンドを実行できると説明しています。ワークスペース外の編集やネットワークが必要なコマンドは、承認を求められます。バージョン管理されたフォルダにAutoを推奨するのは、変更をgitで確認し、必要なら戻せるためだと読めます。公式の「Version control」の節にも、機能ブランチで作業し、委任前に git status をきれいにしておくと、Codexのパッチを切り分けて戻しやすくなる、という趣旨のことが書かれています。公式ページで原文を確認できます。

確認する点	見るタイミング	理由
作業ブランチと git status	依頼の前	差分を切り分けて、後から戻しやすくするため
承認要求が来た操作の中身	承認を押す前	ワークスペース外の編集やネットワーク利用が含まれる可能性があるため
差分とテスト結果	作業の後	通常のプルリクエストと同じ目線で確認するため

仮の例として、既存の関数に引数を1つ追加してテストを直してもらう場面を考えます。ファイル編集とテスト実行はワークスペース内で完結するため、承認の画面は頻繁には出ません。一方、依存パッケージの取得などネットワークが必要な操作が出たときは承認の画面が出ます。ここで「何のために、どこへ接続するのか」を読んで判断します。承認の回数が少ないことは安全の証拠ではなく、「範囲内の操作が自動で通っている」という状態の表れです。範囲そのものが適切かは、サンドボックスの設定で別に見直します。

実装後のレビューには、Codexのコードレビュー機能を組み合わせる方法もあります。自分で書いたコードも、Codexが書いたコードも、レビューの流れに乗せる運用にすると、承認の判断とレビューの判断を分けられます。

場面別の選び方③｜CIや非対話の実行

人が見ていない実行では、承認を待てないため never を使いますが、その代わりサンドボックスを read-only か workspace-write に絞って範囲側で守ります。

公式ページの「Run without approval prompts」では、--ask-for-approval never（短縮形 -a never）で承認プロンプトを無効にできると説明されています。このオプションはすべての --sandbox モードと組み合わせられるため、自律の度合いを引き続き制御できます。Codexは設定した制約の範囲内でベストエフォートに動きます。

つまり never は「確認を省く」設定であって、「何でもできる」設定ではありません。承認が必要な操作は、止まって待つのではなく、その制約のもとでのベストエフォートになると読めます。公式の早見表では、非対話のCI向けに --sandbox read-only --ask-for-approval never が示されています。コードを読んで報告だけをさせる用途に向きます。

# 仮の例：読み取り専用で、承認を求めずに実行する構成
codex --sandbox read-only --ask-for-approval never

編集を伴う非対話実行については、公式ページが codex exec --sandbox workspace-write を使うよう案内しています。古い codex exec --full-auto は非推奨の互換経路として残っており、警告が表示されるとも書かれています。既存のスクリプトに --full-auto が残っている場合は、置き換えを検討する材料になります。CLIリファレンスの安全のヒントも同じ方向で、無人のローカル作業にはワークスペース内に収まる --sandbox workspace-write を使い、専用のサンドボックスVMの中でない限り --dangerously-bypass-approvals-and-sandbox は避けるよう書かれています。CLIリファレンスの該当節で確認できます。

ネットワークとWeb検索の扱い

ネットワークは workspace-write でも既定でオフで、オンにしたあとに network_proxy で行き先を絞り込む、という二段構えで考えます。

公式ページの「Network access」の節によると、デスクトップアプリ、Codex CLI、IDE拡張の既定の workspace-write は、設定で有効にしない限りネットワークアクセスがオフです。有効にする設定は次のとおりです。

# 仮の例：workspace-writeでコマンドのネットワークを許可する（公式ページの設定例に沿った書き方）
[sandbox_workspace_write]
network_access = true

さらに、ネットワークを有効にしたあとで行き先を絞りたい場合は、network_proxy 機能を併用します。公式は、この機能は有効なネットワークの強制のしかたを変えるだけで、ネットワークアクセスそのものは付与しないと明記しています。組み合わせは次の表のとおりです。

ネットワーク設定	network_proxy	結果（公式の説明）
オフ	オン	ネットワークはオフのままで、機能は何もしない
オン	オフ	制限のない直接の外向き通信が可能なまま
オン	オン	ネットワークは有効で、外向き通信は設定したポリシーで制約される

ドメインのルールは許可リスト優先で、deny は常に allow に勝つと公式は説明しています。ワイルドカードの * による全許可は広いネットワークアクセスにあたるため、可能なら範囲を絞ったルールを使うよう勧められています。ルールを書いただけではプロキシは有効にならない点にも注意が必要です。

Web検索は別の制御です。公式ページでは、検索はキャッシュ（OpenAIが管理するインデックス）の結果を返すモードが既定で、web_search = "cached" がデフォルトと示されています。"disabled" や "live" も選べますが、フルアクセス系の設定を使っている場合は、検索の既定がライブ結果になると書かれています。ネットワークやWeb検索を有効にするときは、プロンプトインジェクションによって、エージェントが信頼できない指示を取得して従う恐れがあるという公式の注意を念頭に置いてください。

書き込み範囲の広げ方と保護されるパス

書き込み先を増やしたいときは、danger-full-access に切り替えるのではなく、--add-dir や writable_roots で必要な場所だけを足します。

CLIリファレンスには、Codexにより多くのディレクトリへの書き込みを許可したい場合は、--sandbox danger-full-access を強制するより --add-dir を優先するよう書かれています。設定ファイル側では、Configuration Referenceに sandbox_workspace_write.writable_roots があり、workspace-write のときの追加の書き込み可能ルートを文字列の配列で指定します。exclude_tmpdir_env_var と exclude_slash_tmp で、一時ディレクトリを書き込み可能ルートから外す設定もあります。

# 仮の例：ビルド出力用の兄弟ディレクトリを書き込み先に足す
codex --sandbox workspace-write --add-dir ../build-output

書き込み可能なルートの中にも、保護されるパスがあります。公式ページの「Protected paths in writable roots」では、既定の workspace-write で、ルート直下の .git が（ディレクトリでもファイルでも）読み取り専用として保護されます。.git がポインタファイルの場合は、解決先のGitディレクトリも保護されます。.agents と .codex も、ディレクトリとして存在すれば読み取り専用で、保護は再帰的に配下全体へ及びます。

パス	既定の workspace-write での扱い
<writable_root>/.git	読み取り専用（ポインタファイルの場合は解決先も）
<writable_root>/.agents	ディレクトリとして存在すれば読み取り専用
<writable_root>/.codex	ディレクトリとして存在すれば読み取り専用

この保護があるため、既定のままではCodexがリポジトリの履歴ディレクトリや、設定・指示を置くディレクトリを書き換えにくくなっています。「Codexにコミットまで任せたい」といった要望がある場合も、まず範囲の拡張を検討する前に、差分の確認とコミットを人が行う運用で足りないかを考えてみてください。範囲を広げる判断は、保護の意味を理解してからにするのが安全です。

granularと自動承認レビューで確認の質を上げる

確認の回数を減らしたいときは、承認を切る前に、granular で確認の種類を選ぶか、approvals_reviewer を auto_review にしてレビュー担当を挟む方法があります。

Configuration Referenceでは、granular の中身は次の5つのキーで、それぞれ true のとき該当する承認プロンプトが表示されます。

キー	true のときの意味（公式の説明）
sandbox_approval	サンドボックス昇格の承認プロンプトを表示できる
rules	execpolicyの prompt ルールによる承認を表示できる
mcp_elicitations	MCPのelicitationプロンプトを自動拒否せず表示する
request_permissions	request_permissions ツールのプロンプトを表示できる
skill_approval	スキルスクリプトの承認プロンプトを表示できる

公式ページは、granular を、特定の承認プロンプトの種類は対話的なまま残し、ほかは自動で拒否する中間的な選択肢として紹介しています。たとえばMCP連携を使うなら、MCP連携ガイドで扱うサーバーが出す確認の扱いを、この単位で決められます。

もうひとつが自動承認レビューです。公式ページによると、既定では承認要求はユーザーへ回り（approvals_reviewer = "user"）、approvals_reviewer = "auto_review" にすると、対象の承認要求をCodexが実行する前にレビュー担当のエージェントが確認します。レビューが見るのは、サンドボックス昇格やブロックされたネットワーク要求のように、すでに承認が必要な操作だけで、サンドボックス内で完結する操作に追加のレビューは入りません。ポリシーは、データの持ち出し、認証情報の探索、恒久的なセキュリティの弱体化、破壊的な操作を確認します。レビューが失敗した場合は安全側に倒れ、実行されません。

注意点も公式に書かれています。自動レビューは追加のモデル呼び出しを使うため、Codexの使用量が増える場合があります。レビューは承認の代わりに判断する仕組みで、Configuration Referenceには、この設定はサンドボックスの扱いを変えないと書かれています。公式の挙動の詳細は公式ページで確認してください。あわせて、組織で運用する場合の許可値の制約（allowed_approval_policies や allowed_sandbox_modes など）は、OpenAI Codex企業導入ガイドのような導入側の観点とあわせて検討するとよいでしょう。

危険な設定と隔離環境の考え方

サンドボックスと承認の両方を外す設定は、公式が「推奨しない」と明記しており、使うなら外側に別の隔離境界があるときだけに限ります。

公式の早見表では、--dangerously-bypass-approvals-and-sandbox（別名 --yolo）はサンドボックスなし・承認なしで、「not recommended」と注記されています。この設定を使う前提として、公式ページは、Docker内ではホストやコンテナの設定がnamespace、setuid bwrap、seccomp の操作を妨げるとサンドボックスが動かない場合があると説明しています。その場合は、コンテナ側で必要な隔離を用意したうえで、コンテナ内で --sandbox danger-full-access を使う、という使い方が示されています。

Dev Containersについても、公式ページはリファレンス実装（Codexのsecure devcontainerの例）を紹介しています。ただし、コンテナは多くの保護を提供するものの、すべての攻撃を防ぐわけではないとも述べています。コンテナ内で danger-full-access や --dangerously-bypass-approvals-and-sandbox を使うと、悪意のあるプロジェクトが、コンテナ内で使えるものを何でも持ち出せる（Codexの認証情報を含む）と注意されています。信頼できるリポジトリだけに使い、ほかの高権限環境と同じように監視する前提です。

状況	公式が示す選択肢	この記事の整理
ホストでサンドボックスが動く	Codexのサンドボックスを使う	まずはこちら。workspace-write を起点にする
コンテナ側が隔離境界で、内側でサンドボックスを作れない	コンテナ内で --sandbox danger-full-access	信頼できるリポジトリに限り、外側の隔離と監視を前提にする
コンテナがサンドボックスの作成を許可している	Codexの bwrap を有効のままにする	二重の守りになるため、可能ならこちらを優先する

最後の列は筆者の整理です。承認を切ること、サンドボックスを外すことの2つは別々の判断で、片方だけでも外せば自動化の度合いは大きく上がります。「まず承認だけを切り、サンドボックスは残す」という順番を踏むほうが、失敗したときの影響が小さく済みます。

もうひとつ見落としやすいのが、Codexの安全性の監視との関係です。公式ページによれば、GPT-6 Astraを使うときの安全性の監視は非同期で動き、潜在的に危険なモデルの挙動を検知するとタスクを一時停止することがあります。一時停止が、きっかけとなった行動より後に届くことがある、サンドボックスや権限や結果のレビューの代わりにはならない、とも明記されています。Codex CLIでは、完全な検出結果の表示と再開はできず、タスクは終了すると書かれています。設定側の守りと、この監視は別物として扱ってください。

設定を固定して動作を確かめる方法

毎回フラグを書くのではなく、config.tomlやプロファイルに用途別の組み合わせを保存し、codex sandbox や /status で実際の挙動を確かめてから使います。

公式のConfig basicsには、承認プロンプトの設定が approval_policy = "on-request"、サンドボックスの設定が sandbox_mode = "workspace-write" の形で例示されています。公式のAgent approvals & securityページには、対話的な承認と読み取り専用サンドボックスの設定例と、任意のハードニングとしての allow_login_shell = false も載っています。

# 仮の例：~/.codex/config.toml（公式ページの例に沿った書き方）
approval_policy = "on-request"
sandbox_mode    = "read-only"
allow_login_shell = false # 任意：ログインシェルを禁止する

用途別に切り替えたい場合は、設定をプロファイルファイルとして保存し、codex --profile プロファイル名 で選べます。公式ページには、~/.codex/full_auto.config.toml に on-request と workspace-write を、~/.codex/readonly_quiet.config.toml に never と read-only を書く例が載っています。名前を付けて保存しておくと、「調査用」「実装用」「CI用」を取り違えにくくなります。プロファイルの扱いはconfig.tomlの完全ガイドも参考になります。

確認手段	見えること	使うタイミング
/status	有効なモデル、承認ポリシー、書き込み可能ルートなど	セッションを始めた直後、設定を変えた直後
/permissions	承認プリセットの切り替え	調査から実装に移るとき、またはその逆
codex sandbox	サンドボックス下でコマンドを試した結果	設定を保存する前の動作確認

サンドボックスの動作確認には、CLIの codex sandbox サブコマンドが使えます。公式ページは、macOS、Linux、Windowsの各ヘルパーを案内しています。macOSでは codex sandbox macos、--log-denials オプションなどが示されています。/status の説明はCLIリファレンスにあり、有効なモデル、承認ポリシー、書き込み可能ルート、残りのコンテキスト容量を確認できます。

# 仮の例：macOSで、サンドボックス下のコマンド結果を確かめる
codex sandbox macos --log-denials ls

設定は「書いて終わり」にせず、(1) 保存、(2) 試す、(3) 見直す、の順で回します。これで、いつの間にか緩い設定が標準になっていた、という事態を防げます。

よくある質問（FAQ）

Q1. 迷ったらどの組み合わせから始めればよいですか。

公式のAutoプリセットにあたる workspace-write と on-request が標準です。バージョン管理されていないフォルダでは read-only が推奨されているため、まずそちらで様子を見る選び方もあります。根拠は公式ページの「Defaults and recommendations」の節です。

Q2. 承認プロンプトが多くて困るとき、never にしてよいですか。

対話的に使うなら、先に granular や auto_review で確認の種類や担当を調整する方法を検討してください。never は公式が非対話の実行向けとしている値で、使う場合はサンドボックスを狭く保つのが前提です。値の位置づけはConfiguration Referenceにあります。

Q3. 起動できなくなったとき、承認ポリシーの設定を疑うべきですか。

設定に approval_policy = "untrusted" が残っていないか確認してください。公式ページは、この設定がもうサポートされず、残っているとCodexが起動できなくなる場合があると説明しています。読み取り専用の対話的な運用に置き換える例として、sandbox_mode = "read-only" と approval_policy = "on-request" が示されています。

Q4. ネットワークを許可すると、Web検索も自由になりますか。

別の制御です。コマンドのネットワークは sandbox_workspace_write.network_access で、Web検索は web_search で決まります。公式ページでは、ネットワークプロキシはWeb検索やMCPサーバー接続などを絞り込まないと説明されています。両方を別々に確認してください。

Q5. 書き込めないフォルダに出力させたいときは何を使いますか。

danger-full-access へ切り替える前に、--add-dir や writable_roots で必要な場所だけを足す方法を検討します。CLIリファレンスもこちらを優先するよう書いています。ただし、.git、.agents、.codex は書き込み可能ルートの中でも既定で読み取り専用です。

Q6. 自動承認レビューを使えば、人の確認は不要になりますか。

公式の説明では、レビュー担当はすでに承認が必要な操作を確認するものです。サンドボックスの範囲を変えるものではなく、追加のモデル呼び出しにより使用量が増える場合もあります。承認の判断を自動化しても、結果のレビューは別に必要です。

まとめ｜範囲で守り、確認で絞り、外すなら隔離の中で

Codex CLIの安全な自動実行は、サンドボックスで範囲を決め、承認ポリシーで確認の入り方を決める、二層の設計です。日常は workspace-write と on-request、調査は read-only、無人実行は never と狭いサンドボックス、サンドボックスごと外すのは隔離環境の中だけ、と整理できます。

場面	サンドボックス	承認ポリシー
初めてのリポジトリの調査	read-only	on-request
日常の実装	workspace-write	on-request
CIでの読み取り専用の実行	read-only	never
隔離された外側の環境がある場合	danger-full-access（外側の隔離が前提）	運用に合わせて設定

設定の根拠は、すべて公式ページの記述にあります。Agent approvals & security、Configuration Reference、CLIリファレンスの3つを手元に置き、設定を変える前に原文を見直す習慣をつけると、仕様の更新にも追随しやすくなります。Codex全体の始め方はOpenAI Codexの使い方、クラウド側の運用はCodex Cloudの使い方も参考にしてください。