Codex 核准政策怎麼選？一次搞懂不受信任、依請求、永不要求核准
2026-08-11
Aibasil
83
使用 Codex 進行 AI Coding 或 Agentic Coding 時，除了模型與 Sandbox 沙盒權限之外，「核准政策 Approval Policy」也是非常重要的設定。 Codex 目前常見的核准模式包括「不受信任」、「依請求」與「永不要求核准」。三者最大的差異，在於 Codex 執行指令時，什麼情況需要停下來詢問使用者。 本文整理三種模式的差異，並進一步說明 Approval Policy 與 Sandbox Mode 之間的關係，幫助你依照日常開發、自動化與安全需求選擇適合的設定。
一、什麼是 Codex 的核准政策？
當我們使用一般聊天式 AI 時，大部分情況只是：
提出問題 → AI 回答。
但使用 Codex 進行 AI Coding 時，情況就不太一樣。
Codex 可能需要：
- 讀取專案檔案
- 搜尋程式碼
- 修改程式
- 建立新檔案
- 執行 Shell 或 PowerShell
- 執行 Build
- 執行 Test
- 安裝套件
- 存取外部資源
這時就會出現一個很重要的問題：
Codex 準備執行某項操作時，什麼情況需要先取得我的同意？
這就是 Approval Policy，核准政策。
OpenAI 官方目前列出的常見核准政策包括：
untrusted on-request never
它們控制的是 Codex 何時停下來要求人工核准。
二、不受信任：Untrusted
設定方式：
approval_policy = "untrusted"
這是三種模式中相對保守的方式。
OpenAI 官方對 untrusted 的說明是：
Codex 遇到不屬於可信任集合的指令時，會先要求使用者核准。
可以簡單理解成：
「這個操作安全嗎？不確定就先問我。」
流程大致像這樣：
Codex 準備執行指令
↓
是否屬於可信任操作？
↓ ↓
是 否
↓ ↓
直接執行 詢問使用者
適合什麼情況？
如果你是：
- 第一次使用 Codex
- 正在處理陌生 Repository
- 不熟悉專案內容
- 希望掌握 AI 執行的操作
- 對環境安全要求比較高
可以考慮使用這個模式。
優點
安全性與人工控制程度比較高。
缺點
如果 Codex 執行的是較長的 Agentic Coding 任務，過程中可能比較常被人工核准打斷。
三、依請求：On-request
設定方式：
approval_policy = "on-request"
這是一般開發環境中相當值得使用的一種模式。
OpenAI 官方對它的說明是：
Codex 預設在 Sandbox 沙盒範圍內工作，當它需要超出目前的沙盒邊界時，再提出核准要求。
簡單理解就是：
「能自己做就自己做，需要額外權限再問我。」
流程大概是：
Codex 執行任務
↓
Sandbox 是否允許？
↓ ↓
允許 不允許
↓ ↓
直接執行 請求核准
例如可以搭配：
approval_policy = "on-request" sandbox_mode = "workspace-write"
此時 Codex 可以在 Workspace 所允許的範圍內工作。
當某項操作需要突破目前 Sandbox 的權限邊界時，再向使用者請求核准。
四、為什麼 On-request 很適合 Agentic Coding？
Agentic Coding 和傳統的程式碼補全不太一樣。
它的工作流程可能是：
理解需求 ↓ 讀取 Repository ↓ 分析程式碼 ↓ 修改程式 ↓ 執行測試 ↓ 讀取錯誤 ↓ 修正程式 ↓ 再次測試
這是一個連續的多步驟工作流程。
如果每執行一個操作都需要人工確認，Agent 就會頻繁停下來。
但如果把所有權限完全開放，又可能增加安全風險。
因此 on-request 的概念就是：
在允許的工作區內保持自主性，真正需要更高權限時再找人。
這也是安全性與 Agent 自主性之間比較容易取得平衡的方式。
OpenAI 目前的 Codex 基本設定文件，也以 approval_policy = "on-request" 作為 Approval Prompts 的設定示例。
五、永不要求核准：Never
設定方式：
approval_policy = "never"
這個模式最容易被誤解。
看到「永不要求核准」，可能會直覺理解成：
Codex 什麼都可以自動執行。
其實不是。
真正的意思比較接近：
Codex 不會停下來向使用者提出核准要求。
OpenAI 官方也明確說明，never 代表 Agent 不會為 Approval Prompt 停下來。
六、Never 不等於最高權限
這是一個很重要的觀念。
例如：
approval_policy = "never" sandbox_mode = "read-only"
此時：
Sandbox 仍然是 Read-only。
也就是 Codex 的操作範圍仍受到唯讀沙盒限制。
如果 Codex 想做一件目前 Sandbox 不允許的事情，它不會跳出視窗詢問：
是否允許我取得額外權限？
而是只能在目前限制內繼續嘗試；無法完成的受限操作就無法藉由人工核准突破。OpenAI 官方也特別指出，never 可以搭配各種 Sandbox Mode 使用，Codex 仍然會受到所設定的沙盒限制。
因此：
Never ≠ 所有權限開放
真正應該理解成：
Never = 不要向我跳出核准詢問
七、Approval Policy 與 Sandbox Mode 不一樣
要真正理解 Codex 的權限設定，最重要的一件事情就是：
Approval Policy 與 Sandbox Mode 是兩個不同概念。
可以簡單記成：
Sandbox Mode ＝ Codex 可以在哪些範圍工作 Approval Policy ＝ 遇到權限邊界時，要不要詢問使用者
例如：
Codex 想執行某個操作
↓
Sandbox 判斷是否允許
↓
超出權限範圍
↓
Approval Policy 決定如何處理
所以只看「核准政策」是不夠的。
真正的 Codex 權限行為，是：
Sandbox Mode ＋ Approval Policy
兩者共同決定。
八、常見 Sandbox Mode 有哪些？
Codex 的 Sandbox 可以控制 Agent 執行指令以及存取檔案系統的範圍。
常見模式包含：
read-only workspace-write danger-full-access
其中 danger-full-access 會大幅放寬沙盒限制，因此 OpenAI 官方特別提醒使用時需要謹慎。
可以簡單理解為：
Read-only
偏向：
可以查看，但限制寫入。
適合分析、閱讀程式碼等情境。
Workspace-write
偏向：
允許 Codex 在工作區內進行開發操作。
一般 AI Coding、修改程式、測試與 Agentic Coding，比較常會使用這類模式。
Danger-full-access
代表：
大幅解除 Sandbox 的限制。
這時 Agent 的自主程度非常高，但相對也需要承擔更高風險。
因此不建議只是為了「少按幾次確認」就直接使用。
九、三種核准政策，用一句話記住
如果覺得三個英文名稱不好理解，可以直接記這三句話。
Untrusted
有風險或不在可信任集合，就先問我。
特色：
安全優先
On-request
能自己做就自己做，需要突破權限時再問我。
特色：
安全性與自主性平衡
Never
不要問我，在目前允許的範圍內完成工作。
特色：
不需要人工互動式核准
十、不同使用情境該怎麼選？
情境一：第一次使用 Codex
可以考慮：
Untrusted
因為你可以比較清楚看到 Agent 準備執行哪些操作。
情境二：日常 AI Coding
可以優先考慮：
On-request
讓 Codex 在 Sandbox 範圍內保持一定自主性，需要額外權限時再詢問。
情境三：Agentic Coding
如果希望 Codex 可以連續完成：
讀程式 → 修改 → 執行 Test → 讀取 Error → 修正 → 再測試
可以考慮：
approval_policy = "on-request" sandbox_mode = "workspace-write"
這是一個兼顧操作流暢度與權限控制的組合。
情境四：CI/CD 或無人值守自動化
則可能會考慮：
Never
因為這類環境本來就不適合等待人工按下：
Allow
但這時更要仔細設計 Sandbox 的權限範圍。
OpenAI 官方也建議互動式執行優先使用 on-request，而非互動式執行則可以考慮 never。
十一、我自己會怎麼選？
如果是一般的 AI Coding 與 Agentic Coding，我會優先從：
approval_policy = "on-request" sandbox_mode = "workspace-write"
開始。
原因不是因為它「權限最大」，而是它比較接近合理的人機協作方式：
工作區內
Codex 自己完成
↓
需要突破權限
↓
再交給人類決定
如此可以減少不必要的人工打斷，同時保留重要的權限邊界。
十二、最後整理
Codex 的三種核准政策，其實沒有想像中複雜。
只需要記住：
Untrusted ＝ 不信任的操作先詢問 On-request ＝ 需要額外權限時詢問 Never ＝ 不跳出人工核准
另外還有一句更重要：
Approval Policy ≠ Sandbox Mode
Approval Policy 控制：
什麼時候需要人類核准。
Sandbox Mode 控制：
Agent 本身可以在哪些範圍內工作。
真正影響 Codex 自主程度的，是兩者的組合。
當 AI Coding 從單純「幫我寫一段程式」逐漸進入 Agentic Coding，AI 開始能夠讀取 Repository、修改多個檔案、執行測試並自行修正錯誤後，如何設計適當的權限邊界，也會變成使用 AI Coding Agent 時非常重要的一環。