---
title: "设置审批和安全边界"
description: "理解 Codex 的 sandbox、approval、network access 和自动审批审查，给本地与云端任务设置正确边界。"
verifiedAt: "2026-05-06"
---

import { Cards, Card } from 'fumadocs-ui/components/card';

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

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

> [!WARNING]
> 不要为了省确认步骤，把 `danger-full-access` 或 `--yolo` 设为日常默认。越是自动化场景，越需要外层隔离、可回滚和最小权限。

<Cards>
  <Card title="Agent approvals & security" href="https://developers.openai.com/codex/agent-approvals-security">
    查看 sandbox、approval、network access 和安全建议的官方说明。
  </Card>
  <Card title="Sandboxing concepts" href="https://developers.openai.com/codex/concepts/sandboxing">
    理解本地和云端 Codex 的 sandbox 行为。
  </Card>
  <Card title="Configuration Reference" href="https://developers.openai.com/codex/config-reference">
    查询 `config.toml` 中相关配置项的类型和默认行为。
  </Card>
</Cards>

## 两层控制

```mermaid
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`：取消沙箱限制，只适合外层已经隔离的受控环境。

推荐默认：

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

只读审查：

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

脚本化只读检查：

```bash
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` 默认不应随意开启网络。确实需要时，显式配置并说明原因：

```toml
[sandbox_workspace_write]
network_access = true
```

更稳的做法：

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

## 自动审批审查

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

典型配置思路：

```toml
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`：

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

为常用模式设置 profiles：

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

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

启动时选择：

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

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

## 安全检查清单

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

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

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