Codex の承認待ちが多くなると、つい「Codex auto-review か codex auto approval を入れれば人間が見なくて済む」と考えたくなります。codex approvals_reviewer、approvals_reviewer = "auto_review"、codex autoreview で検索している人も、知りたいのはほぼ同じ論点です。けれど、ここを雑に扱うと、承認を減らしたつもりで危険な外部通信や workspace 外編集を別の agent に丸投げするだけになります。
この記事では、2026年7月19日時点の OpenAI 公式ドキュメントを前提に、Codex auto-review を 自動承認機能ではなく、approval 境界の reviewer 差し替えとして設計する方法を整理します。codex approvals_reviewer、approvals_reviewer = "auto_review"、codex autoreview を調べている人が最初に知るべきなのは、「これは codex auto approval の恒久許可ではない」という点です。sandbox / approval 全体の基礎は Codex sandbox / approvals 設計ガイド、config.toml や profile ごとの設定面は Codex config / profile 設定ガイド、Codex が出した差分を受け入れる判断は Codex レビュー完了ゲート設計ガイド、通常の PR review 運用は Codex code review 実践ガイド、定期的に approval queue を棚卸しする運用は Codex Automations 実践ガイド、セキュリティ診断 lane は Codex Security plugin ガイド に分けています。
先に結論: auto-review は権限を広げない
Codex auto-review で最初に固定すべき前提はこれです。
approval_policy = "on-request"
approvals_reviewer = "auto_review"この設定は、Codex の sandbox を広げません。network を有効化しません。workspace 外の書き込みを許しません。変わるのは、approval prompt を誰が見るかです。
| 設定 | 役割 |
|---|---|
sandbox_mode / permissions profile | そもそも何ができるかを決める |
approval_policy | 境界越えを止めるかどうかを決める |
approvals_reviewer | 止まった approval request を誰が見るかを決める |
auto_review.policy | auto-review 側の判断方針を補足する |
だから、auto-review は「安全な作業をもっと自動化するための仕上げ」です。危険な設定を安全に見せるための機能ではありません。
何が既存 Codex 記事と違うのか
このサイトには Codex の安全運用記事がいくつかあります。この記事は、その中でも approval request を自動 reviewer に渡す境界だけを扱います。
| 記事 | 主題 |
|---|---|
| Codex sandbox / approvals | sandbox、approval、permissions profile、network allowlist の全体設計 |
| Codex code review | GitHub PR 上の @codex review と review guidelines |
| Codex review gate | Codex の成果物を受け入れる前の人間側チェック |
| Codex Security plugin | repo 全体や差分の security scan / deep scan / triage |
| この記事 | approvals_reviewer = "auto_review"、denial、override、運用ログ |
つまり、この記事は「Codex にレビューさせる」話ではありません。Codex が何かを実行しようとして approval 境界で止まったとき、人間の代わりに reviewer agent が判断する範囲の話です。
auto-review が発火する場面
OpenAI の auto-review docs では、auto-review は interactive approval がある場合にだけ適用されます。代表例は approval_policy = "on-request" です。approval_policy = "never" では、そもそも approval prompt が出ないので auto-review するものがありません。
実務で発火しやすいのは次の場面です。
| 発火場面 | 例 | 最初の扱い |
|---|---|---|
| sandbox 権限の escalation | workspace 外の file edit、強い shell 実行 | 原則 deny 寄り |
| network access | blocked domain への外部通信 | domain と目的が説明できる時だけ検討 |
| MCP / app tool approval | write 系 tool、open-world tool、destructive tool | tool risk tier と対応づける |
| Computer Use の新規 domain | ブラウザで新しい website に入る | credential 入力前に止める |
| policy category prompt | granular policy で surfaced された request | category ごとの判断にする |
ここで大事なのは、auto-review が通常の許可済み操作には割り込まないことです。active sandbox 内でそのまま実行できる command や、すでに allow されている tool call は、reviewer agent を通らずに進みます。
導入順は「境界を狭める」が先
私なら、auto-review をいきなり有効にしません。先に人間 reviewer で承認ログを見ます。
sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"この状態で1週間ほど使い、approval request を次の4つに分類します。
- 常に許可してよい反復作業
- 条件付きで許可してよい作業
- 人間判断が必要な作業
- 常に拒否すべき作業
たとえば、pnpm run build が毎回止まるなら、auto-review の policy を甘くする前に sandbox / permissions profile 側を見直します。よく使う安全な操作を「毎回 reviewer agent に判断させる」のは、設計として弱いです。
逆に、外部 network、workspace 外編集、MCP write tool、secret に近い file access は、auto-review に任せる前に ask / deny の基準を先に決めます。
config の最小例
最小構成はかなり短くできます。
sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "auto_review"ただし、チーム導入ではこのままだと判断方針が薄いです。最低限、auto-review policy には「何を拒否するか」を書きます。
auto_review.policy = """
Approve only low-risk actions that are clearly within the current task.
Deny actions that read secrets, exfiltrate private data, weaken security controls,
write outside the workspace, or contact unapproved network destinations.
If the request is ambiguous, deny and ask for a human decision.
"""ここで「便利そうなら approve」と書かない方がいいです。auto-review は承認を増やすためではなく、人間が見なくてもよい低リスク request を通し、高リスク request を止めるために使います。
denial は普通の失敗ではない
auto-review で明示的に denial された action は、ただの command error ではありません。OpenAI docs では、Codex は main agent に rationale を返し、同じ outcome を workaround や policy circumvention で追わせないようにします。
これは実務上かなり重要です。
悪い挙動はこうです。
Network request was denied.
Try curl through another domain.
Try a different tool.
Try reading token from local config.これは denial を「障害」として扱っています。正しくは、denial は安全境界からの拒否です。
良い挙動はこうです。
The network request was denied because the destination was outside the approved domains.
I will continue with local docs and report the missing external verification.auto-review を導入するなら、最終報告にも denial を残します。何が拒否され、どう迂回せずに作業を縮退したかが分からないと、後から review できません。
circuit breaker を前提にする
OpenAI docs では、current open-source implementation の auto-review は、同じ turn 内で denial が続く場合に circuit breaker を持ちます。連続 denial や rolling window 内の denial が一定数に達すると、Codex は warning を出して turn を interrupt します。
これは「auto-review が壊れた」ではありません。同じ危険な要求を agent が繰り返している可能性を止めるための防御です。
運用では、circuit breaker が出た run を次のように扱います。
| 見る項目 | 判断 |
|---|---|
| denial が同じ目的に集中している | prompt や task scope が危険に寄っている |
| network denial が多い | allowlist か research 手順が曖昧 |
| workspace 外編集 denial が多い | 作業場所の設計が悪い |
| MCP / app tool denial が多い | tool risk tier と approval mode が噛み合っていない |
| denial 後に代替実行を試している | agent 指示を強める |
auto-review の breaker は、作業を止めるためだけでなく、権限設計の悪さを見つける signal として使えます。
/approve は広い override ではない
Codex には、auto-review が denied した最近の action を人間が1回だけ retry させる /approve 導線があります。
ここで誤解しやすいのは、/approve が「今後これを許す」設定ではないことです。OpenAI docs では、override は exact denied action に対する one retry です。似た action や将来の action まで許可するものではありません。
私なら、/approve を使うときは次の3点を残します。
### Auto-review override record
- denied_action: `gh pr view --json ...`
- reason_to_override: GitHub PR metadata is required for the requested review.
- retry_scope: one retry only; do not broaden network or filesystem permissions.逆に、秘密情報の読み取り、credential の送信、destructive command、外部 side effect を伴う操作は、/approve で済ませず設定と作業手順を見直します。
MCP / app tool は tool risk tier とつなぐ
auto-review は shell だけの話ではありません。MCP や app tool の approval request も対象になります。ここは、AI エージェントの tool risk tier とつなげると運用しやすいです。
| tool tier | 例 | auto-review の扱い |
|---|---|---|
| read | issue / docs / calendar の読み取り | low-risk なら approve 候補 |
| inspect | status / diff / metadata 確認 | task 内なら approve 候補 |
| draft | PR body draft、ticket draft | human review 前提で approve 候補 |
| write | comment 投稿、file update、calendar 作成 | 原則 human approval |
| external action | deploy、payment、メール送信 | 原則 deny or explicit human |
| forbidden | secret exfiltration、policy weakening | deny |
app tool の設定に open_world_hint や destructive_hint がある場合、auto-review に任せる前に default approval mode を保守的にします。tool 側の annotation を見ずに「auto-review があるから大丈夫」と扱うのは危険です。
導入時の判断基準
auto-review を入れるべきなのは、次の条件が揃ってからです。
- 標準 sandbox / permissions profile が決まっている
- denied / approved のログを見る owner がいる
- network allowlist が作業種別ごとに分かれている
- MCP / app tool の read / write / destructive 分類がある
- denial 後に workaround しない指示がある
/approveを使う条件が文書化されている- final report に denial / override / missing verification を残す
逆に、次の状態ならまだ早いです。
- full access を常用している
.envや secret file を deny していない- network を broad allow している
- approval request のログを誰も見ていない
- denial が出ても「別手段で続けて」と頼みがち
- MCP write tool と read tool の扱いが同じ
auto-review は成熟した運用を少し軽くする機能です。未整理の権限設計を埋める機能ではありません。
実務テンプレート
チームの AGENTS.md や runbook には、このくらい短く書いておくと扱いやすいです。
## Codex Auto-review Policy
- Auto-review may approve low-risk requests that are clearly inside the current task.
- Auto-review must deny requests that read secrets, send private data, weaken security controls,
write outside the workspace, or contact unapproved network destinations.
- A denial is a security decision, not a normal command failure.
- After a denial, do not try alternate commands for the same outcome unless the alternative is materially safer.
- Use `/approve` only for one exact denied action with a written reason.
- Report all denials, overrides, and skipped verification in the final summary.ここまで書くと、auto-review の役割がはっきりします。人間の承認を消すのではなく、承認が必要な場面のうち低リスクなものだけを前に進め、危険なものは止める。その前提が揃って初めて、長い Codex run の待ち時間を減らせます。
まとめ
Codex auto-review は、承認をなくす機能ではありません。approval 境界に来た request を、別の reviewer agent が見る機能です。
最初にやるべきことは、approvals_reviewer = "auto_review" を入れることではなく、sandbox、network、MCP / app tool、secret、denial 後の動きを整理することです。そのうえで、低リスクな approval 待ちだけを auto-review に流せば、人間は本当に見るべき判断に集中できます。
Codex を強く使うほど、承認設計は「邪魔な確認」ではなく、作業を安全に続けるための run control になります。