自動審查（Auto-review）

自動審查會在沙箱邊界上用獨立的審查智能體替代人工審批。主 Codex 智能體仍然執行在同一個沙箱內，使用相同的審批策略，以及相同的網路和檔案系統限制。變化只在於：由誰來審查符合條件的升級請求。

自動審查如何工作

從高層看，流程如下：

1. 主智能體在 read-only 或 workspace-write 內工作。
2. 當它需要越過沙箱邊界時，會請求審批。
3. 如果設定了 approvals_reviewer = "auto_review"，Codex 會把該審批請求路由給獨立的審查智能體，而不是停下來等待人工確認。
4. 審查智能體決定該動作是否應該執行，並返回理由。
5. 如果動作獲批，執行會繼續；如果被拒絕，主智能體會被要求尋找實質上更安全的路徑，或者停止並詢問使用者。

自動審查只是更換了審查者，不是授予新的權限。它不會擴大 writable_roots、啟用網路存取，也不會弱化受保護路徑。它只改變 Codex 如何處理那些原本就需要審批的動作。

何時觸發

自動審查會審查那些本來會暫停等待人工確認的審批請求，包括：

• 請求提升沙箱權限的命令列（shell）或執行（exec）工具呼叫。
• 被當前沙箱或策略阻止的網路請求。
• 允許可寫根目錄之外的檔案編輯。
• 根據工具註解或設定的審批模式，需要審批的 MCP 或應用工具呼叫。
• Computer Use（計算機操作）存取新網站或新域名。

自動審查不會為沙箱內已允許的常規動作執行。如果某條命令可以在當前 sandbox_mode 下執行，或者某個工具呼叫仍停留在允許策略內，主智能體會直接繼續執行，不會經過審查。

Computer Use（計算機操作）是一個單獨場景。Computer Use 的應用審批仍會直接呈現給使用者，因此自動審查不會替代這些應用級提示。

自動審查會阻止什麼

從高層看，自動審查旨在阻止這類動作：

• 向不可信目的地傳送私有資料、金鑰或憑據；
• 探測憑據、令牌、Cookie 或會話材料；
• 大範圍或持續性削弱安全邊界；
• 存在重大不可逆損害風險的破壞性動作。

具體策略位於開源 Codex 儲存庫： policy_template.md 和 policy.md。企業可以通過 guardian_policy_config 自定義策略，個人使用者也可以用本機 [auto_review].policy 自定義。

審查智能體會看到什麼

審查智能體本身也是一個 Codex 智能體，但任務範圍比主智能體更窄：判斷某個具體的越界動作是否應該執行。

它會看到壓縮後的對話記錄和精確的審批請求。通常包括使用者訊息、已展示的助手進度更新、相關工具呼叫與工具輸出，以及當前被提議審批的動作。必要時，它也可以進行只讀檢查來補足缺失上下文，但這種情況很少發生。

隱藏的助手推理過程不會包含在內。自動審查看到的是保留下來的聊天 item 和工具證據，而不是私有思維鏈。

拒絕與失敗行為

顯式拒絕不會被當作普通沙箱錯誤處理。Codex 會把審查理由返回給主智能體，並附加更強的指令：

• 不要通過變通方法、間接執行或繞過策略來追求同一個結果。
• 只有在存在實質上更安全的替代路徑時才繼續。
• 否則停止並詢問使用者。

Codex 還會按輪次應用拒絕熔斷機制。在當前開源實現中，如果同一輪次內連續出現 3 次拒絕，或由最近 50 次審查組成的滾動視窗內出現 10 次拒絕，自動審查會中斷該輪次。

任何非拒絕結果都會重置連續拒絕計數器。當熔斷機制觸發時，Codex 會發出警告，並以中斷方式中止當前輪次，而不是讓智能體繼續迴圈嘗試更多升級。

超時會和顯式拒絕分開呈現，主智能體也會被告知：單獨的超時並不能證明該動作不安全。

對於被拒絕的動作，也存在顯式覆蓋路徑。在當前開源 TUI 中，執行 /approve 可以開啟 Auto-review Denials（自動審查拒絕項） 選擇器，然後從最近被拒絕的動作中選擇一個，為一次重試授予核准。Codex 每個任務最多記錄 10 個最近拒絕項。這個核准範圍很窄：只適用於被拒絕的那個精確動作，不適用於未來的類似動作；只記錄為同一上下文中的一次重試；並且重試仍會經過自動審查。底層實現上，Codex 會為該精確動作注入開發者作用域的審批標記。審查智能體隨後會把這個顯式使用者覆蓋作為上下文，但仍會遵循策略；如果策略認為使用者不能覆蓋這類拒絕，它仍然可以再次拒絕。

設定

設定細節請參見託管設定。

預設審查策略位於開源 Codex 儲存庫：core/src/guardian/policy.md。企業可以在託管要求中使用 guardian_policy_config 替換其中與租戶相關的策略部分。個人使用者也可以在 config.toml 中設定本機 [auto_review].policy，但託管要求優先順序更高：

[auto_review]
policy = """
YOUR POLICY GOES HERE
"""

如果要自定義策略，先完整複製預設策略文本，再根據你的具體風險畫像迭代。

在不削弱安全性的前提下降低審查量

當沙箱本身已經覆蓋常見安全工作流程時，自動審查的效果最好。如果太多日常動作都需要審查，應優先修正邊界，而不是讓審查智能體永遠核准噪聲型升級。

實踐中，最有效的調整包括：

• 為臨時目錄或你有意使用的相鄰儲存庫新增範圍很窄的 writable_roots。
• 新增範圍很窄的字首規則。優先使用精確命令字首，例如 ["cargo", "test"] 或 ["pnpm", "run", "lint"]，而不是 ["python"] 或 ["curl"] 這類寬泛模式。寬泛規則常常會抹掉自動審查本來要守住的邊界。

自動審查會話記錄預設保留在 ~/.codex/sessions 下，因此你可以先讓 Codex 分析那裡的歷史流量，再調整策略或權限。

限制

自動審查會改善長時間智能體式工作的預設執行點，但它不是確定性的安全保證。

• 它只會評估那些請求越過邊界的動作。
• 它仍可能出錯，尤其是在對抗性或非常規上下文中。
• 它應該補充而不是替代良好的沙箱設計、監控和組織級策略。

關於研究動機和已釋出的評測結果，請參見 Alignment Research 關於 Auto-review 的文章。

來源：</zh-TW/docs/sandboxing/auto-review> 更新時間：2026-05-11（UTC）