AI 编程教程中文版
从原理到实战

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

用工程边界理解 sandbox 和 approval:一个管能不能做,一个管要不要问你。

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

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

能力越强的 agent,越不应该裸奔。让 Codex 自动工作,不等于让它无边界工作。

两个边界

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 能进入真实项目的条件。

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

本页目录