想让 Codex 自己把活干完：改文件、跑命令、持续推进，不必每一步都等你点确认？不少人打开了“Full Access”，却发现它照样频繁弹出审批。问题不在于设置没生效，而是权限机制比看上去多一层。下面先给出结论：本文基于 Codex CLI v0.145.0 实测，说明怎样真正做到全程免干预。
根本原因：Codex 的“自动模式”并不是一个总开关，而是由两套彼此独立的控制组成：沙箱决定它能碰什么，审批策略决定它何时必须停下来问你；网络访问还是第三道独立关卡。放开其中一项，并不会自动放开另外两项；而且 Codex 更新后，当前会话还可能被悄悄重置回默认策略。
CLI 下彻底免干预：--yolo 是唯一能一次撤掉所有关卡的参数。若想保留沙箱以降低风险，就需要明确设置这两个维度。务必在会话一开始就设好，更新后也要重新检查。
# 真正免干预：无沙箱、无提示（仅限一次性环境）：
codex --yolo
# 更稳妥：可在项目内自由修改，离开项目范围时仍会询问：
codex --sandbox workspace-write --ask-for-approval on-request应用内彻底免干预：打开审批菜单，选择 Full access；每次更新后都要重新选择，因为升级会重置该模式。
以上是速览。接下来会完整梳理各个模式、它们在底层分别对应什么，以及不同场景该选哪一种。
三种模式到底差在哪
沙箱规定代理可访问的范围，例如文件和网络；审批策略则规定它什么时候要停下来征求同意。所谓自动模式，本质上只是这两者的组合。桌面应用和 CLI 对同一组组合使用了不同名称。
| 应用内名称 | 实际行为 | 对应 CLI 设置 |
|---|---|---|
| Ask for approval | 可修改工作区文件、执行常规本地命令；访问互联网或工作区外内容前会询问 | sandbox_mode = "workspace-write" + approval_policy = "on-request" |
| Approve for me（当前应用默认值） | 边界与前者相同，但可交由 AI 审核器处理的审批请求不再由你决定（即 Auto-review） | 前述设置 + approvals_reviewer = "auto_review" |
| Full access | 没有沙箱、没有审批提示，文件和网络均不受限制 | sandbox_mode = "danger-full-access" + approval_policy = "never" |
如果你主要使用 CLI，可以直接通过 --sandbox 和 --ask-for-approval 设置它们，也可以在会话中用 /permissions 选择预设。至于是否还在 Codex 与其他客户端之间犹豫，那是另一个问题；我们在这里比较过 Codex 和 Claude Code。本文只讨论权限设置本身。
为什么开了“Full Access”还会弹审批
通常有三个原因，而且可能同时存在。
沙箱与审批是两条独立的轴。workspace-write + on-request 允许 Codex 在项目内自由编辑，但一旦触及边界就会停下：发起网络请求、访问仓库外文件、执行 sudo。即使你放宽了沙箱，只要审批仍是 on-request，跨越边界时依旧会收到提示。
网络访问另有一道门。即便是 Full Access，互联网访问也可能与文件系统权限分开控制。正如 @mxcl 在 2026 年 7 月 16 日所说，Codex “cannot use the Internet without full access, ending task until the user enables full access.” 文件写入权限和网络权限并不是一回事。
更新会重置模式。2026 年 7 月下旬，多位用户都遇到了这个问题：升级 Codex 后，活跃会话会被悄悄切回默认策略。@s_rafcon 在 7 月 22 日提到，线程会“switch their Full access flag to the default flag and [are] stuck asking for approval on every single edit.” 因此，应在每次会话开始时设置模式，并在每次更新后重新确认。
CLI 里的 --full-auto 已移除，该用什么替代
codex --full-auto 曾是“在我的项目里工作、不要反复问我”的快捷方式，对应 approval_policy = "on-request" + sandbox_mode = "workspace-write"。如今交互式命令已不再接受该参数。v0.145.0 实测如下：
$ codex --full-auto
error: unexpected argument '--full-auto' found现在应显式设置两个维度，效果与旧参数完全一致：
# --full-auto 的现代替代写法
codex --sandbox workspace-write --ask-for-approval on-request
# 或者：非交互执行、不弹提示，但保留沙箱：
codex -a never -s workspace-write exec "your task"用于脚本时，codex exec --full-auto 仍然接受这个参数；报错的只有交互式命令。根据 codex --help，--ask-for-approval 可取 untrusted / on-request / never，而 --sandbox 可取 read-only / workspace-write / danger-full-access。应用里的每一种“模式”，都是这两个选项的一组搭配。
--yolo：何时该彻底放开限制
--yolo 是 --dangerously-bypass-approvals-and-sandbox 的简写。它才是真正的“无需看管”开关：启用 danger-full-access 加 never，既没有文件系统边界，也没有审批关卡。--full-auto 被移除后它仍得以保留，正是因为这个名字已经直接表明风险：在 v0.145.0 中，codex --yolo 可以正常解析，而 codex --full-auto 会报错。
许多经验丰富的用户会默认使用它；在合适的任务中，这么做确实合理。前提是环境本身就是你的安全边界，也就是说要把机器当作一次性资源：
- 在临时 VM 或开发容器中运行，不要在日常主力电脑上执行。
- 先从环境中移除生产凭据。
- 任务范围要收紧，继续之前先检查
git diff。
--yolo 会撤掉所有关卡，因此误执行的 rm -rf、git push 或 DROP TABLE 都不会再征求确认——这就是换取速度的代价。（通过自定义模型提供商把 Codex 指向自托管端点或 Anthropic-compatible endpoint，并不会改变这一点；沙箱不在乎 API 背后是哪一个模型。）
“Approve for me” / Auto-review：让 AI 替你审批
最新的模式、也是当前应用默认模式，是 Auto-review。符合条件的升级请求会交给一个独立的审核代理：一个运行 GPT-5.4 Thinking (low) 的轻量 Codex。OpenAI 将其定义为“审核者替换，而非权限授予”：它不会扩大可写目录，也不会开放网络，只是改变了谁来批准。
根据 OpenAI 在 2026 年 4 月 30 日发布的评估，与手动审批相比，Auto-review 需要人类介入暂停的频率大约低 200 倍；它会批准约 99.1% 的已审核升级请求，按全部操作计算则为 99.93%。在其给出的 10,000 次操作示例中，9,280 次直接在沙箱内完成，720 次进入审核器，只有 7 次被拒绝。
它也设有防止连续拒绝失控的保护机制：连续 3 次拒绝后会中断当前轮次；或者在最近 50 次审核构成的滚动窗口中，累计 10 次拒绝后中断。被它拦下时，可运行 /approve 打开 Auto-review Denials 选择器，为某项操作放行并重试。
问题在于，这些安全检查可能拖住长时间任务。2026 年 7 月下旬，进行数小时 /goal 任务的用户反馈，周期性出现的“keep waiting?”提示打断了原本可以无人值守运行数天的工作流。OpenAI 也明确表示，它“should not be treated as a guarantee of security”：红队测试的召回率虽高但并不完美，分别为 90.3% overreach、99.3% prompt injection、96.1% misaligned-model。它适合作为默认选择，却不能替代高风险工作中的沙箱。
如果不想通过 UI，而是希望在配置中开启，可这样写：
approvals_reviewer = "auto_review"
[auto_review]
policy = """
Describe what the reviewer should allow or block here.
"""实际该选哪种模式
- 日常本地开发：
workspace-write+on-request（“Ask for approval”）。项目内可以正常推进，任何离开仓库边界的动作仍由你最终决定，而真正严重的风险通常就在这里。 - 长时间无人值守任务：“Approve for me”（Auto-review）。但要知道，它仍会在标记出的操作处暂停，因此并非完全零介入。
- 一次性环境中的杂活：
--yolo。速度最快，风险也最大，只有在环境本身不怕被破坏时才适合使用。 - 阅读或审查代码库：
read-only。不能写入，也不会有意外修改。
说到底，不存在一个既完全自主、又绝对安全的设置。每多放开一步，都是用你自己的判断换取分类器的判断。处理常规工作时，这笔交换往往划算；面对生产基础设施时，则很可能并不明智。应当按任务选择，而不是一次设定后永久不变。
FAQ
Codex 有自动模式吗？
有，但它是一组预设，而不是单一开关。应用内的“Ask for approval”、“Approve for me”和“Full access”都属于自动模式；CLI 中则通过 --sandbox 与 --ask-for-approval 组合出相同行为，也可以使用 /permissions。
怎样让 Codex 自动批准所有命令？
将 approval_policy = "never"。配合 workspace-write 时，它会停止在沙箱内弹出提示；配合 danger-full-access 时，也就是 --yolo，它会彻底停止所有提示。后者会移除全部防护，因此只能在隔离环境中使用。
Codex 的 auto-review 模式是什么？
Auto-review（approvals_reviewer = "auto_review"，在应用中显示为“Approve for me”）会将审批决定交给 AI 审核代理，而不是由你亲自处理。它会批准其审核内容中的约 99%，让人类暂停介入的频率约低 200 倍，但这并不构成安全保证。
--full-auto 现在还能用吗？
交互式 CLI 中不能。v0.145.0 实测，codex --full-auto 会返回“unexpected argument”。但 codex exec --full-auto 仍可作为面向脚本的废弃别名使用。交互式使用请改为设置 --sandbox workspace-write --ask-for-approval on-request。
--yolo 模式安全吗？
不安全，这正是它名字的含义。它会同时禁用沙箱和全部审批。只有在移除了生产凭据、任务范围明确的一次性 VM 或容器中，才算是合理的选择。