YOLO 危险模式：什么时候绝对不要绕过审批和沙箱
TL;DR
Codex CLI 的 --dangerously-bypass-approvals-and-sandbox，也就是 --yolo，会让 Codex 在没有审批、没有沙箱的情况下运行每个命令。官方 CLI 文档写得很直接：只应在外部加固环境中使用；codex exec 场景下也标注为 dangerous，并建议只在隔离 runner 中使用。它不是“更高效率模式”，而是把本地文件系统、网络、凭据、git 状态和外部副作用都交给 agent。团队默认应禁用或强约束该模式，确需使用时必须放在一次性隔离工作区、受限凭据、无生产网络、可销毁 VM 或容器里，并保留完整审计记录。
读者定位
本文面向已经熟悉 Codex CLI、希望加速批处理任务或在 CI/自动化中运行 Codex 的中高级开发者、平台工程师和技术负责人。你可能见过 --yolo，也可能在本地为了减少弹窗尝试过它。本文的目标不是制造恐惧，而是把风险说清楚：哪些任务不该用，哪些环境下可以有限使用，怎样建立替代方案。
问题：把交互摩擦全部拿掉，会把风险一起拿掉边界
日常使用 Codex 时，最烦人的体验往往是审批弹窗：装依赖要问，联网要问，写外部目录要问，运行不在 trusted set 的命令要问。--yolo 的诱惑在这里。它能让任务一路跑完，尤其在批处理、修复大量文件、跑脚本和 CI 场景里看起来省事。
但审批和沙箱不是 UI 摩擦，它们是状态变化前的最后防线。取消后，Codex 生成的任何 shell 都会带着当前用户的权限执行。它可以读 home 目录，改任意可写文件，访问网络，读取环境变量，运行包管理器脚本，调用云 CLI，推送 git，删除目录，触发外部系统。只要任务提示、网页内容、依赖脚本、仓库文件或模型推理出现问题，后果不再局限于当前工作区。
官方 CLI 文档把这个 flag 命名为 dangerously-bypass-approvals-and-sandbox，不是偶然。文档还在 flag combinations and safety tips 中建议：无人值守本地工作优先用 --sandbox workspace-write，避免绕过审批和沙箱，除非处在专用 sandbox VM；需要给更多目录写权限时，优先用 --add-dir，不要强行切到 full access。这些措辞说明官方也把它看成外部隔离场景的工具，而不是日常开发选项。
心智模型：YOLO 不是权限更宽，而是边界消失
可以这样理解三种模式：
read-only：默认观察，需要审批才能行动
workspace-write + on-request：工作区内行动，越界审批
--yolo：每个命令都按当前用户权限执行，不再由 Codex 沙箱和审批拦截
danger-full-access 已经很宽；--yolo 更直接地同时绕过审批和沙箱。它不只是把 approval_policy 改成 never，也不只是把 sandbox_mode 改成 danger-full-access，而是通过一个 flag 明确告诉 Codex：本次运行不需要这些保护。
在安全评估里，这意味着风险边界要外移。既然 Codex 内部不再拦截，就必须由外部环境承担：独立 VM、容器、临时用户、只读源码挂载、受限网络、无长期凭据、一次性 token、只允许访问镜像源、任务结束销毁。没有这些外部保护，--yolo 就是在开发者主机上运行一个能自由生成 shell 的 agent。
详细机制：它绕过了什么
它绕过审批
--ask-for-approval 的作用是控制 Codex 何时暂停让人批准命令。on-request 允许沙箱内自动执行，越界时提问；untrusted 对不在可信集合内的命令提问；never 不停下来。--yolo 直接绕过审批，意味着人不会在关键动作前获得停顿点。
审批不只是确认命令文本。它还给人机会判断任务语义：这次是否应该安装依赖，是否应该联网，是否应该写外部目录，是否应该推送，是否应该读某个文件。没有审批，模型的下一步推理会直接变成本地状态变化。
它绕过沙箱
沙箱本来定义 Codex 派生命令能访问哪些文件和网络资源。workspace-write 把写入限制在工作区内；read-only 阻止直接改文件；permission profiles 可以进一步限制敏感文件和网络域名。--yolo 取消这些边界。命令能做什么，取决于当前操作系统用户能做什么。
这也包括间接命令。npm install 会运行 package lifecycle scripts，make 可以调用任意 shell，测试脚本可以启动服务，Python 脚本可以读环境变量和网络。取消沙箱后，Codex 不需要显式生成危险命令，调用一个已有脚本也可能产生危险副作用。
它会放大 prompt injection 和供应链风险
Codex 会读取仓库内容、网页资料、issue 评论、PR 描述、日志和错误输出。任何这些输入都可能包含诱导性文字。正常沙箱和审批下，即使模型被诱导，越界动作也会被拦下或要求人确认。--yolo 下，这个缓冲减少。
供应链风险也类似。仓库里的脚本、依赖安装脚本、测试 fixture、生成器都可能含有副作用。平时你可能信任某个项目，但 --yolo 让所有脚本都获得当前用户的完整环境，风险范围比“当前仓库”大。
它会让审计更难
在交互模式里，审批提示本身是审计线索。谁批准了什么命令、为什么需要越界、命令是否被拒绝，这些都能帮助事后复盘。--yolo 省掉了这些节点。你只能依赖终端日志、Codex JSON 输出、shell history、git diff 和系统审计。如果没有提前打开日志，任务完成后很难还原每一步。
因此，任何允许 --yolo 的自动化，都应该配合 --json、--output-last-message、任务目录快照、网络日志或外部 runner 日志。否则它不仅风险高，也难以证明风险没有发生。
真实工作流案例：大规模文档格式修复
假设团队有 300 个 Markdown 文件需要统一标题和链接格式。有人想运行：
codex --yolo "Fix markdown formatting across the repository"
在开发者主机上，这个命令风险过宽。Codex 可能运行格式化脚本、改大量文件、删除临时目录、安装工具、访问网络查规则。更稳的流程是先用普通模式：
codex --sandbox workspace-write --ask-for-approval on-request
任务说明：
只修改 docs/ 下的 Markdown 文件。不要安装依赖，不要联网，不要删除文件。
先列出计划和受影响文件，再分批修改。完成后运行 ./scripts/check.sh all。
如果确实要无人值守批处理，可以把它放进外部隔离环境：
- 新建临时 VM 或容器，不挂载 home 目录。
- 使用一次性 clone，不包含生产
.env、SSH key、云凭据。 - 网络默认关闭，或只允许必要包仓库。
- 用只读 token 或无 token 环境。
- 运行
codex exec --json --output-last-message result.md --dangerously-bypass-approvals-and-sandbox ...。 - 任务结束后导出 patch，不直接推送。
- 销毁环境。
即使这样，也要把 prompt 写窄：
Only edit Markdown files under docs/. Do not install packages, do not access the network, do not modify git remotes, and do not delete files. Produce a patch and a summary.
外部隔离不是为了给模型“更自由”，而是把最坏结果限制在可丢弃环境里。
替代方案：不要为省审批直接开 YOLO
用 --add-dir 扩展可写目录
官方 CLI 文档建议，需要给 Codex 写更多目录时，优先用 --add-dir，不要强行 full access。比如一个项目需要同时改主仓库和 sibling package：
codex --sandbox workspace-write --ask-for-approval on-request --add-dir ../shared-lib
这比 --yolo 更可控，因为写权限只扩展到明确目录。
用 rules 降低重复审批
如果某些只读命令总是需要越界审批，可以用 rules 为具体前缀设置 allow 或 prompt，而不是完全取消审批。比如允许 gh pr view，但禁止 gh repo delete；允许 npm view，但对 npm install 保持 prompt。
用 profile 表达场景
为只读审计、日常开发、依赖维护分别建 profile，比临时切 --yolo 更稳定。profile 可以设置模型、web search、沙箱和权限边界。开发者启动时选择 profile，团队也能审查 profile 文件。
用 CI runner 做隔离
非交互任务可以跑在 CI 或临时 runner 里。即使使用 approval_policy = "never"，也应保留沙箱和受限凭据。CI 的价值不是“更适合冒险”，而是环境可复现、凭据可控、日志可留存、任务结束可清理。
操作清单：确需使用前的硬条件
- 是否在专用 VM、容器或隔离 runner 中运行，而不是开发者主机。
- 是否使用一次性 clone，且工作区不包含生产凭据、私有配置和无关仓库。
- 是否禁用或严格限制网络。
- 是否没有长期 SSH key、云凭据、包发布 token、数据库凭据。
- 是否禁止直接推送、发布、部署和数据库迁移。
- 是否记录完整命令、JSON 事件、最终摘要和 git diff。
- 是否任务结束后只导出 patch，不保留可变环境。
- 是否能销毁运行环境并重新创建。
- 是否有更小权限替代方案：
workspace-write、--add-dir、rules、profile、permission profiles。 - 是否有人对产物做人工审查。
团队可以把下面规则写进治理文档：
## Dangerous Mode Policy
- Do not run Codex with `--yolo` on developer machines.
- `--yolo` is allowed only in disposable isolated runners with no production credentials.
- The run must export a patch and logs; it must not push, publish, deploy, or migrate.
- Prefer `workspace-write + on-request`, `--add-dir`, profiles, and rules before considering dangerous mode.
权衡与风险
--yolo 的确能减少交互，特别是在大规模机械修改和自动修复场景里。但它把风险从 Codex 控制面转移到外部环境。没有外部隔离，它就是高风险本地执行。技术负责人应该评估的是“最坏情况下损失什么”，不是“这次模型看起来会不会犯错”。
在隔离 runner 中使用也不是零风险。它仍可能生成错误 patch、引入供应链依赖、修改许可证文本、删除测试、降低安全检查、产生难以审查的大 diff。隔离只限制外部损害，不保证代码质量。产物仍要走 review、测试和安全扫描。
还有组织风险。一旦开发者习惯 --yolo，团队会失去对 agent 行为的共同预期。新人会模仿老人的命令，CI 脚本会复制本地习惯，安全例外会变成默认流程。治理文档应把它列为例外，不列为快捷技巧。
常见误区
误区一：--yolo 只是少弹审批。它同时绕过审批和沙箱，影响文件系统、网络和所有派生命令。
误区二：我信任这个仓库，所以可以开。仓库脚本、依赖脚本、网页内容和模型推理都会参与任务。信任仓库不等于信任所有执行路径。
误区三：只要不让 Codex 推送就没事。本地文件、凭据、缓存、网络请求、外部 API 仍可能受影响。
误区四：CI 中用就安全。CI 也可能有发布 token、云凭据和生产网络。隔离 runner 必须配合最小凭据和网络限制。
误区五：用完检查 git diff 就够。git diff 只能看到仓库文件变化，看不到网络请求、外部系统变化、读取过的秘密和临时目录变化。
团队落地：把危险模式写成例外流程
如果团队决定允许极少数 --yolo 使用场景，就必须把它写成例外流程，而不是口头提醒。流程应回答五个问题：谁可以发起，运行在哪里，允许访问什么，产物如何审查，环境如何销毁。缺少任何一项，都不应批准。
发起人应提供任务说明和替代方案评估。比如为什么 workspace-write + on-request 不够，为什么不能用 --add-dir，为什么不能写 rules，为什么不能由 CI 普通 job 完成。很多“必须 yolo”的任务，拆开后其实只是需要多一个 writable root 或一次网络审批。例外流程会迫使团队先寻找更小权限方案。
运行环境应是可销毁的。理想情况是临时 VM 或容器，使用干净系统用户，挂载一次性 clone，不挂载 home 目录，不带生产凭据，不共享开发者 SSH agent。任务结束后导出 patch、日志和最终摘要，然后销毁环境。不要在开发者日常机器上运行，也不要在长期 CI runner 上留下状态。
访问范围要写明。网络默认关闭，确需打开时列出域名和方法。凭据默认不提供，确需提供时使用短期、最小权限、可撤销 token。文件系统只包含任务必要仓库和缓存目录。远端写入默认禁止。即使 --yolo 取消了 Codex 内部边界，外部运行环境仍要有边界。
产物审查不能省。危险模式生成的 patch 应像外部贡献一样审查：看 diff 是否越界，看测试是否真实运行，看依赖是否变化，看生成文件是否可追溯，看许可证和安全配置是否被改动。不要因为任务是 agent 自动完成，就降低 review 标准。
替代路线图：从小权限到外部隔离
面对一个需要更多自治的任务，可以按升级路线走。第一步，保持 workspace-write + on-request，要求 Codex 每次越界说明原因。第二步，如果只是多目录写入，使用 --add-dir 或 writable roots。第三步，如果只是重复审批，写细粒度 rules。第四步，如果需要特殊场景，建立 profile。第五步，如果需要无人值守，放进受限 CI runner。只有第六步，在外部隔离已经到位时，才考虑 --yolo。
这条路线能把“省事”转化为“减少不必要权限”。许多任务在第二或第三步就能解决。比如批量修改两个 sibling 仓库，不需要 full access，可以加第二个目录。比如查询 GitHub PR 评论，不需要 shell 任意联网，可以用连接器或 gh pr view 的受控规则。比如依赖升级，不需要全部网络，可以限定包仓库域名。这个判断过程要写进审批记录，方便事后复盘。
把路线写进文档后，审批人也有标准。有人申请 --yolo 时，先问是否试过前五步。没有试过，就退回。这样 --yolo 会自然保持稀少，不会因为方便而扩散。
事故复盘视角
评估危险模式时，可以从事故复盘倒推。假设任务出事了，你需要回答：Codex 读过哪些文件，运行过哪些命令，访问过哪些网络，使用过哪些凭据，改过哪些远端资源，生成了哪些产物，谁批准了运行，怎样回滚。如果当前方案无法回答这些问题，就不具备使用危险模式的条件。
普通模式下，审批、沙箱失败、rules、hooks 和命令记录会自然留下线索。危险模式下，这些线索减少，所以外部日志要更完整。建议运行时保存 JSON 事件、终端输出、最终摘要、git diff、依赖变更和网络策略。对高风险任务，还应保存运行环境镜像或构建清单，以便复现。
复盘还要区分仓库损害和环境损害。git diff 能恢复仓库文件，但恢复不了外部 API 调用、发布包、删除云资源、泄露 token、写入数据库。危险模式的风险评估必须覆盖环境损害，而不是只看代码 diff。
人的因素
危险模式最大的问题之一是习惯化。第一次使用时大家很谨慎，第二次觉得没事，第三次写进脚本，第四次新人复制。很多工程事故不是一次大胆决定造成，而是例外逐渐变成默认。技术负责人要避免把 --yolo 包装成效率技巧。它应在文档中被放在“外部隔离自动化”章节，而不是“常用命令”章节。
提示词也不能弥补环境风险。即使写了“不要删除文件，不要联网，不要读取密钥”，危险模式仍然让命令具备这些能力。模型可能误解，脚本可能有副作用，依赖可能有生命周期脚本，网页可能有诱导。安全设计不能建立在“模型会遵守提示”上。
最后，团队要允许开发者说“不需要 yolo”。在赶进度时，拒绝危险模式可能看起来拖慢任务。管理层应明确支持小权限流程，否则规范会被交付压力压垮。效率来自可复现和少事故，不来自把所有边界关掉。
危险模式评审问题
批准危险模式前，审批人应问十个问题。任务是否能拆成普通模式完成？是否需要写工作区外目录？是否需要网络？是否需要远端写入？是否带有长期凭据？是否有生产数据？是否能导出 patch 而不直接推送？是否能完整记录命令和输出？是否能销毁环境？是否有人负责最终 review？任意一个问题回答不清，就不应批准。
还要看任务输入来源。如果任务会读取网页、issue 评论、第三方 PR、未知依赖或外部日志，危险模式风险更高，因为这些输入可能影响模型行为。外部输入越多，越需要沙箱和审批，而不是越应该绕过。危险模式更适合机械、封闭、输入受控的任务，例如在一次性 clone 中按固定规则改文档格式；不适合处理不可信外部内容。
审批人还应要求回滚计划。仓库文件可以回滚，外部状态不一定。发布包、推送分支、触发部署、写数据库、修改云资源，都可能需要专门回滚。危险模式任务如果可能触发这些动作，应直接拒绝或改成人工执行。Codex 可以生成命令和检查清单，但不应该在无边界环境里执行。
安全文档中的表述方式
团队文档不要把 --yolo 写成“快速模式”。这个名字会影响使用习惯。建议使用“危险模式”“无沙箱无审批模式”或“外部隔离自动化模式”。文档中的示例也不要给开发者主机命令，而应给隔离 runner 流程。命令示例如果必须出现，要带上前置条件，例如“仅在一次性容器中运行”。
内部培训也要说明官方 flag 名称为什么带有 dangerously。这不是保守措辞，而是告诉用户该选项改变了安全模型。让开发者理解这一点，比单纯禁止更有效。禁止没有解释，遇到紧急任务时会被绕过；解释清楚风险，开发者更可能选择小权限替代方案。
安全文档还应列出绝对禁止场景：开发者主机、包含生产凭据的环境、可访问内网的 VPN 环境、发布流程、数据库迁移、云资源修改、第三方不可信仓库、客户数据处理。这些场景不需要逐次讨论，默认拒绝。
最低通过标准：危险模式产物只能是待审 patch
即使在隔离环境中使用危险模式，最终产物也应只是待审 patch、日志和摘要，而不是已经推送的分支、已经发布的包或已经修改的外部系统。这个标准把风险限制在代码审查阶段。人类 reviewer 仍然有机会拒绝、拆分、重跑测试或要求重新生成。
如果一个危险模式任务必须直接改变外部状态，说明它不适合交给 Codex 自动执行。Codex 可以帮助生成命令、写 runbook、列检查项，但最终动作应由授权人员在正式流程里完成。把这个边界写清楚，团队才能在使用自动化时保留责任链。
危险模式还应有时间边界。一次运行对应一个任务，一个任务结束环境就销毁。不要把配置保存在默认 profile，不要把命令写进常用别名，不要让 runner 长期存活。时间越长，环境漂移和凭据暴露的概率越高。短生命周期是外部隔离的一部分。
最可靠的治理信号是使用频率。如果一个团队每周都需要危险模式，问题通常不在 Codex，而在脚本、权限设计或自动化平台。应回头修小权限流程，而不是把高风险模式正常化。
发布前复核
发布前再确认全文没有把危险模式写成效率技巧。它只能作为外部隔离自动化的例外路径。
延伸阅读
GitHub 原文：22-yolo-dangerous-mode.md