三種核准模式:讓 Codex 該放手時放手、該把關時把關

上一課你跑了第一個任務,大概注意到一件事:Codex 真正要改檔、要在終端機跑指令之前,會停下來問你要不要套用。這個「要問到什麼程度」不是固定的,而是可以調的——調對了,你能一邊快、一邊安心;調錯了,不是每兩秒被打斷煩死你,就是它自己在背景把你沒預期的檔案改掉。

很多人用 Codex 卡在這裡:要嘛全程盯著一步步按 Enter,累到乾脆不用;要嘛一開始就開到最放權,結果被 AI 改壞一整包程式碼、嚇到再也不敢放手。這堂課就是要你跳過這兩種極端,建立一套「什麼任務該用哪個模式」的判斷力。

這堂課適合誰適合:已經裝好 Codex CLI、跑過第一個任務,想搞懂「怎麼讓它自己動手又不出事」的人(本課程屬工程師 / 進階應用專區)。需要基礎:會開終端機、上一課的內容。前置課:第 1 課(Codex 是什麼、怎麼裝、跑第一個任務)。

這堂學什麼

Codex 的權限其實是兩個獨立旋鈕:sandbox(能碰到什麼)+ approval(要不要問你)——搞懂這個,所有模式一秒看穿
三個官方預設:Read Only、Auto(預設)、Full Access,各自對到什麼場景
對應的指令旗標:--sandbox、--ask-for-approval,以及在 TUI 裡用 /permissions 即時切換
為什麼 --full-auto 現在會跳警告(它被淘汰了),以及 --yolo 到底能不能碰
用 Git 當安全網,讓你放手時真的不怕:改壞一行指令就還原
把模式觀念用在 codex exec 非互動模式:寫進腳本 / CI 時該怎麼設權限

觀念一:別背模式名稱,先看懂兩個旋鈕

網路上教 Codex 模式的文章,常常直接丟給你三四個名字要你背,越背越亂——因為 6 月跟 7 月的介面用字還不太一樣。真相其實很單純:Codex 的權限是由兩個彼此獨立的旋鈕組合出來的,你只要記住這兩個,任何版本的介面你都看得懂。

Codex 權限的兩個旋鈕:sandbox 決定能碰什麼、approval 決定要不要問你,兩者組合出所有模式

旋鈕一:sandbox(沙盒)——它能碰到什麼。 這是「圍籬」,決定 Codex 的手能伸多遠,有三檔:

read-only:只能讀,不能寫任何檔案、不能跑會改東西的指令。
workspace-write:可以讀,也可以在你目前這個專案資料夾內寫檔、跑指令;但要碰資料夾以外的東西、或連外網,預設擋下。
danger-full-access:拆掉圍籬,檔案系統跟網路都不設限。

旋鈕二:approval(核准)——它要不要停下來問你。 這是「關卡」,有幾檔:

untrusted:只有它判斷「不可信」的指令才問。
on-request:它在沙盒內自己做,一旦需要越過沙盒邊界(改外面的檔、連網),就停下來問你。這是最常用的一檔。
on-failure:先在沙盒裡試,失敗了才問你要不要放權重試。
never:從不問,適合自動化腳本(但務必配合夠緊的沙盒)。

看懂了嗎?圍籬管「能碰什麼」,關卡管「要不要問」,兩個旋鈕各轉各的。 所謂的「模式」,只是這兩個旋鈕的常用組合有個好記的名字而已。

觀念二:三個預設,涵蓋九成場景

實際用的時候,你不用每次自己轉兩個旋鈕。Codex 把最實用的組合包成三個預設,在 TUI(互動介面)裡按 /permissions 就能切:

Codex 三種核准預設對照:Read Only 只讀、Auto 沙盒內自動、Full Access 全放權,各自的旋鈕組合與適用場景

Read Only(唯讀)

旋鈕組合:--sandbox read-only。Codex 只讀你的程式、回答問題、給修改草案,不會自己改任何檔、不跑會有副作用的指令。最安全。適合「先讓它讀懂專案、講講它打算怎麼改」的探索階段。

Auto(預設,日常主力)

旋鈕組合:--sandbox workspace-write --ask-for-approval on-request。Codex 可以在目前專案資料夾內自己讀、改檔、跑指令,不會一步步煩你;但要改資料夾外的檔、或連外網時,會停下來問。這是你八成時間會用的模式:夠自動、又有邊界。

Full Access(全放權)

旗標:--dangerously-bypass-approvals-and-sandbox(別名 --yolo)。沒有沙盒、也不問你,直接全速跑。快,但你必須百分之百信任這個任務的範圍,而且環境本身要夠隔離(例如拋棄式容器)。

怎麼選:一句話原則不熟的專案 / 重要程式碼 → 用 Auto(它在沙盒內自己跑,越界才問你)。要它單純讀、給建議、做 code review → 用 Read Only。只有在「範圍明確、環境可拋棄、你完全清楚它要做什麼」時,才動 Full Access。九成日常任務,Auto 就是最佳解。

觀念三:為什麼這件事是「安全閥」,不是「麻煩」

新手常把核准模式當成擋路的東西——「它一直問,好煩,我開全自動不就好了?」這個想法會害你。

放權越大越省事,但風險是指數上升的:Read Only 頂多給你爛建議,你不採用就沒事;Auto 會動你的檔,但被關在專案資料夾內、越界會問;Full Access 則是「AI 判斷錯了,直接執行,而且可能連你的家目錄、雲端憑證、線上資料庫都碰得到」。核准模式就是你在放權光譜上,親手決定「AI 的判斷失誤,最多能造成多大破壞」。

放權光譜:從 Read Only 到 Full Access,便利度往右升、可能的破壞範圍也往右暴增,核准模式就是你手上的安全閥

破壞性操作,永遠留一道關卡刪檔、改資料庫、git push、部署上線、跑 rm 或連到正式環境——這些「難還原」的動作,絕對不要在 Full Access 下讓 AI 自己決定。保持在 Auto 或更嚴,讓它越界前停下來問你,你親眼看過再點頭。省下的那幾秒,遠不值得一次線上事故。

這也是為什麼官方把全放權那顆按鈕命名成 --dangerously-bypass-approvals-and-sandbox——名字這麼長、這麼嚇人,是故意的,就是要你打之前想清楚。

觀念四:兩層防護,不是一層

再進一步:sandbox 和 approval 是兩層獨立的防護,不要把它們當成同一個東西。

兩層防護:sandbox 是作業系統層級的被動圍籬、approval 是把決定權交回你的主動關卡,兩層疊起來才安全

sandbox 是被動的牆:就算 Codex 或某個它跑的指令「想」亂搞,牆會直接擋下越界的檔案 / 網路操作。它不靠 AI 的判斷,靠的是作業系統層級的隔離。
approval 是主動的關卡:當 AI 想做沙盒不允許的事,關卡把決定權交回你手上。

兩層疊起來才安全:沙盒防「AI 判斷正確但你不想要」,approval 防「AI 想越界時你能攔」。Full Access 之所以危險,正是因為它一次拆掉了兩層。 這也是為什麼「開 Full Access 但在乾淨的容器裡跑」勉強可接受(至少環境是隔離的),但「開 Full Access 直接在你自己的主力電腦上跑」是在玩火。

觀念五:Git 才是你真正的後悔藥

前面講的是「事前」防護。但再怎麼防,AI 總有改到你不滿意的時候。這時候讓你敢放手的,是版本控制。

Git 安全網:動手前 git status 確認乾淨、Codex 改完 git diff 看清楚、不滿意 git restore 一鍵還原

養成一個鐵律:讓 Codex 動手前,先確保專案在 Git 控制下、工作區是乾淨的。 這樣不管它改成什麼樣,你都能一鍵回到動手前的狀態。

# 動手前:確認工作區乾淨(沒有一堆未提交的改動混在一起)
git status

# 讓 Codex 跑任務……

# 它改完、你要 review 時:看它到底動了哪些行
git diff

# 改得好 → 正常 commit;改壞了 → 一鍵還原到動手前
git restore .

有了 Git,即使你在 Auto 模式讓它改了十個檔,發現方向不對,git restore . 三秒鐘全部回到原樣,完全無痛。沙盒是圍籬、approval 是關卡、Git 是後悔藥——三個一起用,你才能真的放心把手放開。 Git 的完整心智模型我們會在後面課程展開,今天先把「動手前 status、動手後 diff」這個習慣建起來。

手把手實戰:切模式、看差別

光看觀念沒用,開個終端機跟著做一遍,你會秒懂。找一個已經是 Git 倉庫的練習專案(隨便一個都行),cd 進去。

先確認你的版本與現況

不同版本的預設值和用字會微調,先對一下:

codex --version    # 這篇對到 0.142.5,你的接近就行

進到互動介面後,打 /status 可以看目前這個 session 用的是哪個 sandbox、哪個 approval、哪個模型。養成開工先看一眼的習慣,你就不會「以為在 Read Only 結果它把檔改了」。

用 Read Only 讓它先「動口不動手」

啟動時直接指定唯讀,讓它讀懂專案、講講打算怎麼改,但保證不動你一根寒毛:

codex --sandbox read-only

然後丟一個需求,例如「幫我看這個專案的登入流程有沒有安全問題,先只告訴我你會怎麼改,不要動手」。它會給你一份分析和計畫。這一步是用最低風險先對齊方向——尤其面對不熟的專案,先讀再改,少踩雷。

在 TUI 裡用 /permissions 即時切到 Auto

看完計畫覺得 OK,不用重開。直接在對話框打:

/permissions

選 Auto(對應 --sandbox workspace-write --ask-for-approval on-request)。現在再說「好,照你剛剛的計畫改」,它就會在專案資料夾內自己動手改檔、跑測試。過程中如果它需要 npm install(要連網下載套件)這類越界動作,會停下來問你——這時你看清楚它要裝什麼,再決定要不要放行。

用 git diff 驗收

它說改完了,先別急著相信。開另一個終端(或用 /diff)看:

git diff

逐段看它改了什麼。滿意就 commit,不滿意就 git restore . 回到原點,重新調整你的需求再讓它跑一次。這個「改 → diff → 收或退」的迴圈,就是用 Codex 的核心節奏。

需要非互動 / 自動化時,用 codex exec 明確指定權限

如果你想把 Codex 塞進腳本或 CI(跑完就結束、沒人在旁邊按 Enter),用非互動模式 codex exec。這種場合沒人能回答核准,所以你必須自己把權限講清楚:

# 在腳本裡讓它自動改檔,但關在沙盒內(不連網、不出資料夾)
codex exec --sandbox workspace-write --ask-for-approval never \
  "把所有 console.log 換成專案的 logger,跑一次測試確認沒壞"

重點:非互動就設 --ask-for-approval never(不然它會卡在等待核准),但一定要搭配夠緊的 --sandbox 當唯一防線。想接續上一段非互動任務,可以用 codex exec resume --last "接著把剛剛漏掉的那個檔也改了";想讓它做程式碼審查,有專門的 codex exec review --uncommitted(審你還沒 commit 的改動)。

codex exec 非互動流程:腳本呼叫 → 明確指定 sandbox 與 approval never → 沙盒內完成 → 回傳結果,適合 CI 自動化

常見坑

坑 1:一直被核准問題打斷,煩到不想用

你在 Auto,結果它每做一件小事都在問。多半是任務會頻繁越界(一直要連網、一直要碰專案外的檔),或者你其實停在更嚴的 untrusted。先用 /status 確認目前是不是 Auto;如果本來就是 Auto 還一直問,代表這個任務的本質就需要越界(例如要大量裝套件),那就先手動把套件裝好、或評估這個任務適不適合放給 AI,而不是無腦往更放權切。

坑 2:--full-auto 跑起來跳一行警告

warning: `--full-auto` is deprecated; use `--sandbox workspace-write` instead

這是舊教學的鍋。2026 年的 Codex 已經把 --full-auto 標為淘汰(deprecated),雖然還能動,但會叫你改用新寫法。看到這行不是壞掉,是提醒你:互動時直接用 /permissions 選 Auto,腳本裡用 --sandbox workspace-write --ask-for-approval never。跟著新寫法走就不會再看到它。

坑 3:開了 Full Access,結果它真的把不該動的東西動了

Codex is running with --dangerously-bypass-approvals-and-sandbox (no sandbox, no approvals)

看到這行紅字警告,代表你(或某個複製貼上的指令)開了 --yolo / --dangerously-bypass-approvals-and-sandbox。這模式下 AI 判斷錯了沒有任何東西攔它,連你的家目錄、SSH 金鑰、雲端憑證都在射程內。解法:除非在拋棄式容器裡,否則不要用。 需要它做危險操作時,寧可留在 Auto 一步步核准。已經誤開又改壞了?這就是坑 5 的 Git 派上用場的時候。

坑 4:非互動 codex exec 卡住不動,或直接失敗

在 CI / 腳本裡跑 codex exec 卻卡住沒反應,九成是你沒設 --ask-for-approval never——它遇到要核准的動作,停在那邊等一個永遠不會來的人回答。加上 never,並確認 --sandbox 設得夠嚴當防線。反過來,如果它報權限不足(要寫的檔在沙盒外),那是 --sandbox 太緊,評估後改成 workspace-write,但別直接跳 danger-full-access。

坑 5:讓 AI 動手前忘了 commit,改壞了回不去

最痛的坑,而且完全可以避免。你在 Auto 讓它改了一輪,發現整個方向錯了,想還原——結果動手前的狀態根本沒存過,git restore 只能還原到「更早的某次 commit」,把你這中間手動做的好東西也一起吃掉。鐵律:每次要放手讓 Codex 大改之前,先 git status 確認乾淨、或先 commit 一次當存檔點。 這個習慣救過的人比任何模式設定都多。

作業

找一個 Git 專案,依序體驗三個模式:用 codex --sandbox read-only 讓它讀懂並給計畫 → 在 TUI 用 /permissions 切到 Auto 讓它照計畫改 → 用 git diff 驗收。全程感受「它什麼時候會問、什麼時候自己做」。
故意觀察 approval 關卡:在 Auto 模式下給它一個需要連網或裝套件的任務,看它在越界前怎麼停下來問你,體會 on-request 的邊界在哪。
練 Git 安全網:讓 Codex 隨便改幾個檔,然後用 git restore . 全部還原,確認回到動手前一模一樣。把「動手前 status、動手後 diff、不滿意就 restore」變成肌肉記憶。
選做:寫一行 codex exec --sandbox workspace-write --ask-for-approval never "..." 跑一個明確的小任務(例如統一某種寫法),體驗非互動模式,並想想它適合放進什麼樣的自動化流程。

下一課預告

模式和權限搞定了,你已經知道怎麼安全地把手放開。接下來要進入 Codex 真正值錢的地方:用一句話讓它讀懂整個專案、跨多個檔案改東西、還自己跑測試驗證改對了沒。第 3 課會用一個實際的重構任務,帶你走完「講需求 → 讓它讀 → 它改 → 你用 diff 驗收 → 收工」的完整編輯工作流,把這堂學到的模式判斷,實際套進每天的開發節奏裡。