Codex 設定ガイド

Codexで自動承認（automode）を設定する方法｜approval_policyとsandboxの安全な組み合わせ

Codexに毎回「実行していい？」と聞かれるのを止めたい——そんなときに使うのが承認ポリシー（approval_policy）とサンドボックス（sandbox_mode）の設定です。この記事では、2つの設定の関係、目的別の安全なレシピ、config.tomlへの恒久設定、そして「やってはいけない全解除」までを、2026年7月時点の公式リファレンスに基づいて解説します。

Codexの「自動承認」は2つの設定の組み合わせ

Claude Codeの「Auto Mode」のようなひとつのスイッチを探すと迷子になります。Codexの自動化は、役割の違う2つの設定を組み合わせて作ります。

設定	役割	例えるなら
`approval_policy`	Codexが作業前に人間に確認を取るかを決める	「上司への確認の頻度」
`sandbox_mode`	確認なしで動くとき、どこまでの操作を物理的に許すかを決める	「渡す鍵の範囲」

つまり「確認を減らす（approval）」と「動ける範囲を絞る（sandbox）」はセットで考えるものです。確認を切るならその分サンドボックスを狭くする——これがCodex自動化の基本原則です。

approval_policy：3つの値と非推奨になった値

値	動作	向いている場面
`untrusted`	安全と分かっている読み取り系のみ自動実行。状態を変更するコマンドは毎回承認を求める	初めてのリポジトリ・信頼できないコード
`on-request`	サンドボックスの範囲内は自動実行し、範囲を超える操作（ワークスペース外の編集・ネットワークアクセス等）のときだけ承認を求める。Git管理下フォルダでのデフォルト	日常の開発作業
`never`	承認プロンプトを完全に無効化。ただしサンドボックス制限は生きたまま	定型作業の自動化・CI・バッチ実行

⚠ 「on-failure」は非推奨になりました

古い解説記事でよく見るapproval_policy = "on-failure"は、現在の公式リファレンスで非推奨（deprecated）とされています。対話利用ならon-request、非対話の自動実行ならneverに置き換えてください。同様に、昔の記事にある--full-autoフラグも現行の設定リファレンスには記載がないため、本記事では現行の公式な指定方法（--ask-for-approval＋--sandbox）を使います。

検索で「codex automode」と呼ばれているものの実体は、多くの場合approval_policy = "never"＋適切なサンドボックスの組み合わせです。

sandbox_mode：動ける範囲を決める3つの値

値	できること	リスク
`read-only`	ファイルの読み取りのみ。書き込み・実行系は承認が必要	最小
`workspace-write`	作業ディレクトリ（ワークスペース）内の読み書き。外への書き込みやネットワークは原則ブロック	小〜中
`danger-full-access`	サンドボックス制限なし。システム全体に書き込み可能	大

ネットワークアクセスは独立した設定になっており、workspace-writeのまま必要なときだけ開けられます。

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

[sandbox_workspace_write]
network_access = true   # npm install などが必要な場合のみ true

目的別レシピ：この組み合わせを使えばいい

レシピ①：日常開発の「ちょうどいい自動化」（推奨）

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

ワークスペース内の編集・実行は確認なしで進み、範囲を超える操作のときだけ聞いてきます。Git管理下ではこれがデフォルト相当なので、まずはこの挙動を基準にしましょう。

レシピ②：確認ゼロの自動承認（automode相当）

codex --ask-for-approval never --sandbox workspace-write

承認プロンプトが出なくなりますが、サンドボックスが生きているため被害範囲はワークスペース内に限定されます。「自動承認にしたいが安全は保ちたい」への公式な答えがこの組み合わせです。

レシピ③：調査専用の読み取りモード

codex --ask-for-approval never --sandbox read-only

コードベースの調査・レビュー・説明をさせるだけなら、書き込み権限自体を渡さないのが最も安全です。確認なしでもファイルは一切変更されません。

レシピ④：CI・バッチでの非対話実行

codex exec --ask-for-approval never --sandbox workspace-write "テストを実行して失敗を修正して"

CIパイプラインなど人間が承認ボタンを押せない環境ではneverが前提になります。実行後は必ず差分をレビューしてからマージしてください。

✕ やってはいけない：全解除フラグ

--dangerously-bypass-approvals-and-sandbox（別名--yolo）は、承認もサンドボックスも同時に無効化します。公式ドキュメント自身が「サンドボックスなし・承認なし（非推奨）」と明記している設定で、AIの誤操作がシステム全体に及びます。使い捨てのコンテナ・VM内など、壊れても困らない隔離環境以外では使わないでください。「automode」を調べている人が本当に欲しいのは、ほぼ確実にレシピ②です。

config.tomlで恒久設定にする

毎回フラグを付けるのが面倒になったら、~/.codex/config.tomlに書いておきます。

# ~/.codex/config.toml
approval_policy = "on-request"     # 日常のデフォルト
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = false

「普段は確認あり、自動化タスクのときだけ確認なし」を切り替えたい場合は、プロファイル（別ファイルの設定）を用意して--profileで切り替えるのが便利です。プロファイルは環境名（dev・ci など）で命名するのが定石です。

# ~/.codex/auto.config.toml（自動化用プロファイル）
approval_policy = "never"
sandbox_mode = "workspace-write"

# 実行時
codex --profile auto "リンタ警告を全部直して"

セッションの途中で切り替えたい場合は、対話画面（TUI）で/approvalsコマンドを使うと、その場で承認モードを変更できます。「最初は確認ありで様子を見て、信頼できたら残りは自動で」という運用ができます。

安全に運用するための3原則

Git管理下でだけ自動承認を使う：何が変更されたかをgit diffで必ず確認でき、いつでも巻き戻せる状態が前提です。Git管理外のフォルダでneverを使うのはやめましょう
ネットワークはデフォルト閉じる：network_access = falseを基本にし、パッケージインストールが必要なタスクのときだけ開ける。自動実行中の意図しない外部通信を防げます
自動実行の結果は人間がレビューする：承認を省略するのは「作業中の確認」であって「成果物の検収」ではありません。差分レビュー→コミットの流れは維持してください

ℹ Claude Codeユーザーの方へ

Claude Codeの自動承認（Auto Mode・permission mode）に相当する仕組みの比較で言うと、Codexのon-requestがClaude Codeの通常モード＋acceptEdits的な立ち位置、never＋workspace-writeがAuto Mode相当、--yoloがbypassPermissions相当です。Claude Code側の設定はAuto Modeの設定ガイドをご覧ください。

よくある質問

Q. 設定しても承認を求められることがあるのはなぜですか？

on-requestはサンドボックスの範囲を超える操作（ワークスペース外への書き込み、ネットワークアクセスなど）のときに承認を求める設計です。確認を完全になくしたい場合はapproval_policy = "never"にしますが、その場合サンドボックス外の操作は承認ではなく「ブロック」になります。

Q. 「–full-auto」や「on-failure」を紹介している記事を見ましたが使えますか？

on-failureは現在の公式リファレンスで非推奨とされており、on-request（対話）またはnever（非対話）への置き換えが案内されています。--full-autoも現行の設定リファレンスには記載がないため、本記事のレシピ（--ask-for-approval＋--sandboxの明示指定）を使うのが確実です。

Q. –yoloを使えばいちばん速いのでは？

速さは変わりません。never＋workspace-writeでも承認プロンプトは一切出ないので、体感速度は同じです。違うのは事故ったときの被害範囲だけです（ワークスペース内 vs システム全体）。隔離されたコンテナ内でない限り、--yoloを選ぶ理由はほぼありません。

Q. IDE拡張やCodex Cloudでも同じ設定ですか？

この記事はCodex CLI（ターミナル）の設定を扱っています。IDE拡張にも承認の概念はありますが、UIからモードを選択する形になります。クラウド実行（Codex Cloud）はそもそも隔離環境で動くため、承認まわりの考え方が異なります。