Codex CLI 自動承認モード: 承認待ちを減らす3つの安全設定

Codex CLI 完全ガイド

対象 / ポイント

対象:

• Codex CLIで dangerously skip permissions 相当のコマンドを探している人
• Codex CLIを日常的に使っていて、承認ダイアログを減らしたい人
• approval_policy と sandbox_mode の組み合わせが分かりづらい人
• Claude Codeの権限モデルとの違いを短時間で把握したい人

ポイント:

• Claude Codeの --dangerously-skip-permissions に最も近いのは、Codex CLIの --dangerously-bypass-approvals-and-sandbox / --yolo
• 非対話の自動化では、codex -a never -s workspace-write execが承認なし・サンドボックス維持の明示形
• 設定profileとpermission profileは別機能。完全bypassは外部で隔離した環境だけに限定する

クイック回答

やりたいこと	まず使う設定	理由
Claude Codeの --dangerously-skip-permissions 相当を知りたい	codex --dangerously-bypass-approvals-and-sandbox または codex --yolo	承認とサンドボックスをまとめてbypassするため、外部で隔離された環境に限定
非対話の自動化を承認なしで回したい	codex -a never -s workspace-write exec	承認を出さず、サンドボックス外の操作は失敗としてモデルへ返す
日常開発で境界外だけ確認したい	codex -a on-request -s workspace-write	ワークスペース内は自動で進み、境界外だけ承認を求める
承認を減らしつつネットワークも使いたい	codex -a never -s workspace-write -c 'sandbox_workspace_write.network_access=true'	フルアクセスに寄せず、必要な通信だけ追加できる

問題の核心

Codex CLIの自動承認は、1つのスイッチで全部切り替わるわけではない。現在の公式ドキュメントでは、大きく2つの設定モデルがある。

• Permission profiles（beta）: :read-only、:workspace、:danger-full-access など、ファイルとネットワーク境界をまとめるポリシー
• Sandbox / approval設定: approval_policy / sandbox_mode / network_access を組み合わせる安定したCLI・設定モデル

同じ設定でpermission profileと旧来の sandbox_mode を混ぜない。使うモデルを決め、リスク境界を明示しておく。²

2026年版の更新点: dangerous bypass、permission profiles、exec --full-auto

検索語「Codex dangerously skip permissions」への現在の直接回答は、次のコマンドになる。

codex --dangerously-bypass-approvals-and-sandbox "Task"

# 短いalias
codex --yolo "Task"

これはClaude Codeの --dangerously-skip-permissions に最も近い。ただし、Codex側では承認とサンドボックスをまとめてbypassする最も強い経路でもある。OpenAI公式CLIリファレンスとsecurity guidanceでは、外部でhardening済み、または隔離済みの環境に限定する扱いだ。⁴

非対話で承認待ちを発生させないなら、方針を明示する。

codex -a never -s workspace-write exec "Run tests and fix failures"

codex exec --full-auto は残っているが、現在はdeprecated compatibility flagとして扱われる。新しく組むなら --sandbox workspace-write を明示する。⁴

permission profileを使う場合、CLIを起動してから/permissionsで選択する。--permission-profileというCLIフラグはない。

codex
/permissions

既定値にする場合は、config.tomlへdefault_permissions = ":workspace"を置く。permission profileはbetaであり、sandbox_modeや[sandbox_workspace_write]を同じ設定レイヤーに置くと旧sandbox設定が優先される。²

:danger-full-access やdangerous bypassは、ホスト、コンテナ、CI runnerが使い捨てで、外側にガードレールがある場合に限定する。

旧来のsandboxモデル

既存例の多くは、次の3軸で整理されている。

• approval_policy: 承認をどこまで省くか
• sandbox_mode: ファイルやコマンドの実行範囲をどこまで広げるか
• network_access: ネットワークを使えるか

つまずきやすいのは、approval_policy だけを見てしまうことだ。実際には sandbox_mode の影響が大きく、workspace-write ではネットワークは既定で許可されない。¹

on-request と never の違い

on-request + workspace-writeはワークスペース内を自動実行し、境界外で承認を出す。never + workspace-writeは承認を一切出さず、境界外の操作を失敗としてモデルへ返す。承認待ちをなくす目的なら、後者を明示する。¹

クイックスタート

まずはこの3つだけ覚えれば十分だ。

# 1) 非対話・承認なし・ワークスペース内だけ
codex -a never -s workspace-write exec "Run unit tests and fix failures"

# 2) サンドボックスを維持したままネットワークを許可
codex -a never -s workspace-write \
  -c 'sandbox_workspace_write.network_access=true' \
  "Update deps and run migrate"

# 3) 強い自動化が必要な隔離環境向け
codex --dangerously-bypass-approvals-and-sandbox \
  "Non-interactive build and deploy"

最初に選ぶ設定

いきなり danger-full-access に寄せず、対話作業は -a on-request -s workspace-write、無人実行は -a never -s workspace-write から始める。

3つの設定方法

方法1: CLIフラグで都度切り替える

一時的な作業なら、これが最も分かりやすい方法だ。

# 対話型: 境界外だけ承認
codex -a on-request -s workspace-write "Fix failing tests"

# 無人型: 承認を出さず、境界内だけ実行
codex -a never -s workspace-write exec "Fix failing tests"

# ネットワークありの安全モード
codex -a never -s workspace-write \
  -c 'sandbox_workspace_write.network_access=true' \
  "Install packages and run migration"

# フルアクセス
codex -a never -s danger-full-access "Refactor and run full local build"

向いている場面:

• 単発作業
• 検証用セッション
• その場で強さを切り替えたいとき

方法2: config.toml / 設定profileで固定する

同じ設定を何度も使うなら、プロファイル化した方が速い。

~/.codex/config.tomlには通常の既定値を置く。

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

Codex 0.134.0以降、--profile networkedは~/.codex/networked.config.tomlを重ねる。旧形式の[profiles.networked]は読まれない。⁶

# ~/.codex/networked.config.toml
approval_policy = "never"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true

起動例:

codex --profile networked "Update dependencies"

向いている場面:

• 毎回同じ設定を使うチーム
• ローカル環境を標準化したいとき
• 安全な既定値を固定したいとき

方法3: -c で一部だけ上書きする

既定は保ちつつ、今回だけ変えたいときの方法だ。

# 今回だけ承認設定を強める
codex -c 'approval_policy="never"' "Task"

# 今回だけサンドボックスを変える
codex -c 'sandbox_mode="read-only"' "Analyze project structure"

# ネットワークだけ追加
codex -c 'sandbox_workspace_write.network_access=true' \
  "Fetch release notes"

向いている場面:

• 既存プロファイルを少しだけ変えたいとき
• CIやスクリプトで細かく制御したいとき

設定が反映される順序

1. CLIフラグと-c
2. 信頼済みプロジェクトの.codex/config.toml（現在のディレクトリに近いものが優先）
3. --profileで選んだ$CODEX_HOME/<name>.config.toml
4. ユーザーの$CODEX_HOME/config.toml
5. システム設定
6. 組み込み既定値⁷

モード設定マトリックス

体感で理解したい場合は、先にこのシミュレータを触るのが早い。

用途	approval_policy (-a)	sandbox_mode (-s)	ネットワーク	特殊フラグ	リスク
日常開発の基本形	on-request	workspace-write	off	なし	中
無人実行・境界維持	never	workspace-write	off	なし	中
ネットワークありの安全運用	never	workspace-write	on	-c 'sandbox_workspace_write.network_access=true'	中〜高
フルアクセス運用	never	danger-full-access	on	なし	高
完全無制限	-	-	-	--dangerously-bypass-approvals-and-sandbox	極高
読み取り専用	never	read-only	off	なし	低

Claude Codeとの対応

Codex CLIは approval_policy と sandbox_mode を分けて制御できる。Claude Codeの方が見た目は単純だが、Codex CLIの方が調整幅は広い。

Claude Code	Codex CLI	説明
claude --dangerously-skip-permissions	codex --dangerously-bypass-approvals-and-sandbox	完全無制限実行
claude の通常運用	codex -a on-request -s workspace-write	ワークスペース内を自動実行し、境界外だけ確認する基本線
相談中心の慎重運用	CLI内で/permissions → Read-only	変更を許さず、調査と相談へ寄せる安全側モード
allowedTools / 権限ルール	/permissions、approval policy、sandbox、Rules	自動許可する境界を調整
Hooks	Rules / hooks / skills	ワークフロー制御

Plan mode という言い方について

Codexには現在、/plan という built-in command があり、これは read-only とは別物だ。read-only は安全側の実行ポリシー、/plan は計画を先に固めるための操作と考えるのが正確だ。³⁵

セキュリティとベストプラクティス

まず守るべき4原則

1. 既定は workspace-write: 日常開発で danger-full-access を常用しない
2. ネットワークは必要時だけ許可: workspace-writeでは既定で無効と考える
3. 強い設定には外部ガードレールを併用: PRレビュー、CI、隔離環境を前提にする
4. ログを残す: 自動承認ほど実行証跡が重要

よく使う安全寄りの設定

# 日常開発: 境界外だけ承認
codex -a on-request -s workspace-write "Task"

# 無人実行: 承認なし、境界外は失敗
codex -a never -s workspace-write exec "Task"

# gh / curl / package install が必要
codex -a never -s workspace-write \
  -c 'sandbox_workspace_write.network_access=true' \
  "Task"

避けたい設定

# 本番ホストでの無制限運用
codex --dangerously-bypass-approvals-and-sandbox "Deploy to production"

# 機密情報の直書き
codex -a never "Use API key sk-xxxxxx"

# フルアクセスと広い削除を同時に使う
codex -s danger-full-access "Delete old files recursively"

ガバナンスの最低ライン

よくあるトラブルと対処法

このページでは「承認モードの設定」に絞る。長時間運用時の再接続や文脈肥大は、専用記事に切り出して読む方が早い。

症状	まず確認すること	次のアクション
workspace-write で gh や curl が失敗する	ネットワークが既定で無効か	workspace-write のまま network_access=true を追加
設定が反映されない	どのレイヤーが勝っているか	CLI、project、profile、user、systemの順で確認
強すぎる設定になって不安	danger-full-access を使っていないか	workspace-write へ戻して再実行
長時間実行で re-connecting... が出る	この記事の主題外	再接続ガイド を参照
context window で止まる	この記事の主題外	文脈エラー対策 を参照

FAQ

Codex CLIで承認をできるだけ減らす基本設定は？

対話型ならcodex -a on-request -s workspace-write、承認待ちをなくす非対話実行ならcodex -a never -s workspace-write execを使う。

サンドボックスを維持したままネットワークだけ許可できる？

可能だ。codex -a never -s workspace-write -c 'sandbox_workspace_write.network_access=true' を使えば、ファイル保護を保ちながら必要な通信だけ有効にできる。

Claude Codeの --dangerously-skip-permissions に相当するものは？

Codex CLIでは codex --dangerously-bypass-approvals-and-sandbox が最も近い設定だ。ただし非常に強いモードなので、隔離環境かCI専用に寄せるのが前提だ。

workspace-write でネットワークが使えないのはなぜ？

workspace-writeではネットワークが既定で無効だからだ。必要ならsandbox_workspace_write.network_access=trueを追加する。

設定は CLI と config.toml のどちらが優先される？

CLI引数が最優先だ。その後にproject config、選択したprofile file、user config、system config、組み込み既定値が続く。

まとめ

• 非対話・承認なし・境界維持の明示形はcodex -a never -s workspace-write exec
• --dangerously-bypass-approvals-and-sandbox / --yolo が検索されているCodex側の直接回答だが、隔離環境専用
• ネットワークが必要なら workspace-write を保ったまま追加許可
• 強い自動化は danger-full-access や bypass を常用せず、隔離環境に限定
• permission profileはbetaで、設定profileとは別物。旧sandbox設定と混ぜず、利用中のCodexバージョンで確認する

関連記事

• Codex CLI 完全ガイド
• Codex CLI ベストプラクティス
• Codex CLI のネットワーク制限を解く方法
• Codex CLI の Re-connecting ループ対策
• Codex CLI の context window エラー対策
• Claude Code 自動実行許可完全ガイド

---

1. Codex agent approvals & security — approval policy、sandbox、ネットワークの現行整理。 ↩↩

2. Codex permission profiles — betaのpermission profileと旧sandbox設定を混在させない注意。 ↩↩

3. Codex CLI slash commands — /planと/permissionsの現行導線。 ↩

4. Codex CLI command reference — dangerous bypass、--yolo、approval、sandboxの現行CLIリファレンス。 ↩↩

5. Codex permissions — Read-onlyを含む権限モードの説明。 ↩

6. Codex advanced configuration — 0.134.0以降のprofile file形式。 ↩

7. Codex config basics — 設定レイヤーと優先順位。 ↩