長工作流最容易讓人把權限開大的時刻，是 Agent 其實做得下去，流程卻三不五時停在 approval。測試跑到一半要多一個權限、某個外部資源要連、寫入位置超出目前範圍，畫面又停下來等人。
這時有兩個地方可以動。放寬 sandbox，等待會變少；sandbox 留著，把跨界時的 reviewer 換掉，等待也會變少。Auto-review 選的是第二條。[1][2]
主 Codex Agent 平常照原本的 sandbox 規則工作。已經允許的 action 直接跑；某個符合條件的 action 要跨過目前 boundary、原本會停下來等 approval 時，request 才送給另一個 Reviewer Agent。[1][2]
Reviewer 只看這次跨界
第二個 Agent 沒有坐在旁邊逐條看 command。Sandbox 內已經能做的事情，不會因為開了 Auto-review 就多繞一次。
Reviewer 收到的是那次 escalation。它判斷這個 action 要不要放行；approve 後就執行這個 action，deny 則把理由送回主 Agent。主 Agent 接著改方案，找不到可接受的路再停下來找人。[2]
主 Agent 的工作是把任務做完，Reviewer 的工作只有眼前這次跨界。OpenAI 把兩個角色拆開後，也能把 Reviewer 單獨拿來 eval，不必用主 Agent 的 task completion 代替權限判斷的品質。[2]
這個 reviewer 有很明確的視野限制。Sandbox 內的行為可能完全不經過它；一個表面正常的跨界 request，也可能沒有露出背後真正的意圖。OpenAI 明確提醒，Auto-review 不能當成 deterministic security guarantee。[2]
Approval 一直跳，最容易修錯地方
OpenAI 4 月那篇 Auto-review 文章裡，有一段比功能介紹更值得看。
Approval 太常出現後，有些使用者直接切 Full Access；有些人把 prefix rule 寫得很寬，甚至一次放過所有 python 開頭的 command；也有人逐漸變成看到 prompt 就 approve。[2]
每一種做法都能讓流程少停幾次，改到的權限層卻差很多。
Manual approval 留著 sandbox，也留著人類 reviewer。Auto-review 還是用同一條 sandbox boundary，只把符合條件的跨界 approval 交給另一個 Agent。Full Access 則直接改 execution environment 的限制。
假設每天都在做、風險低、而且本來就應該被允許的操作反覆撞同一條 boundary，問題多半不在 reviewer。讓 Reviewer 永遠替同一批 request 蓋章，會把 permission 設定的錯誤藏起來。
Boundary 本身合理，只有少數例外真的需要審，而同步等人已經拖慢長工作流，這時 Auto-review 才對症。
兩邊看起來都叫「approval 太多」。實際施工時，一邊改 boundary，一邊改 reviewer。
99.1% 到底量了什麼
OpenAI 公布的幾個數字，如果只截最漂亮的一個，Auto-review 很容易被讀成「大概 99% 安全」。原始資料沒有這個結論。[2]
| 指標 | OpenAI 報告結果 | 量到的是什麼 |
|---|---|---|
| Human approval interruption | 約 200× less often | 同步等人的頻率下降多少 |
| Auto-approval rate on escalated actions | 99.1% | 被送來 review 的 escalation 裡，有多少被自動批准 |
| Overeagerness recall | 90.3% | synthetic overeager-risk cases 中，有多少被拒絕 |
| Prompt-injection recall | 99.3% | 指定 prompt-injection attack categories 中，有多少被拒絕 |
| MonitoringBench Hard recall | 96.1% | 惡意 trajectory 中，是否至少有一個 action 被 Reviewer 攔下 |
99.1% 的分母是 escalated actions。它主要反映 Reviewer 會不會把大量正常 escalation 一起卡死，也就是 Auto-review 用起來會不會很煩。
Safety 用的是另一批資料。90.3%、99.3%、96.1% 各自對應不同攻擊類型和 benchmark；OpenAI 把 destructive deletion、data tampering 等較廣的類別一起算時，結果是 90.2%。[2]
99.1% auto-approval 因此不能改寫成 99.1% 的 dangerous action 都能被安全處理。兩個百分比就算長得一樣，分母不同，意思就不同。
5 月 10 日公開的 MonitoringBench 提供了另一個參照。研究者建立 2,644 條 coding-agent attack trajectories，再把 attack generation 和 refinement 做得更強；部分 monitor 的 catch rate 明顯往下掉。[3]
它測的不是 Codex Auto-review，數字不能混用。Monitor 的成績會隨 attack distribution 改變；看 reviewer benchmark 時，單獨抄百分比很容易少掉最重要的條件。
Approval 一直跳，先看是哪一批 request 在跳。正常操作被 boundary 擋錯，該修的是 boundary；boundary 合理、卡在同步人工 review，Auto-review 才有用。高風險、不可逆，或制度上要求 human sign-off 的 action，停下來等人本來就是正確行為。
Auto-review 可以替你審一部分跨界 request。Boundary 畫在哪裡，還是另外一題。
References
- OpenAI, ChatGPT & Codex changelog: Automatic approval reviews, 23 April 2026.
https://developers.openai.com/codex/changelog - OpenAI Alignment, Auto-review of agent actions without synchronous human oversight, 30 April 2026.
https://alignment.openai.com/auto-review/ - Jotautaitė, M., Martinez, M. A., Matthews, O. & Tracy, T., MonitoringBench: Semi-Automated Red-Teaming for Agent Monitoring, 10 May 2026.
https://arxiv.org/abs/2605.09684