05 · Codex 为什么需要审批和沙箱

你是 Codex 安全边界配置顾问，帮我为一个任务配好 sandbox、approval 和网络权限，既不裸奔也不过度限制。

【角色】
你精通 Codex 的 sandbox（能不能做）、approval（要不要问）、network access 三层边界，熟悉只读、workspace-write、自动化只读等模式，能按任务风险给出最小够用的权限配置。

【输入】
- 我要让 Codex 做的任务：___
- 任务在什么环境跑：___（本机日常开发 / CI 批处理 / 陌生项目审查）
- 是否会碰高风险区：___（git 不可逆操作 / 装依赖改 lockfile / 生产数据 / 密钥 token / 联网下载）
- 是否多人或多 agent 同时在这个 repo：___

【工作流程】
1. 按任务性质判断基线模式（只读分析 / 日常开发 / 自动化只读）
2. 逐项核对高风险动作清单，标出哪些必须 approval、哪些直接禁止
3. 判断是否需要联网，能用本地或官方文档替代就关闭网络
4. 若多人协作，补上工作树边界规则（先看 git status、不碰别人改的文件）
5. 产出可直接使用的 config.toml 配置 + 启动 CLI 参数

【输出规范】
▌一、推荐基线：sandbox_mode + approval_policy + 是否联网，各附一句理由
▌二、必须人工确认或禁止的动作清单（针对本任务，不要泛泛而谈）
▌三、可直接粘贴的 config.toml（含 profile）或启动 CLI 参数
▌四、验证方式：怎么确认这套边界真的生效

【硬约束】
- 遵循最小够用：能只读不写、能不联网不联网、能 workspace 内就不越界
- 命中"不可逆 / 影响别人 / 涉及钱、权限、密钥、生产数据 / 无回滚"任一条的动作，一律不自动放行
- 网络默认关闭，需要时限定域名、用完收回，不作为日常默认打开
- 配置里不出现真实密钥，凭据一律走环境变量或凭据存储

Codex 是能行动的 agent。它会读文件、改代码、运行命令，所以必须先定义行动边界。否则一个看起来很小的任务，也可能扩大成文件误删、依赖污染、错误推送或敏感信息泄露。

Sandbox 和 approval 就是这套边界的两部分：sandbox 管“技术上能不能做”，approval 管“做之前要不要问你”。

两个边界

flowchart TD
    Start["Codex 想做一个动作"]
    Sandbox{"Sandbox<br/>允许这个动作吗?"}
    Approval{"Approval<br/>需要人工确认吗?"}
    Run["执行"]
    Ask["请求确认"]
    Stop["停止或换方案"]

    Start --> Sandbox
    Sandbox -->|允许| Approval
    Sandbox -->|不允许| Approval
    Approval -->|不需要| Run
    Approval -->|需要| Ask
    Approval -->|拒绝| Stop
    Ask -->|同意| Run
    Ask -->|拒绝| Stop

可以这样记：

• Sandbox 像墙，限制它能走到哪里。
• Approval 像门，决定什么时候必须敲门。
• Network access 像外网出口，默认应更谨慎。
• Git、密钥、生产数据、支付和权限系统都属于高风险区域。

缺 sandbox，agent 可能做太多。缺 approval，关键动作没有人工判断。

为什么不能直接全开

危险不在于 Codex “想作恶”，而在于 agent 会根据目标寻找路径。目标和边界不清楚时，它可能走到你不希望它走的地方。

典型风险：

• 清理文件时误删重要目录。
• 调试依赖时安装新包并污染 lockfile。
• 处理 Git 冲突时做不可逆操作。
• 访问网络时被网页内容诱导执行不可信指令。
• 自动化脚本触碰密钥、账号、支付或生产数据。

这些问题都不是靠一句“谨慎一点”解决的。要靠权限、审批、版本控制、回滚和验证。

三个常用模式

只读分析：

codex --sandbox read-only --ask-for-approval on-request

适合陌生项目、审查、学习、定位问题。它能读，但默认不能直接改。

日常开发：

codex --sandbox workspace-write --ask-for-approval on-request

适合在当前 workspace 内改文件、跑测试、迭代实现。越界动作需要确认。

自动化只读检查：

codex exec --sandbox read-only --ask-for-approval never "检查文档格式问题"

适合 CI 或批处理。它不会弹审批，所以任务必须设计成不需要越界。

什么动作必须人工判断

这些动作不应该默认自动放行：

• 写 workspace 外的文件。
• 删除大量文件或执行不可逆命令。
• git reset --hard、force push、改主分支。
• 安装新依赖或刷新 lockfile。
• 访问生产数据库、生产日志、支付、权限系统。
• 读取或上传密钥、token、cookie、账号信息。
• 从互联网下载脚本并执行。

判断标准很简单：

1. 是否不可逆。
2. 是否影响别人。
3. 是否涉及钱、权限、密钥或生产数据。
4. 是否缺少回滚方案。

只要命中其中一条，就不要让 Codex 自动执行。

网络访问要更谨慎

默认关闭网络不是保守，而是合理。联网会引入外部内容、依赖供应链和数据外泄风险。

需要联网时，先问：

• 是否真的需要 shell 命令联网。
• 是否能用官方文档、缓存搜索或本地文件替代。
• 是否要限制域名。
• 是否会发送仓库内容、日志或 token。
• 是否能复现和回滚。

网络权限不应作为日常默认打开。它应该是任务需要时明确打开、用完收回。

多人协作时的额外规则

多人或多 agent 同时工作时，安全边界还包括工作树边界：

• 先看 git status。
• 不碰别人已经修改的文件。
• 每批只改少量明确文件。
• 不顺手修改共享脚本、配置或索引。
• 验证失败时区分是否由本次改动造成。

这类边界不完全靠 Codex 配置解决，也要写进任务说明或项目规则。

最小配置建议

个人默认值：

sandbox_mode = "workspace-write"
approval_policy = "on-request"

只读 profile：

[profiles.readonly]
sandbox_mode = "read-only"
approval_policy = "on-request"

自动化只读 profile：

[profiles.audit]
sandbox_mode = "read-only"
approval_policy = "never"

更高权限只应该出现在隔离环境、短期任务和明确验证方案中。

正确心态

Sandbox 和 approval 不是拖慢 Codex 的障碍，而是让 Codex 能进入真实项目的条件。

没有边界，你只能把它当玩具。边界清楚，它才可以成为工程协作者。

官方参考

以下为本页涉及工具的权威来源，功能与价格以官方为准：

• OpenAI Codex 官方文档