明明已經開了「Full Access」，Codex 為什麼還是會在改檔、跑指令時跳出來要你核准？關鍵在於它不是單一開關。以下先給結論：本文以 Codex CLI v0.145.0 實測，整理真正能讓它一路自動執行的設定方式。
問題根源：Codex 的「自動模式」其實由兩套彼此獨立的控制組成：sandbox 決定它能碰哪些資源，approval policy 決定它什麼時候必須停下來問你；網路存取則是第三道獨立關卡。放寬其中一項，不代表另外兩項也會跟著放行。而且 Codex 更新後，工作階段也可能悄悄被重設回預設政策。
CLI 要完全放手：--yolo 是唯一一次解除所有限制的旗標。若想保留 sandbox、但讓 Codex 在其範圍內自行作業，則要明確設定兩個軸向。建議每次工作階段開始時設定一次，更新後再重新確認。
# 真正全自動：無 sandbox、不跳提示（僅限一次性環境）：
codex --yolo
# 較安全：可在專案內自由修改，離開專案範圍時仍會詢問：
codex --sandbox workspace-write --ask-for-approval on-requestApp 要完全放手：打開核准選單，選擇 Full access；每次更新後都要再選一次，因為升級會重設模式。
以上是快速解答。接下來會完整拆解各種模式、它們底層對應的設定，以及不同工作情境該怎麼選。
三種 Codex 權限模式一次看懂
sandbox 管的是代理程式可以存取什麼，例如檔案與網路；approval policy 管的是它在哪些情況必須停下來徵求同意。所謂 Auto mode，只是把兩者配成不同組合；桌面 App 與 CLI 對同一組設定採用了不同名稱。
| App 名稱 | 實際行為 | 對應 CLI 設定 |
|---|---|---|
| Ask for approval | 可修改 workspace 內的檔案、執行一般本機指令；存取網路或 workspace 外資源前會詢問 | sandbox_mode = "workspace-write" + approval_policy = "on-request" |
| Approve for me（目前 App 預設值） | 邊界與前者相同，但符合條件的核准請求會交給 AI reviewer，而不是你本人處理（即 Auto-review） | 上述設定 + approvals_reviewer = "auto_review" |
| Full access | 沒有 sandbox、沒有核准提示，檔案與網路皆不受限制 | sandbox_mode = "danger-full-access" + approval_policy = "never" |
如果你主要使用 CLI，可直接透過 --sandbox 與 --ask-for-approval 設定，或在工作階段中用 /permissions 選擇預設組合。至於你是否還在比較不同客戶端，那是另一個問題；我們已在這篇比較 Codex 與 Claude Code。本文聚焦在權限設定本身。
為什麼開了「Full Access」還是會要求核准？
常見原因有三個，而且可能同時發生。
Sandbox 與核准政策是兩條不同軸線。workspace-write + on-request 讓 Codex 能在專案內自由修改，但只要碰到邊界，例如連網、讀寫 repo 外檔案或執行 sudo，它就會停下來問你。即使你放寬 sandbox，若 approval 仍是 on-request，跨越每個邊界時照樣會出現提示。
網路權限另有一道關卡。即使是 Full Access，網路也可能與檔案系統分開控管。如 @mxcl 在 2026 年 7 月 16 日所說，Codex「cannot use the Internet without full access, ending task until the user enables full access.」檔案寫入與網路存取不是同一項權限。
更新會重設模式。2026 年 7 月下旬已有多位使用者遇到這個問題：升級 Codex 後，現有工作階段會悄悄回到預設政策。@s_rafcon 在 7 月 22 日表示，執行緒會「switch their Full access flag to the default flag and [are] stuck asking for approval on every single edit.」因此，應在每次工作階段開始時設定模式，並在每次更新後重新檢查。
CLI 的 --full-auto 已移除，現在該怎麼設
codex --full-auto 過去是「在我的專案裡直接做、不用一直問」的快捷方式，等同於 approval_policy = "on-request" + sandbox_mode = "workspace-write"。不過互動式指令現在已不再接受它。以下是在 v0.145.0 的實測結果：
$ codex --full-auto
error: unexpected argument '--full-auto' found改為明確設定兩個軸向即可，效果與舊旗標完全相同：
# --full-auto 的現代替代方案
codex --sandbox workspace-write --ask-for-approval on-request
# 或者以非互動方式執行：不跳提示，但保留 sandbox：
codex -a never -s workspace-write exec "your task"codex exec --full-auto 仍接受此旗標，適合腳本使用；只有互動式指令會報錯。依 codex --help 所示，--ask-for-approval 可設為 untrusted / on-request / never，而 --sandbox 可設為 read-only / workspace-write / danger-full-access。App 中的每種「模式」，本質上都是這兩個設定的組合。
--yolo：什麼時候該直接解除全部限制
--yolo 是 --dangerously-bypass-approvals-and-sandbox 的簡寫。這才是真正的「不用管我」開關：它會啟用 danger-full-access 並設為 never，沒有檔案系統邊界，也不會再要求核准。正因名稱已經明白標示風險，--full-auto 移除後它依然保留；在 v0.145.0 上，codex --yolo 可正常解析，codex --full-auto 則會報錯。
不少有經驗的使用者會把它當預設，而在適合的任務上，這樣做確實合理：前提是環境本身就是你的安全邊界。請把使用的機器視為可隨時丟棄的環境：
- 在一次性 VM 或 dev container 執行，不要在日常主力機器上使用。
- 先從環境中移除正式環境憑證。
- 讓任務範圍維持明確且狹窄，繼續下一步前檢查
git diff。
--yolo 會移除所有關卡，因此一條意外的 rm -rf、git push 或 DROP TABLE 都會直接執行，這就是速度的代價。（透過自訂 model provider，將 Codex 指向 self-hosted 或 Anthropic-compatible endpoint，並不會改變這件事；sandbox 不在乎 API 背後是哪個模型。）
「Approve for me」與 Auto-review：交給 AI 替你核准
最新的模式、也是目前 App 預設值，是 Auto-review。符合條件的權限升級請求會交由另一個 reviewer agent 處理，也就是一個採用 GPT-5.4 Thinking（low）的小型 Codex；它會附上理由決定核准或拒絕。OpenAI 將此稱為「reviewer swap, not a permission grant」：它不會擴大可寫入目錄，也不會開放網路，只是改變了誰來說可以。
根據 OpenAI 於 2026 年 4 月 30 日發布的評估，相較手動核准，Auto-review 需要人類介入的頻率約低 200 倍；它會核准約 99.1% 的升級請求，而以全部動作計算則為 99.93%。其列出的 10,000 項動作示意快照中，9,280 項在 sandbox 內直接執行，720 項送交 reviewer，最後僅有 7 項遭拒。
系統也設有避免連續拒絕失控的保護機制：連續 3 次拒絕後，或最近 50 次 review 的滑動視窗內累積 10 次拒絕後，該回合就會中斷。被中斷時，可執行 /approve 開啟 Auto-review Denials 選擇器，允許其中一項動作重試。
但這些安全檢查也可能讓長時間任務卡住。2026 年 7 月下旬，有使用者在執行多小時的 /goal 任務時回報，週期性出現的「keep waiting?」提示打斷了原本能無人值守跑好幾天的流程。OpenAI 也明確表示，它「should not be treated as a guarantee of security」：red-team recall 雖高但並不完美，分別為 90.3% overreach、99.3% prompt injection、96.1% misaligned-model。它適合作為預設選項，卻不能取代高風險工作所需的 sandbox。
若不想透過 UI，而是要在設定檔中啟用：
approvals_reviewer = "auto_review"
[auto_review]
policy = """
Describe what the reviewer should allow or block here.
"""實際上該選哪一種模式？
- 日常本機開發：
workspace-write+on-request（「Ask for approval」）。凡是要離開 repo 的操作，你仍保有最終否決權，而真正容易造成損害的通常正是這些操作。 - 長時間無人值守任務：「Approve for me」（Auto-review）。要知道它仍會在標記到的動作上暫停，因此並不是零介入。
- 一次性的雜務，且在可丟棄環境中執行：
--yolo。它最快也最危險，只有環境本身不怕損壞時才適用。 - 閱讀或檢視程式碼庫：
read-only。無法寫入，也不會有意外變更。
坦白說，不存在既完全自主又絕對安全的設定。每往「免手動介入」靠近一步，都是把你的判斷交給分類器。對例行工作而言，這筆交換通常值得；對正式環境基礎設施而言，往往不是好主意。請依任務選模式，不要一次決定後就永遠不變。
FAQ
Codex 有 auto mode 嗎？
有，但它是一組預設組合，不是單一切換鈕。App 中的「Ask for approval」、「Approve for me」與「Full access」就是不同 auto mode；CLI 則可用 --sandbox 與 --ask-for-approval 組出相同行為，或透過 /permissions 切換。
如何讓 Codex 自動核准所有指令？
將 approval_policy = "never"。搭配 workspace-write 時，它不會再對 sandbox 範圍內的操作跳出提示；搭配 danger-full-access 時，也就是 --yolo，則會完全停止詢問。後者會移除所有防護，務必只在隔離環境中使用。
Codex 的 auto-review mode 是什麼？
Auto-review（approvals_reviewer = "auto_review"，App 顯示為「Approve for me」）會將核准決策交給 AI reviewer agent，而非由你親自處理。它會核准約 99% 的審查項目，人類介入頻率約低 200 倍，但這不是安全保證。
--full-auto 還能用嗎？
互動式 CLI 已不能使用。在 v0.145.0 的實測中，codex --full-auto 會回傳「unexpected argument」。codex exec --full-auto 仍可作為腳本的 deprecated alias 使用。互動式使用時，請改設 --sandbox workspace-write --ask-for-approval on-request。
--yolo 模式安全嗎？
不安全，這正是它名稱的意思。它會同時停用 sandbox 與所有核准機制。只有在已移除正式環境憑證、任務範圍明確，且可隨時捨棄的 VM 或 container 中，才算是合理選擇。