Codex Auto-reviewは、権限を無制限にする機能ではありません。人間に届く承認依頼を、専用のレビューワーAIが審査する仕組みです。
Codex Auto-reviewを使えば、Auto Modeより安全に承認を自動化できるのでしょうか。結論から言うと、両者は役割が違います。Auto ModeはCodexが通常作業できる範囲を決めるプリセット、Auto-reviewはサンドボックスの境界を越える操作の「承認者」を人間からレビューワーAIへ切り替える機能です。
先に結論：workspace-writeとon-requestを維持したまま、approvals_reviewer = "auto_review"を追加するのが基本です。Auto-reviewを有効にしても、書き込み可能な場所やネットワーク権限は広がりません。
Codex Auto-reviewとは
Codex Auto-review（Automatic approval reviews）は、サンドボックスの境界を越えようとする操作を、別のレビューワーエージェントが自動審査する仕組みです。通常はユーザーに表示される承認依頼が、先にAuto-reviewへ送られます。
承認された場合は操作が続行されます。拒否された場合、メインのCodexには拒否理由が返され、同じ結果を迂回して実現しようとせず、より安全な代替策を探すかユーザーへ確認するよう指示されます。
Auto-reviewを有効にしても、writable_rootsは増えず、ネットワークアクセスも自動では有効になりません。保護されたパスもそのままです。変わるのは、承認依頼を最初に誰が審査するかだけです。
Auto ModeとAuto-reviewの違い
「Auto」という言葉が共通するため混同しやすいのですが、公式ドキュメント上では別の設定です。
| 項目 | Autoプリセット | Auto-review |
|---|---|---|
| 主な役割 | 通常作業の権限範囲と承認タイミングを決める | 必要になった承認を誰が審査するか決める |
| 基本設定 | workspace-write＋on-request |
approvals_reviewer = "auto_review" |
| ワークスペース内の編集 | 通常は承認なしで実行 | そもそも審査対象にならない |
| 境界外の操作 | 承認依頼を発生させる | 承認依頼をレビューワーAIが審査 |
| サンドボックスを拡大するか | 設定内容による | 拡大しない |
approval_policy = "never"との併用 |
承認依頼自体が発生しない | 審査対象がないため動作しない |
公式のAutoプリセットは、フラグを指定しない通常起動、または次の組み合わせに相当します。
codex --sandbox workspace-write --ask-for-approval on-request一方、approval_policy = "never"は承認依頼を表示しない非対話向け設定です。境界外の操作を自動で許可する設定ではなく、サンドボックス外の操作は原則として実行できません。承認ゼロの設定やサンドボックスの基本は、Codexの自動承認とsandbox設定ガイドも参考にしてください。
Auto-reviewを有効化する方法
config.tomlへ恒久設定する
~/.codex/config.tomlへ次の3行を設定します。
# ~/.codex/config.toml
approval_policy = "on-request"
sandbox_mode = "workspace-write"
approvals_reviewer = "auto_review"この組み合わせなら、ワークスペース内の通常作業はそのまま進み、外部ネットワークやワークスペース外への書き込みなど、承認が必要な操作だけがAuto-reviewへ送られます。
今回だけCLIオプションで使う
恒久設定を変えず、一度だけ試す場合は次のように起動します。
codex \
--sandbox workspace-write \
--ask-for-approval on-request \
-c approvals_reviewer=auto_reviewChatGPTデスクトップアプリでは、審査中の項目に「Reviewing」「Approved」「Denied」「Aborted」「Timed out」などの状態が表示されます。リスクレベルや、ユーザーから十分な許可が与えられているかの評価が表示される場合もあります。
approval_policy = "never"ではAuto-reviewは動きません
neverは承認依頼を発生させない設定です。審査すべき依頼がないため、approvals_reviewer = "auto_review"を追加してもAuto-reviewは起動しません。on-requestまたは、対象カテゴリを承認対象として残したgranularポリシーと組み合わせます。
自動審査される操作・されない操作
Auto-reviewが審査するのは、通常なら人間の承認待ちになる操作です。
主な審査対象
- サンドボックス外での実行を要求するシェル・コマンド操作
- 現在の設定でブロックされた外部ネットワークアクセス
- 許可された書き込みルート外へのファイル編集
- 承認が必要と設定されたアプリやMCPツールの操作
- Computer Useで新しいWebサイトやドメインへアクセスする操作
Auto-reviewが動かない場面
- 現在のサンドボックス内ですでに許可されている読み取り・編集・コマンド
- ポリシー上、承認不要になっているツール操作
approval_policy = "never"で承認依頼自体が無効な場合- Computer Useのアプリ側で、ユーザーへ直接表示される承認操作
つまり、すべてのツール操作を二重チェックする機能ではありません。境界を越えるときだけ働くため、日常の編集速度を大きく落とさずに使えます。
Auto-reviewが拒否する操作と失敗時の動作
公式ドキュメントでは、レビューワーポリシーが特に警戒する例として、次の操作が挙げられています。
- 秘密情報、認証情報、個人データを信頼できない宛先へ送る
- トークン、Cookie、セッション情報などを探索する
- 広範囲または恒久的にセキュリティを弱める
- 取り返しのつかない被害につながる破壊的操作
低～中リスクの操作はポリシーが許せば承認されます。重大リスクは拒否され、高リスク操作はユーザーの明確な依頼があり、拒否ルールにも該当しない場合に限って承認候補になります。
審査セッションの作成失敗、結果の解析失敗などは安全側に倒れて拒否されます。タイムアウトも操作は実行されず、明示的な拒否とは別の状態として通知されます。
拒否された操作を自分で承認する
現在のCodex TUIでは、/approveから最近拒否された操作を選び、1回だけ再試行するための明示的な許可を与えられます。ただし、これは同じ種類の操作を今後すべて許可する設定ではありません。レビューワーはユーザーの許可を確認したうえで再審査し、ユーザーが上書きできない拒否条件なら再度拒否する場合があります。
同じ操作が何度も拒否されると、Codexがポリシー回避を繰り返さないようサーキットブレーカーが働きます。現在のオープンソース実装では、同一ターンで3回連続、または直近50回の審査中10回の拒否でターンが中断されます。
安全性を重視したおすすめ設定
個人開発や日常のリポジトリ作業では、次の構成を基準にするのがおすすめです。
# 安全性と自動化のバランスを取る基本設定
approval_policy = "on-request"
sandbox_mode = "workspace-write"
approvals_reviewer = "auto_review"
allow_login_shell = false
[sandbox_workspace_write]
network_access = falseネットワークが必要な作業だけ、対象を限定して承認または設定変更します。隣接リポジトリや一時フォルダへ頻繁に書き込む場合は、Auto-reviewへ毎回許可させるのではなく、必要な場所だけwritable_rootsへ追加するほうが明確です。
安全運用のチェックポイント
- Git管理下のプロジェクトで使い、実行後に差分を確認する
- ネットワークアクセスは必要なときだけ許可する
danger-full-accessと--yoloを常用しない- 広すぎるコマンド許可ルールを登録しない
- 拒否理由を確認し、同じ要求を言い換えて回避させない
- 長時間タスクでも成果物の最終確認は人間が行う
長時間作業を最後まで継続させたい場合は、CodexのGoal機能ガイドもあわせて確認してください。Goalは作業を継続させる仕組みであり、Auto-reviewと同様にサンドボックスの境界を広げる機能ではありません。
自動審査には追加のモデル呼び出しが使われるため、Codexの利用量が増える場合があります。承認依頼が多すぎる場合は、レビューワーポリシーを緩める前に、書き込みルートやコマンドルールを狭い範囲で整備しましょう。
よくある質問
Q. Auto-reviewを有効にすれば承認画面は完全になくなりますか？
すべてではありません。対象となる承認依頼はAuto-reviewが審査しますが、Computer Useのアプリ側承認など、ユーザーへ直接表示される操作もあります。また、Auto-reviewが判断できない場合は安全側に倒れます。
Q. Auto-reviewと--yoloは何が違いますか？
Auto-reviewはサンドボックスと承認ポリシーを維持します。--yoloは承認とサンドボックスを無効化するため、事故時の影響範囲がまったく異なります。通常のPCで同じものとして扱ってはいけません。
Q. Auto Modeへ切り替えるだけでAuto-reviewも有効になりますか？
自動では有効になりません。AutoプリセットとAuto-reviewは別設定です。approvals_reviewer = "auto_review"を設定してください。
Q. Auto-reviewはセキュリティを完全に保証しますか？
保証しません。公式ドキュメントも、特殊な状況や攻撃的な入力では誤る可能性があると説明しています。Auto-reviewはサンドボックス、監視、組織固有のポリシーを補完する仕組みです。
Q. 自社向けの審査ルールへ変更できますか？
個人は[auto_review].policy、企業管理者はguardian_policy_configでポリシーを設定できます。管理者の設定がローカル設定より優先されます。変更する場合は公式の既定ポリシー全体を基準にし、部分的な指示だけで重要な拒否条件を消さないようにしてください。
まとめ
- Auto Modeは通常作業の権限範囲、Auto-reviewは承認者を決める
- 基本設定は
workspace-write＋on-request＋auto_review - Auto-reviewを有効にしてもネットワークや書き込み範囲は広がらない
approval_policy = "never"では承認依頼がないためAuto-reviewは動かない- 秘密情報の送信、認証情報の探索、破壊的操作などは拒否対象になる
- 拒否や審査失敗時は、安全な代替策またはユーザー確認へ戻る
Auto-reviewは、サンドボックスを外して何でも自動実行させる機能ではありません。安全境界を残したまま承認待ちを減らせる点が最大の特徴です。まずはGit管理された小さなプロジェクトで、基本設定から試してください。
