共计 5065 个字符，预计需要花费 13 分钟才能阅读完成。
最近在用 Codex 的时候，注意到它和 Claude Code、Gemini CLI 这些 AI 编程助手一样，都提供了某种「自动执行」模式。Claude Code 有 --dangerously-skip-permissions 这样简单粗暴的参数，Gemini CLI 更是直接叫 --yolo（You Only Live Once 的缩写，看到这名字就知道有多激进了）。一开始我以为 Codex 也会是类似的思路，要么问你每一步，要么完全放飞自我。但实际上手后才发现，Codex 在这方面做得更细致一些，它把「自动执行」这个需求拆成了两种模式：--full-auto 和 --dangerously-bypass-approvals-and-sandbox。这两个名字看起来都挺长的，但背后的设计思路还挺有意思，值得聊一聊。
说实话，刚开始接触这些 AI 编程工具时，我和大多数开发者一样，觉得那些频繁的权限询问确实有点烦。你让 AI 帮你改个代码，它每改一个文件都要问一句「可以吗」，这种体验确实不够流畅。但后来在一次差点把系统配置文件搞乱的经历之后，我才真正意识到，这些看似繁琐的提示，其实是在保护我们不被 AI 的「创造力」带偏。所以当我看到 Codex 提供了两种不同层级的自动化选项时，第一反应是：这个设计挺符合实际使用场景的。接下来我就从实际使用的角度，分享一下这两种模式的区别，以及我在什么情况下会选择用哪一种。
两种模式的本质区别
在深入细节之前，我们先用最简单的方式理解这两种模式的核心差异。--full-auto 可以理解为「自动化但仍然受控」，它让 AI 在你的项目范围内自由发挥，但一旦涉及到工作区之外的文件或网络访问，它还是会停下来问你一句。而 --dangerously-bypass-approvals-and-sandbox（别名是 --yolo，后面我就简称 yolo 模式了）则是彻底的「放飞自我」，它会跳过所有的权限检查和沙箱限制，直接执行 AI 的所有操作。
从技术实现上看，--full-auto 实际上是两个底层参数的组合：--sandbox workspace-write 和 --ask-for-approval on-request。前者定义了一个沙箱边界（只能写工作区内的文件），后者设定了审批策略（特定情况下才需要批准）。这种组合设计的好处是，它在「自动化效率」和「安全控制」之间找到了一个比较合理的平衡点。我在日常开发中基本上都是用这个模式，因为它能处理大部分场景，同时又不会让我担心 AI 会不会突然去改 /etc/hosts 或者访问一些不该访问的网络资源。
相比之下，yolo 模式就是另一个极端了。它的参数名里带着「dangerously」（危险地）这个词，其实已经在警告你了。这个模式下，Codex 不会有任何沙箱限制，也不会问你任何问题，它会完全信任 AI 的判断并执行所有操作。OpenAI 官方文档里明确写了「需要谨慎使用，不推荐」，这可不是随便说说的。我自己只在 Docker 容器或者专门用于测试的虚拟机里用过这个模式，而且用完马上就关掉。在自己的主力开发机上，我是绝对不会开启这个模式的，风险太大了。
日常开发的最佳拍档：full-auto 模式
让我们先聊聊我最常用的 --full-auto 模式。这个模式的设计理念其实很符合大部分开发者的工作习惯：在项目范围内，我希望 AI 能自由发挥，不要每次都来问我；但一旦涉及到项目之外的东西，比如系统配置文件或者网络请求，那还是让我自己做决定比较好。
具体来说，在 full-auto 模式下，Codex 可以自动完成这些操作：自动读取和编辑工作区内的所有文件、自动运行工作区内的命令、在大多数常规开发场景下无需人工确认。这些能力已经足够应对日常开发的大部分需求了。比如我让它帮我重构一个模块，它可以自由地修改模块内的多个文件，运行测试命令，甚至帮我格式化代码，整个过程都不需要我一步步确认，体验上非常流畅。
但是，这个模式也有明确的边界。当 Codex 尝试编辑工作区外的文件时（比如你的 .zshrc 或者其他全局配置），它会停下来问你：「这个文件不在项目范围内，确定要修改吗？」同样，如果它需要访问网络资源（比如下载依赖包或者调用外部 API），也会先征求你的同意。这种设计让我在享受自动化便利的同时，依然保持对关键操作的控制权。我觉得这个平衡点把握得挺好的，既不会过于保守导致频繁打断，也不会过于激进让人担心安全问题。
有一次我在用 Codex 帮我配置一个新项目的开发环境，它需要修改项目根目录的配置文件，同时也建议我更新全局的 npm 配置。在 full-auto 模式下，它自动完成了项目配置的修改，但在尝试改全局配置时弹出了确认提示。我看了一眼它的建议，发现确实有必要更新，就批准了。这个体验让我觉得很舒服：常规操作不打扰我，关键决策让我参与。
谨慎使用的极限模式：yolo 的适用场景
现在说说 --dangerously-bypass-approvals-and-sandbox 这个 yolo 模式。这个模式的名字已经充分表达了它的特点：危险地跳过审批和沙箱。在这个模式下，Codex 会获得完全的系统访问权限，不会有任何限制，也不会有任何提示。听起来很爽对吧？但实际上，这种「爽」是有代价的。
我只在两种情况下会考虑使用这个模式。第一种是在 Docker 容器里做实验，反正容器可以随时销毁重建，就算 AI 把系统搞崩了也无所谓。第二种是在专门的测试虚拟机上，用来验证一些比较激进的自动化脚本。除了这两种隔离环境，我不会在任何「有价值」的环境里使用 yolo 模式，包括我的开发机、测试服务器，更不用说生产环境了。
之所以这么谨慎，是因为我曾经见过一个同事在本地开发环境里开启了类似的「完全放飞」模式，结果 AI 助手在尝试「优化」系统性能时，把一些关键的系统配置文件改乱了，导致他花了半天时间才恢复环境。虽然那次没有造成数据丢失，但浪费的时间和带来的挫败感是实实在在的。从那以后，我对这种「无限制」模式都保持高度警惕。
OpenAI 官方文档里也特别强调了这一点：「使用 --dangerously-bypass-approvals-and-sandbox 需要谨慎，不推荐使用。」这可不是官方的保守态度，而是基于实际风险的合理建议。如果你真的需要高度自动化的 AI 执行环境，最佳实践是在 Docker 容器或虚拟机这样的隔离环境里使用，而不是直接在主力机上开启。
实际使用中的典型场景对比
为了更直观地理解这两种模式的差异，我举几个实际开发中常见的场景。这些都是我在使用 Codex 时真实遇到过的情况，可能也是很多开发者会碰到的。
第一个场景是编辑系统配置文件。假设 AI 建议你修改 /etc/hosts 来解决某个开发环境的域名解析问题。在 full-auto 模式下，当 Codex 尝试修改这个文件时，它会停下来问你：「这个文件在工作区之外，需要批准才能修改。」你可以查看它的修改建议，确认无误后再批准。而在 yolo 模式下，Codex 会直接修改这个文件，完全不会问你。听起来效率很高，但如果 AI 的判断有误，或者你其实不希望改这个文件，那就来不及阻止了。
第二个场景是网络访问。比如 AI 决定帮你安装一个新的依赖包，需要从 npm 仓库下载。在 full-auto 模式下，它会先告诉你「需要访问网络下载依赖，是否允许？」你可以检查一下它要安装什么，确认没问题再继续。而在 yolo 模式下，它会直接开始下载和安装，不会有任何提示。如果你对依赖的安全性比较在意（比如担心供应链攻击），这种静默安装就会让你失去把关的机会。
第三个场景是批量修改文件。假设你让 AI 帮你重构整个项目的代码结构，涉及几十个文件的修改。在 full-auto 模式下，只要这些文件都在项目工作区内，AI 可以自动完成所有修改，效率很高。但如果中途它发现需要修改一个全局配置文件（比如 .gitignore_global），就会停下来征求你的意见。而在 yolo 模式下，它会把项目文件和全局配置一起改了，完全不会停顿。表面上看起来更流畅，但实际上失去了对全局配置的控制。
通过这些对比可以看出，full-auto 模式的设计逻辑是「信任但验证」：在安全边界内（工作区）信任 AI 的判断，但一旦越界就需要人工验证。而 yolo 模式则是「完全信任」：无条件执行 AI 的所有操作。对于大部分开发场景来说，full-auto 模式提供的自动化程度已经足够了，而且它保留的那些「边界检查」，往往能在关键时刻救你一命。
更灵活的配置：只想关闭审批怎么办
在实际使用中，我发现有些开发者其实不需要「完全放飞」，他们只是觉得权限询问太频繁，想减少打断。如果你也有这种需求，其实不必直接跳到 yolo 模式，可以通过更细粒度的参数配置来实现。
Codex 允许你单独调整审批策略，而不必同时取消沙箱保护。比如你可以用这个命令：codex --sandbox workspace-write --ask-for-approval never。这个配置的效果是：沙箱边界依然存在（AI 不能修改工作区外的文件），但在沙箱范围内，它不会再频繁询问你的批准。这样一来，AI 可以在项目范围内自由操作，但依然无法越过沙箱边界去改系统文件或访问网络。
我自己在处理一些比较简单的项目时会用这个配置。比如做一些纯粹的前端页面调整，不涉及外部依赖和系统配置，这时候让 AI 在项目内自由发挥，可以大大提升效率，同时也不用担心它会「手伸太长」。这种配置方式的好处是，你可以根据具体项目的特点，灵活调整自动化的程度，而不是只能在「全问」和「全不问」两个极端之间选择。
一份简单的使用建议
基于我这段时间使用 Codex 的经验，我整理了一份针对不同场景的使用建议，希望能帮你更好地选择合适的模式。
对于日常开发工作，我的建议是默认使用 --full-auto 模式。这个模式在自动化和安全性之间找到了一个很好的平衡点，既能让你享受 AI 带来的效率提升，又不会让你担心出现意外的系统修改。无论是写新功能、重构代码，还是做日常的 bug 修复，这个模式都能很好地满足需求。
如果你在 CI/CD 流水线里使用 Codex，也可以考虑 --full-auto 模式，因为 CI 环境通常是相对隔离的，而且有明确的工作区边界。不过如果你的 CI 环境是完全容器化的，并且每次都是全新启动的容器，那用 yolo 模式也问题不大，毕竟容器跑完就销毁了，没什么持久化的风险。
至于 --dangerously-bypass-approvals-and-sandbox 这个 yolo 模式，我的建议是只在 Docker 容器或专门的测试虚拟机里使用。如果你要做一些激进的实验，或者测试一个可能会影响系统配置的自动化脚本，在这种随时可以重置的隔离环境里用 yolo 模式是没问题的。但千万不要在你的主力开发机上开启这个模式，更不要在任何生产环境或者包含重要数据的服务器上使用。
有些开发者可能会想，反正有 Git 版本控制，就算 AI 改乱了也能回滚，所以用 yolo 模式应该没事吧？这个想法有一定道理，但别忘了 yolo 模式不只是会改项目文件，它还能改系统配置、安装软件、访问网络。这些操作可不是 Git 能管得到的。所以还是那句话：能用沙箱就别关，能用审批就别关。
最后
回顾这段时间使用 Codex 的经历，我觉得它在自动化执行这个功能上的设计思路是值得肯定的。不同于一些 AI 工具简单粗暴的「全开全关」设计，Codex 提供的 --full-auto 和 --dangerously-bypass-approvals-and-sandbox 两种模式，实际上代表了两种不同的使用哲学：前者是「在安全边界内尽可能自动化」，后者是「完全信任 AI 并承担风险」。
对于绝大多数开发者来说，--full-auto 模式已经能够提供足够的自动化体验，而且它保留的那些关键检查点，往往能在你不注意的时候保护你免受意外修改的困扰。我现在的习惯是，日常开发全程用 full-auto，只有在 Docker 容器里做实验时才会短暂开启 yolo 模式，而且用完立刻关掉。这种谨慎态度可能看起来有点保守，但在经历过几次「差点出事」的惊险时刻后，我觉得这种保守是值得的。
最后想说的是，AI 编程助手确实很强大，但它终究还是工具，不是魔法。合理使用工具，设置恰当的边界，才能让它发挥最大价值，同时避免不必要的风险。希望这篇文章能帮你更好地理解 Codex 的这两种自动执行模式，也希望你能找到最适合自己工作习惯的配置方式。记住：能用沙箱就别关，能用审批就别关，这是我用血泪经验换来的教训，分享给你。
