Codex 为什么总在关键时刻停下来？一篇讲透沙盒、审批与 Auto-review
Codex 能读代码、改文件和执行命令，但这些能力不能没有边界。
当它突然暂停并询问“是否允许访问网络”或“是否允许写入项目外目录”时，不代表任务出错了，而是沙盒和审批机制正在工作。
用“实验室”理解三个概念
可以把 Codex 想象成在实验室里工作的助手：
- 沙盒是墙和门禁，决定它能碰哪些文件、目录和网络；
- 审批策略决定什么时候门禁需要确认；
- 审批人决定由用户还是 Auto-review 回答请求。
三者共同决定 Codex 实际能够做什么。
沙盒决定行动范围
常见模式有三种：
| 模式 | 能力边界 |
|---|---|
read-only |
主要读取和分析，写入会触发限制 |
workspace-write |
可以在当前工作区读写和运行常规命令 |
danger-full-access |
移除本地沙盒边界 |
日常开发通常选择 workspace-write。它允许 Codex 完成项目内修改，又不会默认访问整台电脑。
danger-full-access 不是性能模式，而是风险模式。删除、部署、数据库、支付、权限和生产环境任务尤其不应该轻易使用。
审批策略决定什么时候暂停
| 策略 | 行为 |
|---|---|
untrusted |
除明确安全的读取操作外，更多命令需要确认 |
on-request |
沙盒内正常执行，越界时请求审批 |
never |
不发起审批，只在已有权限内处理 |
最常见的组合是：
sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"
这意味着项目内常规操作可以继续，联网或写到项目外时再暂停。
需要特别注意：never 不代表自动安全。read-only + never 仍然受到只读边界保护；danger-full-access + never 则同时取消沙盒和审批，是高风险组合。
Auto-review 到底做了什么
Auto-review 改变的是审批人：
approval_policy = "on-request"
approvals_reviewer = "auto_review"
当 Codex 需要越界时，请求先交给 reviewer agent。低风险请求可能自动批准，高风险请求会被拒绝或要求用户确认。
它不会：
- 扩大工作区；
- 自动开放网络；
- 绕过沙盒；
- 保证所有命令都安全。
所以 Auto-review 是减少打断的机制，不是无限授权。
联网为什么要单独谨慎
联网常用于安装依赖、搜索资料、调用 GitHub API 和访问测试服务，但也引入三类风险：
- 恶意网页或内容中的提示词注入；
- 代码、日志和凭据意外外发；
- 依赖安装带来的供应链风险。
安全做法包括：
- 没有必要就不开网络；
- 说明需要访问的域名和用途；
- 优先限制到可信域名；
- 不让联网命令读取
.env、cookie、token 和私钥； - 安装依赖前检查来源和锁文件变化。
扩展边界，不等于拆掉边界
如果任务需要同时操作两个项目目录，优先把第二个目录加入 writable roots，而不是切换到完全访问。
如果只需要访问 GitHub 和 npm，可以定义只允许这些域名的 permission profile，而不是开放整个公共网络。
如果某类命令风险固定，可以用 rules 设置：
- 允许；
- 询问；
- 禁止。
这就是“最小权限”原则：只增加完成任务真正需要的能力。
哪些操作必须人工把关
遇到以下任务，建议先查看计划和影响面：
- 删除或批量移动文件；
- 数据库迁移和生产数据修改；
- 认证、权限、支付与账单代码；
- 生产服务器和外部 API；
- 密钥、token、cookie 与私有凭据；
- 大规模依赖升级；
- 发布、部署和推送 release。
可以在任务开头补充：
动手前先说明计划运行的命令和可能影响的文件。
不要读取或输出任何密钥、token、cookie 和私有凭据。
不要执行删除数据、迁移、部署或发布，除非我明确确认。
提示词不能替代沙盒，但可以让风险更早暴露。
写在最后
一套可靠的 Codex 安全模型应该是分层的：
任务范围
→ AGENTS.md 规则
→ 沙盒边界
→ 审批与 Auto-review
→ Hooks 和 rules
→ 测试、CI 与人工 review
没有任何单层机制可以包办安全。沙盒负责限制范围，审批负责处理越界，最终代码质量仍然需要测试和人工审查。