原文链接：第04篇·Codex Harness 审批×权限边界：4 档策略怎么选，密钥与仓库永远碰不到
上篇讲完了 Codex 的「三件套」——审批、沙箱、AGENTS.md 三道闸。
这一篇把审批这道闸拆到最细：它到底什么时候问你？哪些文件无论如何都碰不到？又如何把可写范围缩到最小？
读完后你能带走：四档审批的真实触发差别、几条关键保护路径清单、一份「只让写 src/ 和 tests/」的自定义权限配置，以及那个标着 EXTREMELY DANGEROUS 的开关到底意味着什么。
一、审批策略怎么配：四档由 approval_policy 决定
Codex 的审批策略由approval_policy这一个字段控制，写在~/.codex/config.toml即可全局生效；单次任务也能用codex exec -c approval_policy=on-failure临时覆盖。
它的核心差异只有一句话：执行前要不要先问你。
| # ~/.codex/config.toml approval_policy = "on-request" # on-request / on-failure / never / granular |
日常默认是 on-request：正常自跑，遇到越权或陌生命令才弹确认，也是新人最该先用的档位。下面逐档拆开看。
二、4 档审批：什么时候会弹确认框？
审批策略只回答一个问题：执行前要不要先问你。沙箱才是回答「能不能做」的那个。
- on-request（默认）：正常自跑，遇到越权或陌生命令才弹确认。适合日常开发。
- on-failure：先让 Agent 跑，执行失败才问你。适合高信任自动化任务。
- never：从不打扰，失败直接回灌给模型自己处理。仅用于已被外部隔离的环境。
- granular：按命令类别拆分，标记为
false的类别直接拒绝、不再弹窗。适合精细化管控。把 shell、文件、网络等命令类别分开授权，是团队做统一安全基线的常用手段。
granular和on-request的关键差别在于：后者对陌生命令还会弹框请你确认，前者对配置为禁止的类别直接静默拒绝。对企业里需要统一安全基线的团队，granular更容易做成「团队共识」而不是「每次让个人决定」。
一个常见误解：默认不是「免审」。on-request 对陌生命令照样会弹框，这正是它适合大多数人的原因。
还有一个不太常见的开关--approve-for-me，它把审批请求转给自动审查，但仍保留workspace-write沙箱。可以理解为「自动点头，但不拆沙箱」。
三、保护路径：几条 Agent 永远碰不到的线
无论你把审批和沙箱调到哪一档，Codex 都会把以下路径锁死。这不是「温馨提示」，而是沙箱在系统调用层直接拒绝。
在 macOS 上靠 Seatbelt，在 Linux 上靠 Landlock + seccomp，在 Windows 上靠 Restricted Token。限制发生在内核层：Agent 发起 write/open/connect 等系统调用时，直接被操作系统拒绝。
| 路径 | 保护对象 |
|---|---|
| .git/ | 版本库元数据 |
| .codex/ | 项目级配置与规则 |
| ~/.ssh/ | SSH 密钥 |
| ~/.aws/ | 云厂商凭证 |
| ~/.config/ | 用户级应用配置 |
这些路径共同构成 Codex Harness 的权限边界底线：Agent 再大胆，也改不了你的仓库、密钥和核心配置。
注意：如果用了--dangerously-bypass-approvals-and-sandbox，沙箱被拆掉，这层保护也随之消失。
四、自定义权限边界：只让写 src/ 和 tests/
默认的workspace-write让整工作目录可写。对团队来说，这有时还是太宽。
把可写区缩到最小，需要用到两个真实存在的参数：sandbox_permissions和--add-dir。
| # ~/.codex/config.toml sandbox_mode = "workspace-write" sandbox_permissions = [ "disk-full-read-access", ] |
| codex exec --add-dir src --add-dir tests "修复类型错误并补测试" |
组合含义：Agent 可以读整台机器上的文件（disk-full-read-access），但只能写src/和tests/。它既能在分析时看到全局上下文，又不会顺手把无关文件改掉。这就是Codex Harness 自定义权限的核心用法。
sandbox_permissions管的是「能不能做某类事」，--add-dir管的是「额外可写目录」。两者叠加，才能把「可读范围」和「可写范围」拆开控制。
原则很简单：能只读就不写，能限目录就不限全盘。
五、--dangerously-bypass真相：拆掉两道门后还剩什么
CLI 帮助里对--dangerously-bypass-approvals-and-sandbox的描述写得很直白：
Skip all confirmation prompts and execute commands without sandboxing. EXTREMELY DANGEROUS.
翻译成大白话：它同时关掉审批和沙箱。
用了它，Agent 执行的命令和你手动在终端里执行没有本质区别。误删文件、覆盖密钥、对外发请求，都可能发生。这个开关的唯一合法场景，是「外层已经隔离」的环境——比如一次性 Docker 容器、CI 里的临时 runner、启动后就会回滚的快照虚拟机。在这些地方，Codex 的沙箱是多余的，甚至会影响性能。
截图来源：本机codex exec --help（codex-cli 0.162.1）。红线部分即--dangerously-bypass-approvals-and-sandbox的完整警告。
六、企业日常推荐组合
把审批、沙箱、自定义权限拼起来，最常见的几类工作对应如下：
| 场景 | 审批 | 沙箱 | 补充说明 |
|---|---|---|---|
| 日常开发 | on-request | workspace-write | 默认即可 |
| 高信任自动化 | on-failure | workspace-write | CI 或回归任务 |
| 只读代码审查 | on-request | read-only | 绝不改代码 |
| 容器内批量任务 | never | danger-full-access | 仅一次性隔离环境 |
| 生产环境直连 | 不推荐 | 不推荐 | 除非外层沙箱已就绪 |
对绝大多数团队，把下面两行写进~/.codex/config.toml，就能覆盖 90% 的日常需求。这也是Codex Harness 企业落地时最稳妥的起点：
| approval_policy = "on-request" sandbox_mode = "workspace-write" |
小结
Codex Harness 的权限设计，本质是把「信任」拆成可独立调节的维度：审批管问不问，沙箱管能不能，自定义权限管范围多大。
搞清楚每档审批的真实触发条件，再守住保护路径和最小权限原则，Agent 才敢真正进工作流。对团队来说，把默认配置写进~/.codex/config.toml，把项目级规则写进.codex/和AGENTS.md，就能形成一条从个人到仓库的完整权限链。
留个问题：你在企业里用 Agent 时，最担心它碰哪里？.git、.ssh，还是生产数据库配置？评论区聊聊。
如果这篇帮你把Codex Harness 审批策略和Codex Harness 权限边界画清楚了，点个「在看」；团队也需要这份配置的话，顺手转发收藏。
【欢迎访问我的个人博客主页，这里有我的精选文章和AI大模型日报专栏。👇）
