上一篇装好了 Codex，这篇讲一个直接决定使用安全感的机制——审批模式。
Codex 能读你的代码、改你的文件、跑你的命令。它到底能”自主”到什么程度，完全由审批模式决定。Codex 提供了三种模式：read-only（只读）、auto-edit（自动编辑）、full-auto（全自动）。
三种模式差别巨大，用错了轻则返工，重则出事。这篇文章把三种模式讲透，告诉你什么时候该用哪个、什么时候坚决不能碰哪个。
三种模式速览
read-only（只读模式）：Codex 只能读代码、分析代码、给出建议，不能修改任何文件，不能执行任何命令。它是”顾问”——你看它分析的结果，自己动手改。
auto-edit（自动编辑模式）：Codex 可以修改文件（改代码、创建文件），但执行命令前会请求你的批准。它是”编辑”——能帮你改文件，但跑测试、装依赖这类操作要你点头。
full-auto（全自动模式）：Codex 可以修改文件、执行命令，全程不需要你的批准。它是”代理”——把任务交给它，它自主完成，中间不打断你。
一句话记：read-only 是”只说不做”，auto-edit 是”能改要问”，full-auto 是”全权代理”。
read-only：最安全的默认模式
read-only 是 Codex 最保守的模式，也是很多场景下最应该用的模式。
适用场景：
- 理解陌生代码：接手一个不熟悉的项目，让 Codex 只读分析——“这个项目的入口在哪””这个函数的调用链是什么”。你只需要理解，不需要改动，read-only 最安全。
- 代码审查：让 Codex 审查你的代码，”看看这个 PR 有没有潜在问题”。审查是”读 + 判断”，不需要写操作。
- 方案咨询：”这个重构方案可行吗？有没有风险？”——咨询性质的任务，read-only 足够。
- 学习场景：跟着 Codex 学代码，让它解释每一步，你亲手敲。
为什么默认该用 read-only：对于”理解类”的任务，read-only 给了你 100% 的安全感——Codex 碰不了任何东西，你不用担心它误操作。当你只是想”问一问、看一看”时，read-only 是最合适的选择。
auto-edit：日常开发的默认选择
auto-edit 是”日常写代码”场景下最常用的模式——它能改文件，但执行命令要你批准。
适用场景：
- 日常功能开发：让它改代码，但跑测试、启动服务这些”有副作用”的操作要你批准
- 小范围重构：改函数、重命名变量、加类型注解——改文件的操作自动完成，你审查 diff
- 代码生成：让它写新文件、补全代码——文件操作自动完成，运行验证要你批准
auto-edit 的边界：它自动放行的是”改文件”（因为改文件有 diff 可审查，且可以 Git 回退），但”执行命令”要你批准（因为命令的副作用不可逆，比如 rm -rf、数据库操作）。这个设计很合理——文件修改是可逆的（Git 回退），命令执行可能不可逆（删库、改配置），所以命令要额外审批。
full-auto：最危险也最高效的模式
full-auto 是 Codex 的”全权代理”模式，全程不打断。高效，但风险最高。
适合 full-auto 的场景：
- CI/CD 集成：在 GitHub Actions 里跑 Codex 自动修 bug，没有人在旁边等着审批，只能用 full-auto
- 无人值守的批量任务：明确的、可重复的、风险可控的批量操作
- 对项目有充分信任 + 操作范围受限：你已经充分了解 Codex 会做什么，且它的操作范围被沙箱限制住了
坚决不用 full-auto 的场景：
- 不熟悉的项目：你都不知道项目里有什么，让 Codex 全自动跑，风险不可控
- 涉及生产环境：操作生产数据库、生产服务器、线上配置——full-auto 等于把删库的权利交给了 AI
- 不可逆操作：删除、覆盖、迁移数据——这些操作一旦执行无法回退，必须人工把关
- 对结果要求极高的任务：涉及金额、涉及合规、涉及上线发布——每一步都要人确认
一个铁律：full-auto 只用在”你完全清楚会发生什么、且后果可控”的场景。 不确定会不会出事，就别用 full-auto。
三种模式怎么切换
Codex 提供了两种切换方式：启动参数和对话内斜杠命令。
启动时指定模式：
# 以只读模式启动
codex --read-only
# 以全自动模式启动
codex --full-auto
# 默认启动（auto-edit）
codex
对话内切换（TUI 斜杠命令）：
# 在 Codex 对话中输入斜杠命令
/mode read-only # 切到只读
/mode auto-edit # 切到自动编辑
/mode full-auto # 切到全自动
# 查看当前模式
/mode
建议的切换策略：一个任务往往不是”从头到尾用同一种模式”，而是”理解阶段用 read-only，动手阶段用 auto-edit，收尾验证看情况”。灵活切换，而不是一上来就锁定某种模式。
沙箱安全机制：三种模式背后的底层保障
审批模式之外，Codex 还有一层更底层的安全机制——沙箱。不同平台用不同的沙箱技术：
macOS（Apple Seatbelt）：Codex 在 macOS 上通过 Apple Seatbelt（系统级沙箱框架）限制它的文件访问和网络访问范围。它会创建一个隔离的沙箱环境，Codex 只能访问授权范围内的文件。
Linux（Docker）：Codex 在 Linux 上推荐用 Docker 沙箱运行——把 Codex 放进容器里，限制它的文件系统访问和网络权限。容器里发生什么，都不会影响宿主机。
Restricted Token：Codex 执行命令时使用受限 Token，权限被压缩到”只够完成任务所需的最低权限”，防止 Codex 获得超出任务范围的权限。
这三层沙箱的意义：审批模式是”用户层面的把关”，沙箱是”系统层面的把关”。即使你在 full-auto 模式下忘了审批，沙箱也能兜底——Codex 能做的事情被系统层面限制住了，不会真正”失控”。
沙箱不是万能的：沙箱限制的是”访问范围”，不是”操作的正确性”。沙箱能防止 Codex 碰不该碰的文件，但防不住 Codex 在授权范围内做错事（比如改错代码逻辑）。所以沙箱 + 审批模式要配合使用，不能只依赖其中一层。
一个真实的工作流：三种模式配合
用一个”修复 Bug”的任务，展示三种模式的正确配合：
第一步：read-only 定位问题。用 read-only 模式启动 Codex，让它分析报错日志、读相关代码、定位 Bug 原因。这个阶段只需要”读”和”分析”，read-only 最安全。
第二步：auto-edit 修改代码。定位到问题后，切到 auto-edit，让它修改代码。改文件的 diff 你能看到、能审查，可以 Git 回退，所以放它自动改。
第三步：批准关键命令。改完代码，Codex 提议跑测试验证。因为测试命令有副作用（编译、执行），auto-edit 模式下需要你批准。你确认命令安全后批准。
第四步：决定是否 full-auto。如果这是一个”改了 5 个文件、要跑 10 条验证命令”的大任务，且你已经充分理解了每一步在干什么，可以在后半段切到 full-auto 让它一口气跑完。但如果你对其中任何一步不确定，保持 auto-edit 逐步审批。
总结这个工作流的精髓：理解阶段别让 Codex 碰东西，动手阶段让它改但看着它，收尾阶段看情况决定放不放手。 模式是动态的，不是静态的。
总结
三种审批模式，本质是”给 Codex 多大的自主权”：
- read-only：只说不做，理解类任务的默认选择
- auto-edit：能改要问，日常开发的默认选择
- full-auto：全权代理，只用在”后果可控 + 你完全清楚”的场景
配合底层的沙箱机制（Apple Seatbelt / Docker / Restricted Token），Codex 的安全体系是”用户审批 + 系统沙箱”双保险。用好这套体系的关键，是根据任务阶段动态切换模式，而不是从头到尾锁死一种。
下一篇开始进入实战——用 Codex 10 分钟读懂一个陌生代码库，全程用 read-only 模式，你会发现”只读”也能做很多事。
如果这篇文章帮你理解了三种审批模式的区别，欢迎分享给也在用 Codex 的朋友。你平时用哪种模式最多？评论区聊聊~
