从权限模型看 Codex 与其它编程 agent 的差别：选型前该问清楚的五个维度

2026-08-09

选编程 agent 的时候，大部分对比文章都在比”谁写的代码更好”。这个维度我没法诚实地帮你比——本文的实测环境里一次模型对话请求都没发过，没有耗时数据，也没有代码质量对照。

但有一个维度是能查清楚的，而且往往比代码质量更早决定你敢不敢把它装进公司电脑：权限模型。也就是这个 agent 到底能读什么、能写什么、能不能出网、什么时候会停下来问你、边界是靠操作系统撑着还是靠一句提示词自觉。

需要先说明前提：本文能拿出一手依据的只有 Codex（OpenAI Codex）这一侧，来自官方文档和 codex-cli 0.147.0（Windows 11）上的只读命令输出。其它 agent 的具体实现不在我的核实范围内，所以下面不会点名说谁的沙箱更强。我给你的是一套坐标系和一份问题清单——拿去量任何一个候选产品，包括量 Codex 自己。

一、权限模型的五个维度

维度 1：边界画在哪里

Codex CLI 用 -s, --sandbox 选三档：read-only、workspace-write、danger-full-access，配置侧对应 sandbox_mode。官方标注 workspace-write 是默认模式，释义是”能读文件、能在工作区内编辑、能在这个边界内跑常规本地命令”。

这一档的存在本身就是个信号：它承认”能改文件”和”能改哪儿的文件”是两件事。选型时你要问候选产品的第一个问题就是——有没有一个明确的、可配置的可写范围，还是只有”允许改代码 / 不允许改代码”这么一个开关。

维度 2：谁决定要不要问你

approval_policy 三档，CLI 侧是 -a, --ask-for-approval：

untrusted：只有受信任命令（如 ls、cat、sed）免审批，其余升级给用户
on-request：由模型决定何时请求审批
never：从不询问，执行失败直接回传给模型

这里有个必须单独拎出来讲的反直觉点：never 不等于”放开权限”。沙箱边界还在，它改变的只是”要不要问你”。真正撤掉边界的是 danger-full-access，或者顶层的 --dangerously-bypass-approvals-and-sandbox（官方对后者的原文是 “EXTREMELY DANGEROUS. Intended solely for running in environments that are externally sandboxed”）。

把这条抽象出来，就是横向选型时最有用的一个问法：“能不能做”和”要不要问我”是不是两个独立的旋钮。如果一个产品把这两件事糊成同一个滑块，那么调低确认频率就等于同时放开权限——无人值守场景下这个差别会被放大，值得在选型时当面问清楚。别的产品到底是怎么设计的，我没有一手依据，不替它们下结论。

Codex 这边还多一层：approval_policy 既可以写成字符串（粗粒度三档），也可以写成一张表，表里有 granular.sandbox_approval、granular.rules、granular.mcp_elicitations、granular.request_permissions、granular.skill_approval 五个布尔开关。想”只放行某一类弹窗”就必须用表形式，字符串做不到。

维度 3：边界靠什么实现（最容易被忽略的一维）

这一维是区分”真沙箱”和”提示词自律”的关键，官方文档给的是分平台三套实现：

macOS：使用系统内置的 Seatbelt 框架
Windows：在 PowerShell 中使用原生 Windows 沙箱；在 WSL2 中则使用 Linux 沙箱实现
Linux / WSL2：需要用包管理器安装 bubblewrap（bwrap）

这三套是完全不同的东西，别把 Linux 的排查步骤套到 Windows 上——Linux 上”沙箱起不来”第一件事是查 bwrap 装没装，Windows 上查这个毫无意义。

选型时对应的问法是：候选产品的”沙箱”落到操作系统的哪个机制上？如果答案是”我们在系统提示词里要求模型不要越界”，那它和上面这些不是一个量级的东西，你得按”没有边界”来做心理预期。

维度 4：网络是不是独立的一维

workspace-write 下是否出网由 sandbox_workspace_write.network_access 控制，是个独立的布尔，跟文件可写与否分开。再往细走还有域名级：permissions.<name>.network.domains.<pattern> 取 allow 或 deny，支持精确主机与通配；以及 features.network_proxy——这一项官方标注为 experimental（本机 codex features list 里它的阶段也是 experimental、生效值 false），别当稳定能力写进团队规范。

对 ChatGPT Work（web）另有一处开关：Settings > Data controls > Work network access，关闭后命令只能访问必需主机名的允许列表。这部分是官方文档口径，非本机实测。

维度 5：权限能不能做成”档”

Codex 有一层命名权限档：default_permissions 指定默认档名，permissions.<name>.extends 可以继承 :read-only、:workspace 或另一个命名档，permissions.<name>.filesystem.<path-or-glob> 取 read / write / deny。CLI 侧用 -P, --permission-profile <NAME> 套用。

这一维的意义是可复用和可纳管：能不能把”评审代码用这档、跑脚本用那档”固化下来，而不是每次靠记忆敲参数。团队场景还有 guardian_policy_config（受管 Markdown 评审策略，覆盖本地策略）——如果你是要给一个团队选工具，有没有这层直接决定了它能不能纳入 IT 管理。

二、按你的处境倒推：五条决策路径

处境 A：只想让它读代码，绝不许动文件

用 read-only，官方释义是”能查看文件，但不经审批不能编辑文件、不能执行命令”。

codex -s read-only -a untrusted

这条命令是把 -s, --sandbox 与 -a, --ask-for-approval 两个官方选项组合出来的示例，两个选项各自的取值出自官方 help，组合形式未逐项实测，以官方文档为准。

untrusted 在这里是配套的：只有 ls、cat、sed 这类受信任命令免审批，其余全部升级给你。适合刚接手一个陌生仓库、或者对方是生产配置目录的场景。

处境 B：要它改文件，但只许在仓库里

这就是默认的 workspace-write。需要多开一个可写目录时有两条路：命令行的 --add-dir <DIR>，或者配置里的 sandbox_workspace_write.writable_roots——后者的好处是不用撤掉沙箱就能扩可写范围。要不要出网单独由 sandbox_workspace_write.network_access 决定。

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = false
writable_roots = ["<你要额外放开的目录>"]

[windows]
sandbox = "elevated"

以上为按官方文档键位组合的示例，未逐项实测，以官方文档为准。

处境 C：公司电脑，拿不到管理员权限（Windows 用户重点看）

Windows 侧的原生沙箱在 PowerShell 中运行，强制”bounded filesystem and network permissions”，不需要 WSL、不需要虚拟机。但它有两个模式，差别直接落在你有没有管理员权限上：

`windows.sandbox`	特征
`elevated`（官方标注为首选）	使用专用的低权限沙箱用户；文件系统权限边界 + 防火墙规则；需要管理员批准的初始化设置
`unelevated`（回退）	用从当前用户派生的受限 Windows token 运行命令；基于 ACL 的文件系统边界；用环境级离线控制替代防火墙规则；保护更弱

“保护更弱”是官方自己的措辞，我不替它加码。这句话对选型的实际含义是：如果你所在的环境批不下来管理员权限，那你实际能拿到的边界比文档首页描述的要松，相应地就得把 sandbox_mode 和 approval_policy 往保守里调，而不是”反正有沙箱”。

还有两个硬约束要在装之前确认：winget 必须可用；系统版本上 Windows 11 是推荐，较新的 Windows 10（v1809+）是尽力而为（best effort），更老的 Windows 10 不推荐。另有一个 windows.sandbox_private_desktop，默认 true，即默认在私有桌面上运行沙箱子进程。

初始化失败的常见原因官方列了三条：拒绝了 UAC 提示、本地用户创建被阻止、防火墙规则被限制。还有一个专门的错误 1385，官方原文是 “Windows is denying the logon type the sandbox user needs.”，含义是沙箱用户已经建好了，但策略不允许它执行命令。官方给的排查顺序是：① 重启 Codex ② 重试 elevated 初始化 ③ 需要时回退到 unelevated ④ 发送诊断，日志在 CODEX_HOME/.sandbox/sandbox.log。这四步之外的注册表改法、组策略改法，官方没给，我也不编。

处境 D：想让它在云端跑，不占本地机器

到这一步，权限问题就变成数据边界问题了。官方口径：Codex cloud 在隔离的云端环境里跑任务，可并行；本地工作流在你的设备上运行；云端 Work 会话跨 web、移动端、桌面端同步，本地 Work 会话只留在你的电脑上。模型上云端会自动选择，且部分模型在云端不可用。

CLI 侧有对应的 codex cloud 子命令，但本机实测它的帮助文本上标着 [EXPERIMENTAL]，子命令有 exec、status、list、apply、diff。云端与桌面这两块我们没有实测，以上均为官方文档口径。

所以这条路径的判断依据很简单：你的代码允不允许离开本机。如果答案是不允许，那云端能力再方便也不进入你的候选维度，本地沙箱的强度才是你唯一该关心的东西。

处境 E：CI 或无人值守

never + 保留沙箱是这里的正解——从不询问，执行失败直接回传给模型，但边界还在。codex exec 侧有几个配套选项值得注意：--skip-git-repo-check（允许在非 Git 仓库里跑）、--ephemeral（不把会话文件落盘）、--ignore-user-config（不加载 $CODEX_HOME/config.toml，但 auth 仍然使用 CODEX_HOME）。

注意最后这条的例外：忽略用户配置不等于忽略认证。以为加了这个参数就干净了，是个容易踩的坑。

至于 --dangerously-bypass-approvals-and-sandbox，官方原文写得很清楚，它只是给”外部已经沙箱化的环境”用的。换句话说边界并没有消失，只是从 Codex 挪到了容器或虚拟机那一层。你要是本机直接敲这个参数，就是真的没有边界了。

三、怎么验收你的判断（都是只读命令）

判断不能停在读文档上。下面几条在 codex-cli 0.147.0（Windows 11）上实际跑过，你可以照抄验证自己那台机器的实际状态：

codex doctor --summary

看 Configuration 分组下的 sandbox 行。本机这一行显示的是 restricted fs + restricted network · approval OnRequest——文件受限、网络受限、审批策略 OnRequest，三件事一行说清。这比翻配置文件靠谱，因为它显示的是当前生效值，不是你以为自己写进去的值。

配置写坏了怎么办？本机故意传了一段语法不合法的 TOML（codex -c 'features=[unclosed' doctor --summary），doctor 没有崩溃退出，照常跑完，但 Notes 区多了一行：

✗ config       config could not be loaded - Fix the reported config error, then rerun codex doctor.

这是个很实用的一手结论：改完权限配置没生效，第一步就该跑 doctor 看这一行，而不是反复重启。

沙箱到底拦不拦得住写入，也可以自己试。本机在默认沙箱状态下往仓库路径写了个测试文件，命令返回之后目标文件不存在。要注意 codex sandbox 的几个 --sandbox-state-* 选项是一组的：单独给 --sandbox-state-disable-network 而不给 --sandbox-state-json，会直接报缺参数。

还有两条跟”能不能把诊断结果发给别人”有关：codex doctor --json 官方说明是 “Emit a redacted machine-readable report”，是脱敏的；codex mcp list 的 Env 列只显示键名、值打成 *****。这两处自带脱敏，贴给同事排查相对省心——但贴之前仍然自己扫一眼，这是习惯问题。

最后一个边界要说清楚：--strict-config 号称遇到本版本不认识的配置字段就报错退出。本机拿一个拼错的键名（model_reasoning_effortt=high）配 --strict-config 跑 exec --help，正常打印了 help，没有报未知字段错误。说明这个校验发生在真正加载配置去跑会话的时候，--help 这类不进会话的路径不触发。别把它当成”任何情况下都能拦住拼写错误”的保险。

四、横向选型时，该问候选产品的问题清单

我没有其它 agent 的一手依据，所以不给你排名。但上面五个维度可以直接翻译成五个问句，再加一条维度之外的运维补充，凑成六问，拿去量任何一个候选（前五条对应五个维度，第 6 条不在维度里，是装之前顺手要确认的事）：

可写范围是可配置的目录集合，还是一个”允许/不允许”的总开关？
“能不能做”和”要不要问我”是两个独立设置，还是同一个滑块？
边界落在操作系统的哪个机制上？换平台之后是同一套机制吗？
断网是怎么断的——进程级、域名级，还是根本没有这一维？
权限能不能存成可复用的档、能不能被 IT 统一下发？
出问题有没有日志可查、日志在哪个路径？

第 3 条是分水岭。前两条产品文档上都会写得很漂亮，第 3 条问下去才知道对方是有系统级实现，还是只是在提示词里叮嘱模型别乱来。

五、这套坐标系什么时候不管用

不能用它评价代码质量。 权限模型严格的产品不一定写得更好，反过来也一样。这两件事得分开评估。
不能跨版本用。 上面所有实测结论都是 codex-cli 0.147.0（Windows 11）在 2026-08-09 的快照。同一台机器上，我这次采集开头 codex --version 还是 0.131.0，十几分钟后再执行就成了 0.147.0——版本会自己往前走，排查任何权限相关问题时都要以当次 codex --version 的实时输出为准。
标了阶段的功能别当地基。 features.network_proxy 是 experimental，features.code_mode.enabled 与 features.rollout_budget.enabled 官方标注 under development。把团队规范建在这些之上，下个版本可能就得重写。
别把”有沙箱”当成可以不看 diff。 沙箱管的是它能碰什么，不管它改得对不对。评审这一环没有任何权限配置能替你省掉。