---
title: "05 · Codex 为什么需要审批和沙箱"
description: "用工程边界理解 sandbox 和 approval：一个管能不能做，一个管要不要问你。"
canonical: "https://xiangyugongzuoliu.com/openai-codex-sandbox-approval"
verifiedAt: "2026-05-06"
---

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

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

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

> [!IMPORTANT]
> 能力越强的 agent，越不应该裸奔。让 Codex 自动工作，不等于让它无边界工作。

<Cards>
  <Card title="官方安全配置" href="/docs/codex/official/02-config-security/07-approval-security">
    查看 sandbox、approval、network access 的配置说明。
  </Card>
  <Card title="CLI 参数" href="/docs/codex/official/01-products/27-cli-args">
    学习如何在启动时临时设置 sandbox 和 approval。
  </Card>
  <Card title="上下文工程" href="/docs/codex/understanding/context-engineering">
    边界要和上下文一起给，否则任务仍会靠猜。
  </Card>
</Cards>

## 两个边界

```mermaid
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 冲突时做不可逆操作。
- 访问网络时被网页内容诱导执行不可信指令。
- 自动化脚本触碰密钥、账号、支付或生产数据。

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

## 三个常用模式

只读分析：

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

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

日常开发：

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

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

自动化只读检查：

```bash
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 配置解决，也要写进任务说明或项目规则。

## 最小配置建议

个人默认值：

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

只读 profile：

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

自动化只读 profile：

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

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

## 正确心态

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

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