设置审批和安全边界

Codex 能读代码、改文件、运行命令，所以安全边界必须先于自动化。核心控制有两层：sandbox 决定技术上能做什么，approval 决定什么时候必须停下来问你。

本页是配置和安全参考，不是完整字段表。具体 key、默认值和平台差异以官方文档为准。

两层控制

flowchart TB
    Action["Codex 想执行动作"]
    Sandbox{"Sandbox 是否允许?"}
    Approval{"Approval policy 是否要求确认?"}
    Run["执行"]
    Ask["请求用户审批"]
    Block["拒绝或暂停"]

    Action --> Sandbox
    Sandbox -->|允许| Approval
    Sandbox -->|不允许| Approval
    Approval -->|不需要确认| Run
    Approval -->|需要确认| Ask
    Approval -->|策略拒绝| Block
    Ask -->|批准| Run
    Ask -->|拒绝| Block

Sandbox 和 approval 不是替代关系：

• Sandbox 是技术边界，限制文件、网络、系统命令等能力。
• Approval 是决策边界，决定某些动作是否需要人工确认。
• Network access 是额外高风险维度，默认应保持收紧。
• Cloud environment 还有 setup 阶段、agent 阶段、secrets 生命周期等边界。

常见 sandbox 模式

日常理解三档就够：

• read-only：适合只读分析、陌生项目、学习和审查。
• workspace-write：适合日常开发，允许在当前 workspace 内修改。
• danger-full-access：取消沙箱限制，只适合外层已经隔离的受控环境。

推荐默认：

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

只读审查：

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

脚本化只读检查：

codex exec --sandbox read-only --ask-for-approval never "检查项目风险"

不要把危险模式当作“效率模式”。它减少的是提示，增加的是事故半径。

Approval policy 怎么选

常见策略：

• on-request：日常推荐。沙箱内动作自动执行，越界或敏感动作请求确认。
• never：不弹审批。适合 CI 或自动化，但必须接受越界动作会被拒绝。
• untrusted：更谨慎，适合完全陌生项目或高风险目录。
• granular policy：适合团队或企业精细控制不同审批类别。

选择方式：

• 本地开发：优先 workspace-write + on-request。
• 只读审计：优先 read-only + on-request。
• 自动化检查：优先 read-only + never。
• 受控批处理：先外层隔离，再考虑更高权限。

网络访问要单独判断

网络访问不是普通权限。它可能带来 prompt injection、数据外泄、依赖供应链和不可复现问题。

本地 workspace-write 默认不应随意开启网络。确实需要时，显式配置并说明原因：

[sandbox_workspace_write]
network_access = true

更稳的做法：

• 能用官方文档或缓存搜索解决，就不要给 shell 命令完整联网能力。
• 需要安装依赖时，先确认 lockfile、registry、版本和回滚方式。
• 需要访问内部系统时，用最小权限 token，并避免写入公开日志。
• Cloud environment 中的 secrets 只放必要内容，并确认它们在哪个阶段可用。

自动审批审查

Codex 支持把某些审批请求交给 reviewer agent 先审查，再决定是否允许继续。这适合团队希望降低人工审批噪音，但又不想完全放开的场景。

典型配置思路：

approval_policy = "on-request"
approvals_reviewer = "auto_review"

使用前要理解：

• 它只审查本来需要审批的动作。
• 它会带来额外模型调用。
• 它不是安全责任转移，最终策略仍由团队负责。
• 高风险、破坏性、数据外泄相关动作仍应保持人工审查。

企业环境可以通过 managed configuration 统一 reviewer policy。

本地与云端的差异

本地 CLI、IDE、App：

• 主要依赖操作系统级 sandbox。
• 工作目录、可写 root、额外目录由本地配置决定。
• 网络访问和 shell 命令风险更接近你的真实机器。

Cloud / Web：

• 运行在 OpenAI 托管的 cloud environment。
• 适合异步任务和仓库级工作。
• environment setup、internet access、secrets、GitHub 权限需要单独治理。
• 不能把本机权限模型直接套到云端。

所以同一个任务，入口不同，安全评估也不同。

配置落地

个人默认值可以写进 CODEX_HOME/config.toml：

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

为常用模式设置 profiles：

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

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

启动时选择：

codex --profile readonly
codex exec --profile automation-readonly "列出潜在风险"

项目规则、团队限制和共享策略应放在项目或 managed configuration 中，不要散落在个人 prompt 里。

安全检查清单

启用或调整权限前，确认这些问题：

1. 当前目录是否受版本控制管理。
2. 是否存在其他人或其他 agent 的未提交改动。
3. 是否需要访问 workspace 外文件。
4. 是否真的需要网络访问。
5. 是否会触碰密钥、支付、权限、生产数据或部署系统。
6. 是否有测试、构建、dry-run 或回滚方式。
7. 是否能解释为什么当前权限组合是必要的。

Codex 的安全配置不是为了阻止它工作，而是让它在可审查、可回滚、可证明的范围内工作。