Codex untrusted审批策略已退役：需要改什么

Codex CLI v0.149.0（稳定版，2026年8月20日）通过PR #39630“Retire the untrusted approval policy”（退役untrusted审批策略）退役了untrusted审批策略。¹ 该PR将untrusted从CLI、配置schema和MCP工具接口中移除（原文：“from the CLI, configuration schema, and MCP tool interface”），显式的approval_policy = "untrusted"现在会失败，并给出一条“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规则允许它。）⁴ 同一版本中的一项bug修复对同一批读者也很重要：“Resumed and forked threads now restore their active permission profile instead of silently falling back to current defaults.”（大意：恢复和分叉的线程（thread）现在会还原其活动的权限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”（一个项目或worktree标记为受信任或不受信任）的键，而不受信任的项目会“skip project-scoped .codex/ layers, including project-local config, hooks, and rules”（跳过项目范围的.codex/层，包括项目本地配置、hooks和规则）。⁷ 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来保护可写工作区的安全负责人应当编写这些规则。规则文档将其范围限定为在沙箱之外运行的命令；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 "$@"

随后有两个需要权衡的地方。第一，在没有人能回答提示的场景下，on-request之下的交互式codex二进制会卡在第一次审批上；文档化的非交互式组合是--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中grepapproval_policy = "untrusted"（而不是孤立的单词），把每处命中替换为on-request，sandbox_mode和任何trust_level = "untrusted"都不要动。 - 运行codex doctor，然后在临时会话中运行/status，再恢复一个旧线程，看看0.149还原了什么。

对于维护共享profile和脚本的团队： - 在修改config.toml的同一次提交中修复profile文件和内联覆盖；遗留的[profiles.<name>]表会彻底阻断--profile，直到您把它移到~/.codex/<name>.config.toml。⁵ - 把无人值守的任务改为codex二进制上的--sandbox read-only --ask-for-approval never，或codex exec --sandbox workspace-write -c approval_policy=never；on-request之下的交互式codex二进制会卡在一个无人回答的提示上，而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"。

参考资料