Codex淘汰untrusted核准政策：該改什麼

Codex CLI v0.149.0（穩定版，2026年8月20日）透過PR #39630「Retire the untrusted approval policy」（淘汰untrusted核准政策）淘汰了untrusted核准政策。¹ 該PR將untrusted從「the CLI, configuration schema, and MCP tool interface」（CLI、設定schema與MCP工具介面）中移除，明確寫出的approval_policy = "untrusted"現在會失敗，並給出「an actionable error」（可據以採取行動的錯誤）。⁴ 2026年8月25日在0.149.1上重現：不論這個值位於config.toml、profile檔案還是-c覆寫中，工作階段一啟動就會停在Error: approval_policy = "untrusted" is no longer supported; remove this setting，而codex執行檔在引數解析階段就拒絕-a untrusted。⁵ 把值改成on-request，沙箱模式保持不動；若要最謹慎的組合，請將--sandbox read-only與on-request搭配使用。³ 目前的政策集合是on-request、never，以及granular（細粒度）表格形式。² 內容以v0.149.1（2026年8月24日，UTC）為準，也就是目前npm的latest。¹ {.answer-block}

TL;DR

• 這次變更：v0.149.0的完整變更日誌列出PR #39630「Retire the untrusted approval policy」。版本說明除了這個標題之外沒有任何遷移說明；¹ PR描述則有：untrusted已從CLI、設定schema與MCP工具介面中移除，明確寫出的設定「now fail with an actionable error」（現在會失敗並給出可據以採取行動的錯誤）。⁴
• 誰必須動手：任何在~/.codex/config.toml或profile中寫有approval_policy = "untrusted"的人，以及任何在指令碼、別名或CI中傳入--ask-for-approval untrusted（或-a untrusted）的人。
• 替代值：on-request，沙箱模式不變。read-only加on-request就是文件中的「Safe read-only browsing」（安全的唯讀瀏覽）組合。² 舊的workspace-write加untrusted組合沒有直接的後繼者；逐指令詢問現在由exec policy規則（執行政策規則）負責。⁴⁸
• 目前的集合：on-request、never，或用於逐類別控制的approval_policy = { granular = { ... } }。沙箱模式仍是read-only、workspace-write與danger-full-access。²
• 快速失敗，而非靜默：殘留的approval_policy = "untrusted"會讓工作階段停在Error: approval_policy = "untrusted" is no longer supported; remove this setting，不論它位於config.toml、profile檔案還是-c覆寫中。codex doctor只回報設定無法載入，不會指出是哪個鍵。⁵

Codex 0.149改了什麼？

主要項目是幾個新介面，其中包括codex agents儀表板、codex queue，以及範圍更廣的codex doctor；核准政策的變更排在較後面，位於完整變更日誌中。¹ PR #39630的描述補上了版本說明遺漏的細節。它的三點裡有兩點與本文相關：「Remove untrusted from the CLI, configuration schema, and MCP tool interface. Explicit approval_policy = "untrusted" settings now fail with an actionable error.」（從CLI、設定schema與MCP工具介面中移除untrusted。明確的approval_policy = "untrusted"設定現在會失敗並給出可據以採取行動的錯誤。）以及「Remove the known-safe command allowlist. Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it.」（移除已知安全指令的允許清單。標記為untrusted的專案現在會對每一道指令請求核准，除非有明確的exec policy規則允許。）⁴ 同一版本中有一項錯誤修正對同一群讀者也很重要：「Resumed and forked threads now restore their active permission profile instead of silently falling back to current defaults.」（恢復與分支出來的對話串現在會還原其作用中的權限profile，而不是靜默退回目前的預設值。）¹

每一列都引自v0.149.0版本說明。¹

誰需要修改？

有四個地方會帶著這個值。先把它們全部找出來，因為在您修好主設定檔之後，profile或shell別名會再次套回舊政策。

舊式表格的失敗很明顯。在0.149.1上，當config.toml中仍有[profiles.safe]表格時，codex exec --profile safe "hi"會停在Error loading config.toml: --profile `safe` cannot be used while .../config.toml contains legacy `profile = "safe"` or `[profiles.safe]` config; move those settings into .../safe.config.toml ...，因此同事的--profile safe在Codex讀到核准值之前就已經失敗。⁵

每一側各一道grep：

# Config and profiles: match the key, not the bare word
grep -rnE 'approval_policy\s*=\s*"untrusted"' ~/.codex/*.toml .codex/config.toml 2>/dev/null

# Scripts, aliases, CI
grep -rn --exclude-dir=node_modules \
  -e "ask-for-approval untrusted" -e "ask-for-approval=untrusted" \
  -e "-a untrusted" -e "approval_policy=untrusted" \
  ~/.zshrc ~/.bashrc . 2>/dev/null

# CI directories: read every bare hit, because YAML can split a flag from its value
grep -rn --exclude-dir=node_modules "untrusted" .github .gitlab-ci.yml .circleci 2>/dev/null

第一道grep比對的是鍵而不是單獨的字，這是有原因的。trust_level = "untrusted"是另一個設定；請保留它。設定參考將projects.<path>.trust_level定義為標記「a project or worktree as trusted or untrusted」（專案或工作樹是否受信任）的鍵，而不受信任的專案會「skip project-scoped .codex/ layers, including project-local config, hooks, and rules」（略過專案範圍的.codex/層，包括專案本機設定、hooks與rules）。⁷ PR #39630改變的是不受信任的專案如何處理指令，而不是這個鍵：「Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it.」⁴ 盲目地對untrusted做尋找並取代，會弄壞這個鍵。

Profile檔案是文件記載的預設組合機制（~/.codex/<name>.config.toml，以codex --profile <name>選用），所以不論主設定檔怎麼寫，同事的profile都可能重新引入已淘汰的值。²

目前的核准政策集合是什麼？

Codex的安全性來自兩層：沙箱模式決定Codex在技術上能做什麼，核准政策決定Codex何時必須停下來詢問。² 這次淘汰只觸及第二層。

granular形式涵蓋五種詢問類別：sandbox_approval、rules（execpolicy詢問）、mcp_elicitations、request_permissions與skill_approval。² 沒有任何一種能重現untrusted，因為它是一條指令分類規則（自動執行已知安全的讀取，對任何可能變更狀態的操作詢問），而不是詢問類別的篩選器。²

workspace-write加untrusted，也就是文件中「Automatically edit but ask for approval to run untrusted commands」（自動編輯，但執行不受信任的指令前請求核准）那一列，沒有直接的後繼者。² workspace-write加on-request不再對沙箱內執行的指令詢問；read-only加on-request則對編輯與指令都會詢問。² PR #39630移除了「the known-safe command allowlist」（已知安全指令的允許清單），並點名了逐指令詢問僅存的機制：「Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it.」⁴ exec policy規則正是granular表格rules類別背後的同一套機制，也就是核准頁面所列的「execpolicy-rule prompts」。² 先前依賴untrusted來保護可寫入工作區的資安負責人，應該建立這些規則。rules文件將其範圍限定在沙箱之外執行的指令；decision = "prompt"的prefix_rule會「before each matching invocation」（在每一次相符的呼叫之前）詢問：⁸

# ~/.codex/rules/default.rules
prefix_rule(pattern = ["git", "push"], decision = "prompt")

唯讀沙箱仍是最直截了當的替代方案，直接封鎖任何變更。³

確切要改哪些地方？

對應關係只有一行：untrusted改為on-request，沙箱模式維持原狀。³

主設定檔（profile檔案的修改完全相同）：

# ~/.codex/config.toml (before)
approval_policy = "untrusted"
sandbox_mode    = "read-only"

# ~/.codex/config.toml (after)
approval_policy = "on-request"
sandbox_mode    = "read-only"

一段指令碼：

# before
codex --sandbox workspace-write --ask-for-approval untrusted "$@"

# after
codex --sandbox workspace-write --ask-for-approval on-request "$@"

-a/--ask-for-approval這對旗標屬於codex TUI執行檔。codex exec沒有這個旗標：在0.149.1上，codex exec --ask-for-approval untrusted "hi"會以error: unexpected argument '--ask-for-approval' found失敗。⁵ 對codex exec，請在設定中指定政策，或以行內方式傳入：

# non-interactive run, policy set inline
codex exec --sandbox workspace-write -c approval_policy=never "$@"

接下來是兩個需要判斷的問題。第一，在沒有人能回應詢問的環境中，互動式的codex執行檔在on-request下會卡在第一次核准；文件記載的非互動式組合是--sandbox read-only --ask-for-approval never，而codex exec --sandbox workspace-write是文件記載的非互動式進入點。² 第二，如果您先前把untrusted與danger-full-access搭配，用來達成「完整權限，但每次都問」，這個特性在換值之後不會保留。文件中on-request詢問的兩個例子是離開沙箱與使用網路，而danger-full-access會移除這兩個觸發條件。² granular表格其餘四個類別的詢問在完整權限下仍會觸發：decision = "prompt"的exec policy規則、MCP elicitation、skill核准，以及request_permissions詢問。²⁸ 選用的approvals_reviewer = "auto_review"設定會把符合條件的詢問交由審閱代理處理；它只適用於互動式政策，因此在遷移之後仍然可用。²

如何確認變更已生效？

1. 執行codex doctor。若已淘汰的值仍在設定中，它的config那一行會以✗ config config could not be loaded開頭，細節行則寫著· failed to load Codex config；doctor不會指出是哪個鍵出問題。帶有名稱的錯誤來自啟動codex或codex exec。doctor那一行乾淨，表示該值已經不在；若失敗，您仍得啟動一次工作階段才能看到是哪個鍵。⁵ 不論該值位於config.toml、以--profile選用的profile檔案，還是-c approval_policy=untrusted覆寫中，啟動錯誤都完全相同。⁵ 旗標形式在更早的引數解析階段就失敗：codex -a untrusted --version會印出error: invalid value 'untrusted' for '--ask-for-approval <APPROVAL_POLICY>'，後面接著[possible values: on-request, never]。⁵
2. 在暫用目錄中啟動一個用完即丟的工作階段並執行/status。它的Permissions那一行會顯示作用中的政策，on-request在那裡顯示為「Ask for approval」。⁵ /permissions開啟的是預設組合選單，而不是回報目前的模式，因此請改看/status。⁵ /status也會列出工作區目錄。²
3. 恢復一個較舊的對話串。PR #39153「Restore permission profiles when resuming threads」（恢復對話串時還原權限profile）現在會還原「the latest persisted approval policy, approvals reviewer, and active permission-profile ID when resuming or forking a thread」（恢復或分支對話串時，最後一次持久化的核准政策、核准審閱者與作用中的權限profile ID）。⁶ 持久化政策為untrusted的已恢復對話串尚未測試；在您實際開啟一個之前，請把這種情況視為未知。

關於文件本身有一點要注意。官方的「Agent approvals & security」頁面，在2026年8月24日擷取並於8月25日重新核對時，其組合表格仍然顯示--ask-for-approval untrusted，仍然保留以「With --ask-for-approval untrusted, Codex runs only known-safe read operations automatically」（使用--ask-for-approval untrusted時，Codex只會自動執行已知安全的讀取操作）開頭的那段文字，而且其config.toml範例仍然使用approval_policy = "untrusted"。² 設定參考的approval_policy條目在型別聯集中把untrusted列在第一位，其描述卻把另一個值標記為已淘汰：「on-failure is deprecated; use on-request for interactive runs or never for non-interactive runs.」（on-failure已棄用；互動式執行請用on-request，非互動式執行請用never。）⁷ PR與執行檔才是權威記錄；文件落後於它們。請不要把文件的範例區塊原樣複製到全新的0.149安裝中而不換掉那個值。

常見問題

在Codex中，什麼取代了approval_policy = "untrusted"？

approval_policy = "on-request"，現有的sandbox_mode保持不變。若要最謹慎的組合，請同時設定sandbox_mode = "read-only"。³

哪個Codex版本淘汰了untrusted政策？

v0.149.0，於2026年8月20日成為穩定版，透過完整變更日誌中的PR #39630。v0.149.1（2026年8月24日，UTC）是目前npm的latest。¹

如果我把untrusted留在config.toml裡會怎樣？

Codex會拒絕啟動工作階段。在0.149.1上，codex exec會停在Error: approval_policy = "untrusted" is no longer supported; remove this setting，profile檔案與-c approval_policy=untrusted會出現同樣的錯誤，而codex doctor只會回報設定無法載入。⁵ PR #39630將這個行為描述為失敗並給出「an actionable error」。⁴

on-request比原本的untrusted更不安全嗎？

在workspace-write之內，是的：untrusted會在任何可能變更狀態的指令之前詢問，而on-request執行沙箱內的指令時不會詢問。² 沙箱層能補回一部分餘裕：read-only不論政策為何都會封鎖寫入，而on-request在任何權限提升之前仍會詢問。³ 若要在可寫入的工作區上逐指令詢問，請撰寫exec policy規則，也就是PR #39630點名的機制。⁴⁸

我也需要更改沙箱模式嗎？

不需要。這次淘汰只影響核准政策；read-only、workspace-write或danger-full-access維持您原本的設定即可。³

重點整理

給個人開發者： - 在~/.codex/*.toml中grep approval_policy = "untrusted"（而不是單獨的字），把每一處改成on-request，並保留sandbox_mode與任何trust_level = "untrusted"不動。 - 執行codex doctor，接著在暫用工作階段中執行/status，再恢復一個舊對話串，看看0.149還原了什麼。

給維護共用profile與指令碼的團隊： - 在同一個commit中一併修正profile檔案、行內覆寫與config.toml；舊式的[profiles.<name>]表格會完全封鎖--profile，直到您把它移到~/.codex/<name>.config.toml為止。⁵ - 把無人值守的工作改成在codex執行檔上使用--sandbox read-only --ask-for-approval never，或改用codex exec --sandbox workspace-write -c approval_policy=never；互動式的codex執行檔在on-request下會卡在一個沒有人會回應的詢問上，而codex exec沒有--ask-for-approval旗標。⁵

給資安負責人： - untrusted分類規則（自動執行安全的讀取，變更時詢問）沒有granular的對應項；PR #39630為逐指令詢問指向exec policy規則（「unless an explicit exec policy rule allows it」），⁴ 寫法是在~/.codex/rules/default.rules中放一條decision = "prompt"的prefix_rule，⁸ 而唯讀沙箱則直接封鎖任何變更。 - 在審閱代理能代替人類處理符合條件的詢問之處，可以考慮approvals_reviewer = "auto_review"。

參考資料