默认收紧，需要才放开
上一节理解了权限的机制。这一节落地最重要的安全原则：最小权限——默认只给 AI 完成当前任务所必需的能力，不多给一分。
对 codex-review 来说，这是给评审定安全边界的核心原则。评审技能一进仓库就是全组用，它的权限边界如果没收紧，等于把全组的评审能力都暴露在风险下。所以 codex-review 的安全边界，必须「默认收紧、需要才放开」。
什么是最小权限
最小权限（Principle of Least Privilege）是一句朴素的话：给主体恰好够用的权限，而不是够多的权限。
放到 Claude Code 就是：
- 它只需要读
src/，就只让它读src/ - 它只需要跑测试，就别给它跑删除的权限
- 每一个「多余的权限」，都是多一个风险入口
放到 codex-review 就是：
- 评审只需要读，就只给「读」，不给「写」
- 评审不需要跑命令，就别给命令权限
- 评审偶尔要核对依赖，就只放行「读 package.json」，不给改依赖的权限
每一个多余的权限，都是评审一个潜在的风险入口。 评审技能越克制，codex-review 越安全。
三个落地做法
1. 按需授权
任务开始前想清楚：它需要读哪些、改哪些、跑哪些？只开这些。
任务：重构 src/auth.js
授权：读全项目 + 改 src/auth.js + 跑 npm test
不开：改数据库脚本、改部署配置
对 codex-review，每次评审前也这样按需授权：
评审任务：审 src/ 本次 30 个文件改动
授权：读本次改动涉及的 src/ 文件 + diff
不开：改任何文件、跑 npm install、访问生产配置
2. 默认拒绝，明确放行
心态上默认「不让它碰」，确有必要才放行。这样比默认全放、再去收，安全得多。
对 codex-review：默认拒绝一切「改」和「跑命令」，只有当这次评审确实需要（比如要跑测试验证某个问题）时，才明确放行那一条。
3. 敏感操作必须确认
删除、覆盖、执行高风险命令这类不可逆或影响大的操作，无论如何都要弹确认，让 AI 停下来问你要不要做。
对 codex-review：评审几乎不该碰这类操作，但如果某次评审需要删除文件、覆盖配置、执行高风险命令，必须弹确认，让它在动手前停下问你。
信任的边界
「信任」不是「全信」，而是分层的：
- 低风险（读文件、看代码）：可以信任，直接做
- 中风险（改代码）：信任 + 事后审查
- 高风险（删数据、改生产、跑危险命令）：不信任，必须确认
把信任分层套到 codex-review 的评审子 Agent 上：
| 评审动作 | 风险 | 信任级别 |
|---|---|---|
| 读代码、读 diff | 低 | 可信任，直接做 |
| 跑测试验证 | 中 | 信任 + 事后确认结果 |
| 改文件（修正「必须改」） | 中高 | 单独任务 + 授权 + 事后审查 |
| 删文件 / 覆盖配置 | 高 | 不信任，必须弹确认 |
关键是：评审子 Agent 默认只落在「读代码」这个低风险层。要往上跨一层，都必须单独授权、单独确认。
一个安全实践清单
每次让 Claude Code 干有风险的活，过一遍这个清单：
- [ ] 它只需要哪些读权限？
- [ ] 它只需要改哪些目录？
- [ ] 它需要跑哪些命令？
- [ ] 哪些操作必须弹确认？
- [ ] 有没有多余的权限能收掉？
对 codex-review 的每次评审，翻成评审版的清单：
- [ ] 评审只需要读哪些文件 / diff？
- [ ] 本次评审是否允许改文件？（默认否）
- [ ] 是否需要跑命令（如 npm test）？只跑哪几条？
- [ ] 哪些操作（删/覆盖/高危险命令）必须弹确认？
- [ ] 有没有多余的权限能收掉？
每次评审前过一遍，评审权限就不会悄悄扩大。
把权限边界写进 codex-review 技能
最小权限要做到「稳定执行」，最好写进技能本身。在 SKILL.md 里加一节「权限边界」，让每次触发都自带约束：
权限边界（codex-review 评审技能必须遵守）：
- 默认只读，不修改任何文件
- 只输出评审报告，不直接改代码
- 需要跑测试/核对依赖时，只跑列明的命令
- 任何删除、覆盖、高风险命令，必须停下来请求确认
把权限写进技能，codex-review 的评审就不再依赖「每次手动叮嘱」，而是自带安全边界。
落地练习
npm test 命令授权，并确认它没借此拿到别的权限。② 怎么判断做对了：评审过程它只读不改、没乱跑命令；把权限写进技能后，不再需要你每次手动叮嘱「只读」；你给它的授权范围和它实际做的完全一致，没越界。
③ 卡住了怎么办：如果它想改文件或跑多余命令，先确认你本次授权里是否误开了权限，收紧后重试；如果权限边界写了它没遵守，把边界写得更有约束力，或明确声明「违反边界即停止」。
常见坑：只靠「口头叮嘱」，不写进技能
很多人的安全边界只存在于对话里——「这次只读啊，别乱改」。但口头叮嘱会随着会话、子 Agent、不同人，慢慢失效：这次记得，下次忘了；主会话记得，派出去的子 Agent 未必记得。光靠嘴说，安全边界就是纸糊的。
对策是把权限边界写进技能 / 固定配置，让它每次触发都自带约束。codex-review 的做法就是在 SKILL.md 里固化「权限边界」一节——这样不管谁来触发、哪个子 Agent 执行，都先被技能的权限约束框住。
小结
- 最小权限 = 恰好够用，不是越多越好
- 按需授权、默认拒绝、敏感操作必确认
- 信任按风险分级：低风险信任，高风险必确认
- 动手前过一遍安全清单
- codex-review 的权限边界要写进技能，稳定执行、全组生效
下一模块进入「综合实战」，把这几个进阶能力串起来——端到端跑通 codex-review。