Codex 0.130 后 /approvals 没了？别慌，权限开关都搬到启动参数了

发布时间: 2026-05-12

Codex OpenAI AI Agent CLI 权限 Sandbox Approval 开发工具

先说结论

如果你升级到 Codex 0.130.0（很多人会口头叫 Codex 0.130）之后，发现以前习惯在会话里用的 /approvals 不见了，不要急着回退版本。现在更稳定的做法，是在启动 Codex 时就把权限策略说清楚：用 --ask-for-approval 控制什么时候询问，用 --sandbox 控制命令能操作哪些文件，确实处在外部隔离环境里时，再使用 --dangerously-bypass-approvals-and-sandbox 一次性跳过确认和沙箱。这个长参数也可以直接写成 --yolo，更方便记忆和输入，也更接近 Gemini 等工具里常见的命名习惯。

换句话说，思路从“进会话后再临时切权限”，变成“启动前就选择运行档位”。这篇文章会把常用参数、推荐组合、风险边界和 shell alias 写法一次讲清楚。

本文只讨论公开的 Codex CLI 参数和通用工作流，不包含任何真实主机、内网地址、用户名、Token、私有路径或业务项目名。所有命令都用 <PROJECT>、<TASK> 这类占位符表示，你可以按自己的环境替换。

Codex approval control moved from slash command to startup flags

图 1：升级后的核心变化不是“不能调权限”，而是权限策略更适合在启动时确定。

1. 发生了什么：不是没权限了，是入口变了

很多人使用 Codex CLI 的习惯是这样的：先进入项目目录，执行 codex，等会话启动后再用 slash command 调整审批模式。旧版本里，某些环境可以通过 /approvals 或相近的权限入口，把“每次命令都问我”改成“更自动一点”。这很方便，尤其是长任务跑到一半才发现权限太保守时，不需要退出重开。

升级到 0.130.0 后，如果你发现 /approvals 不再可用，直觉上会觉得工具少了一个开关。但从 CLI 设计角度看，这个变化并不奇怪。权限、沙箱、工作目录、可写目录、联网能力这些东西，本来就是影响整个会话安全边界的启动级配置。它们越早确定，越容易审计；越晚在会话里临时切，越容易让人忘记当前到底处于什么权限状态。

所以解决方案不是去找一个隐藏的 /approvals 替代命令，而是把常用模式整理成启动参数。最直接的替代写法是：

codex --dangerously-bypass-approvals-and-sandbox

也可以写成更短的形式：

codex --yolo

这条命令的效果非常明确：跳过确认提示，并且不使用 Codex 自带的沙箱。它能解决“总是问我能不能执行”的痛点，但也带来最大风险。它适合运行在已经被外部隔离的容器、虚拟机、一次性开发环境、临时工作树里，不适合在主力机器、生产服务器、含有敏感文件的家目录里长期默认使用。

如果你只是想减少确认次数，不一定要上来就用这个危险开关。Codex 0.130.0 的帮助信息里已经把几个更细的旋钮暴露出来：

codex --ask-for-approval <policy>
codex --sandbox <mode>
codex --cd <DIR>
codex --add-dir <DIR>
codex --search

真正值得掌握的是这些参数的组合，而不是只记住一条“跳过所有限制”的命令。

2. 两个概念先分开：Approval 和 Sandbox 不是一回事

理解新参数时，最容易混淆的是 approval 和 sandbox。

Approval 解决的是“要不要问人”。比如 Codex 准备运行一个命令，是直接执行，还是弹出确认，还是只在它认为风险较高时才问。这影响的是交互频率。

Sandbox 解决的是“命令能碰到哪里”。比如命令只能读文件、只能写当前工作区，还是可以访问整个文件系统。这影响的是破坏半径。

这两个东西可以组合，但不能互相替代。--ask-for-approval never 只是说不要问你，不等于命令可以写任何地方；--sandbox danger-full-access 只是说不给文件系统沙箱，不等于所有确认提示都会消失。最粗暴的 --dangerously-bypass-approvals-and-sandbox 才是把两者同时放开。

Approval and sandbox are two different knobs

图 2：审批策略决定“问不问”，沙箱策略决定“能碰哪里”。

2.1 `--ask-for-approval`

--ask-for-approval 可以简写成 -a。在 0.130.0 的帮助信息中，常见取值包括：

参数值	含义	适合场景
`untrusted`	只对“不受信任”的命令询问，普通只读命令通常直接跑	新项目、陌生仓库、保守默认
`on-request`	由模型判断什么时候需要请求批准	日常交互开发，兼顾自动化和人工把关
`on-failure`	兼容旧逻辑的弃用模式，失败后再请求更高权限	老脚本兼容，不建议作为新习惯
`never`	不向用户请求批准，失败直接返回给模型	自动化、CI、外部已有控制的环境

这里要注意，never 听起来很爽，但它不是“安全自动驾驶”。它只是减少了人机确认。真正的安全边界还要看 sandbox、工作目录、系统用户权限、容器隔离、文件权限、Git 状态和你给 Codex 的任务范围。

2.2 `--sandbox`

--sandbox 可以简写成 -s。常见取值包括：

参数值	含义	适合场景
`read-only`	只读沙箱，适合分析和计划	让 Codex 看代码、解释日志、做 review
`workspace-write`	允许写工作区，限制在项目范围内	日常改代码、跑测试、生成文档
`danger-full-access`	不使用文件系统沙箱	容器、临时 VM、一次性环境、你非常明确知道后果时

如果你的目标只是让 Codex 能修改当前项目，workspace-write 通常比 danger-full-access 更合理。它给了 Agent 足够空间做事，又把误操作限制在工作区附近。只有当任务天然需要碰工作区外的系统资源，例如安装系统包、访问 Docker socket、管理服务、写多个目录，才需要考虑更高权限。

2.3 `--dangerously-bypass-approvals-and-sandbox` / `--yolo`

这是最容易被传播的一条命令，因为它最像 Claude Code 里“跳过权限确认”的体验：

codex --dangerously-bypass-approvals-and-sandbox
# 等价短写
codex --yolo

长参数的名字已经把风险写在脸上：dangerously；短参数 --yolo 则更适合日常输入和记忆，也方便与 Gemini 等命令习惯保持一致。两者指向的是同一类高权限模式：跳过所有确认提示，并且不使用沙箱。这样 Codex 就更像一个拥有当前用户权限的自动化操作者：你当前用户能删的文件，它理论上也能删；你当前 shell 能访问的凭据，它也可能通过命令间接触达；你当前目录外能写的地方，它也不再被 Codex 沙箱挡住。

所以我建议把它当成“外部隔离环境专用开关”，而不是个人电脑常驻默认值。比如：

已经在一次性容器里。
已经在临时 VM 或快照环境里。
已经在干净 git worktree 里，且没有挂载敏感目录。
任务需要系统级操作，且你愿意让外层环境承担隔离。
你已经确认当前目录没有私钥、Token、浏览器数据、生产配置、重要个人文件。

如果只是嫌确认太多，更推荐从下面这些组合开始。

3. 推荐组合：别只记一条危险命令

Recommended Codex launch combinations

图 3：权限给到刚好够用，通常比一次性全放开更稳定。

3.1 只读分析模式

适合第一次接触仓库、做代码审查、让 Codex 解释架构、排查日志但不希望它改东西：

codex -s read-only -a untrusted --cd <PROJECT>

这个模式下，Codex 更像一个高级阅读助手。它能看文件、总结结构、提出计划，但不应该直接修改项目。对于陌生仓库，这个模式很有价值，因为你可以先让它回答三个问题：这个项目怎么启动、主要风险在哪里、改某个功能可能影响哪些文件。

3.2 日常开发模式

适合大多数编码任务：

codex -s workspace-write -a on-request --cd <PROJECT>

这个组合允许 Codex 在工作区内修改文件、运行测试，同时保留一定的人工把关。它不会像只读模式那样束手束脚，也不会像全放开那样把风险扩散到整个系统。对普通 feature、bugfix、文档更新、单元测试补齐，这应该是最接近日常默认值的档位。

如果你希望更自动一点，可以把审批策略改成：

codex -s workspace-write -a never --cd <PROJECT>

但要记住：-a never 只是少问你，不是少风险。这个组合仍然应该配合干净的 Git 工作区、可回滚分支、明确任务范围和最后的测试验证。

3.3 外部隔离的高速模式

适合临时容器、一次性 VM、快照机、CI 任务或者非常明确的自动化场景：

codex --dangerously-bypass-approvals-and-sandbox --cd <PROJECT>
# 或者
codex --yolo --cd <PROJECT>

如果要跑非交互任务，也可以使用：

codex exec --dangerously-bypass-approvals-and-sandbox --cd <PROJECT> "<TASK>"
# 或者
codex exec --yolo --cd <PROJECT> "<TASK>"

这个模式最大的优点是流畅：不反复弹确认，不被沙箱限制。最大的缺点也正是流畅：做错事时没有内置刹车。因此我一般只在“外层已经可丢弃”的环境里用它，比如容器内部、临时分支、临时工作树、测试 VM。

3.4 需要联网搜索时

Codex 0.130.0 的帮助信息里还有一个 --search 参数：

codex --search -s workspace-write -a on-request --cd <PROJECT>

它用于启用实时 Web 搜索。这个开关和文件权限不是一类东西，但在实际任务中很常见：升级依赖、查官方文档、确认最新 API、排查新版本变化时，都可能需要联网。我的建议是：只有任务确实需要当前信息时再开，不要把“能搜索”当成所有会话的默认值。能从本地仓库、锁文件、帮助信息和官方文档缓存确认的事情，先用本地证据。

4. 把长命令变成 alias，比怀念 `/approvals` 更实用

如果每次都手敲完整参数，很快就会烦。更实际的做法是在 shell 里定义几个清楚的 alias 或函数。比如：

alias codex-ro='codex -s read-only -a untrusted'
alias codex-work='codex -s workspace-write -a on-request'
alias codex-auto='codex -s workspace-write -a never'
alias codex-yolo='codex --yolo'

然后按任务选择：

codex-ro --cd <PROJECT>
codex-work --cd <PROJECT>
codex-auto --cd <PROJECT>
codex-yolo --cd <PROJECT>

Use aliases as explicit Codex launch profiles

图 4：alias 的意义不是隐藏风险，而是把常用档位固定下来。

如果你经常在多个目录之间工作，--cd 很有用。它让 Codex 以指定目录作为工作根目录，不需要你先 cd 过去：

codex-work --cd <PROJECT> "修复测试失败并给出验证结果"

如果任务需要额外写另一个目录，可以使用 --add-dir：

codex -s workspace-write -a on-request --cd <PROJECT> --add-dir <EXTRA_DIR>

这比直接使用 danger-full-access 更精细。比如你希望 Codex 修改项目代码，同时把生成物写到一个临时输出目录，就可以只额外开放这个目录，而不是把整个系统都交出去。

5. `codex exec` 也有同一套思路

交互式 codex 适合边聊边做，codex exec 适合一次性任务和脚本化任务。它同样支持审批和沙箱参数：

codex exec -s read-only -a never --cd <PROJECT> "总结这个仓库的测试入口"

codex exec -s workspace-write -a on-request --cd <PROJECT> "补充缺失测试并运行验证"

codex exec --dangerously-bypass-approvals-and-sandbox --cd <PROJECT> "在容器内完成依赖升级并运行测试"
# 或者
codex exec --yolo --cd <PROJECT> "在容器内完成依赖升级并运行测试"

我建议在自动化脚本里优先显式写出 -s 和 -a，不要依赖默认值。脚本最大的敌人是“过几个月后没人记得当时默认是什么”。把策略写在命令行里，未来回看日志时就能知道这次任务到底是在只读、工作区可写，还是全权限模式下跑的。

如果需要机器可读输出，codex exec 还有 --json，可以把事件以 JSONL 形式输出：

codex exec --json -s workspace-write -a never --cd <PROJECT> "<TASK>"

这适合 CI 日志、自动化审计、后续解析。但请注意，不要把含有密钥、私有路径、生产域名的输出原样贴到公开 issue 或文章里。

6. 为什么不建议全局默认危险模式

很多人会问：既然 --dangerously-bypass-approvals-and-sandbox，也就是短写 --yolo，最省事，为什么不直接把它做成默认 alias？

原因很简单：AI Agent 的错误不是“会不会发生”，而是“发生时影响多大”。当它在 read-only 模式下理解错需求，最多给你一份错误分析；在 workspace-write 模式下理解错，可能改坏项目文件，但 Git 通常能救；在 danger-full-access 且没有审批的模式下理解错，它可能影响工作区外的文件、系统配置、缓存、凭据、服务状态和其他项目。

更关键的是，Agent 很擅长把任务扩大。你让它“修一个测试”，它可能决定先升级依赖；你让它“检查部署脚本”，它可能尝试运行发布；你让它“清理临时文件”，它可能误判哪些文件是临时的。大多数时候这不是恶意，而是自动化执行里的边界漂移。

所以，我更推荐四条原则：

默认用 workspace-write + on-request。
只读分析先用 read-only。
自动化可以用 workspace-write + never，但要有 Git、日志和可回滚环境。
--dangerously-bypass-approvals-and-sandbox 或 --yolo 只在外部隔离环境里用。

这套原则的核心不是保守，而是把风险放在正确的层：Codex 负责执行，Git 负责版本回滚，容器或 VM 负责系统隔离，人工负责关键决策。

7. 一个迁移清单：从 `/approvals` 习惯切到启动参数

如果你以前依赖 /approvals，可以按这个清单迁移：

先运行 codex --help 和 codex exec --help，确认当前版本支持哪些参数。
把旧习惯拆成两个问题：我想减少确认，还是想扩大文件访问范围？
为常用场景建立 alias：codex-ro、codex-work、codex-auto、codex-yolo。
对真实项目默认使用 codex-work --cd <PROJECT>。
对一次性容器或 VM 才使用 codex-yolo --cd <PROJECT>。
对脚本化任务显式写出 -s、-a、--cd，不要依赖记忆。
每次提高权限前先看 git status，确认当前工作区可回滚。
不把真实密钥、内网地址、私人路径写进提示词、日志、文章或公开 issue。

这样迁移后，你会发现 /approvals 消失并不一定是坏事。它迫使我们把权限策略前置，让每个会话从一开始就知道自己是“只读审查”“日常开发”“自动化执行”，还是“外部隔离里的全权限模式”。

8. 总结

Codex 0.130.0 之后，遇到 /approvals 消失，不要把它理解成权限功能消失。真正的替代方案是启动参数：

codex --dangerously-bypass-approvals-and-sandbox
# 等价短写
codex --yolo

但这只是最激进的方案。更值得长期使用的是：

codex -s read-only -a untrusted --cd <PROJECT>
codex -s workspace-write -a on-request --cd <PROJECT>
codex -s workspace-write -a never --cd <PROJECT>
codex --dangerously-bypass-approvals-and-sandbox --cd <PROJECT>
codex --yolo --cd <PROJECT>

如果你只记一句话：把 Codex 权限当成启动配置，而不是会话里的临时情绪按钮。
先选合适的权限档位，再把任务交给 Agent；这比一边跑一边找 /approvals 更清楚，也更适合长期维护。

参考来源

本文参数说明基于本机 codex-cli 0.130.0 的 codex --help 与 codex exec --help 输出整理。
OpenAI Help Center: OpenAI Codex CLI - Getting Started。
OpenAI Codex GitHub 仓库及公开 CLI 文档。