Codex CLI 上手：OpenAI 的沙箱安全编程方案

Sun, 12 Jul 2026 08:30:00 +0800

AI 编程 Agent 能执行任意命令，这意味着它也能删库、泄露密钥、安装后门。信任问题不解决，自主编程就是空谈。

OpenAI 的 Codex CLI 选择了一条不同的路：不靠"请你信任我"，而是用沙箱把 Agent 关进笼子里。97,000+ Star、Rust 重写、Apache-2.0 开源——这是目前安全设计最完善的终端编程 Agent。

为什么需要"安全编程"

AI 编程工具有个天然的取舍：给的自由越多，风险越大。

Agent 需要执行 shell 命令才能干活——装依赖、跑测试、提交代码。但 shell 命令是无限制的：rm -rf / 也是合法命令。你给 Agent 一个任务，它可能顺手执行了你没想到的操作。

已经出过事了。2026 年多个 AI 编程工具被曝出安全问题：沙箱逃逸、权限提升、未授权网络访问。企业用户不敢用，因为一次意外就可能影响生产环境。

Codex CLI 的答案是：默认不信任 Agent，用系统级隔离强制约束行为。

Codex CLI 是什么

项目	值
GitHub	github.com/openai/codex
Stars	97,204
语言	Rust（从 TypeScript 重写）
许可证	Apache-2.0
开发商	OpenAI
支持模型	GPT-5 系列、codex-1 专用模型

Codex CLI 是 OpenAI 开源的终端编程智能体。三种形态：CLI 终端、VS Code 插件、Codex Cloud 云端。核心特点是把安全沙箱做成了系统级能力，而不是靠 prompt 约束。

Rust 重写不只是为了性能。Rust 的内存安全特性让沙箱实现本身更难被绕过——没有 use-after-free、没有 buffer overflow，攻击面从语言层就被收窄了。

五层安全防线

这是 Codex CLI 的核心卖点，也是它与其他工具拉开差距的地方。

第一层：三级沙箱模式

1
2
3
4
5


read-only 只读，不能写文件、不能执行命令
 ↓ 降低约束
workspace-write 可写项目目录，可执行本地命令（默认）
 ↓ 降低约束
danger-full-access 无限制访问（需要显式声明 danger）

默认是 workspace-write——Agent 只能修改当前项目目录的文件，不能动系统文件、不能改其他项目。想突破这个边界？必须显式声明 danger-full-access，名字本身就提醒你这是危险操作。

第二层：审批控制

沙箱管"能做什么"，审批管"什么时候需要问人"：

策略	行为
`untrusted`	非信任命令都要问
`on-request`	沙箱内自由操作，越界时才问（推荐）
`never`	完全自动，不问任何人

最佳实践：--sandbox workspace-write --ask-for-approval on-request。Agent 在项目目录里自由干活，一旦要访问目录外的资源、使用网络、执行敏感命令，就停下来等你确认。

第三层：可写目录白名单

如果 Agent 需要写多个目录（比如同时改前端和后端），不用开 full-access，用 writable_roots 白名单：

1
2
3
4
5
6


# config.toml
[sandbox_workspace_write]
writable_roots = [
 "/home/user/frontend",
 "/home/user/backend"
]

精确控制哪些目录可写，其余一律只读。最小权限原则的工程实现。

第四层：平台原生隔离

Codex 不是用 Docker 容器做隔离，而是用操作系统原生的安全机制：

平台	隔离机制
macOS	Seatbelt 框架（系统级沙箱）
Linux	bubblewrap（用户命名空间隔离）
Windows	双用户架构（CodexSandboxOffline/Online）
WSL2	复用 Linux 的 bubblewrap 方案

Windows 的实现比较巧妙：创建两个本地用户，CodexSandboxOffline（防火墙阻断出站网络）和 CodexSandboxOnline（允许网络），密码随机生成后用 DPAPI 加密存储。Agent 运行在受限用户下，天然无法访问你的个人文件。

第五层：自动审核

设置 approvals_reviewer = "auto_review" 后，审批请求不是弹给你，而是交给另一个 AI Agent 审核。Agent 审 Agent——审核者有权拒绝越界操作，形成双重校验。

安装与上手

macOS / Linux

1

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Linux 需要先装 bubblewrap：

1
2
3
4
5


# Ubuntu/Debian
sudo apt install bubblewrap

# Fedora
sudo dnf install bubblewrap

Windows

1

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

认证

两种方式：

ChatGPT 账号：运行 codex 后选 “Sign in with ChatGPT”，Plus/Pro/Business 套餐包含 Codex 额度
API Key：设置 OPENAI_API_KEY 环境变量

AGENTS.md

在项目根目录放一个 AGENTS.md，告诉 Agent 项目上下文：

1
2
3
4
5
6
7


# 项目说明
这是一个 Next.js 15 项目，使用 TypeScript + Tailwind CSS。

# 规则
- 测试用 vitest，不要用 jest
- 提交信息用 conventional commits 格式
- 不要修改 .env 文件

Codex 启动时会自动读取这个文件，相当于给 Agent 一份项目手册。

实战演示

场景 1：安全模式下重构代码

1

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

在这个模式下，Agent 可以自由读写项目文件、运行测试。但当它尝试 npm install 一个新包（需要网络）时，会弹出审批提示。你确认后才继续。

场景 2：CI/CD 管道中的静默模式

1
2


codex exec --sandbox workspace-write --ask-for-approval never \
 "运行所有测试，如果有失败的修复它们，然后提交"

exec 是一次性执行模式，跑完自动退出。配合 --ask-for-approval never 适合自动化管道——但沙箱仍然生效，Agent 不能突破项目目录。

场景 3：/goal 自主执行

在交互模式下输入 /goal，Agent 进入自主循环：规划 → 执行 → 验证 → 继续，直到目标完成。沙箱和审批策略全程生效。

与 Claude Code、OpenCode 对比

维度	Codex CLI	Claude Code	OpenCode
开发商	OpenAI	Anthropic	社区
语言	Rust	TypeScript	Go
安全设计	五层沙箱 + 平台原生隔离	沙箱 + 权限控制	BYOK，无内置沙箱
沙箱机制	bubblewrap/Seatbelt/Windows Sandbox	类似但实现不同	无
审批控制	三级策略 + 自动审核	有	基础
可写目录白名单	`writable_roots`	有	无
模型	GPT-5 系列 + codex-1	Claude 4 系列	75+ 模型
MCP 支持	✅	✅	✅

安全设计维度，Codex CLI 领先一个身位。 它的沙箱不是应用层的权限检查，而是操作系统级的强制隔离——Agent 想逃逸，得先攻破 bubblewrap 或 Seatbelt。

Claude Code 也有沙箱，设计思路类似，但实现深度不同。OpenCode 走的是 BYOK（Bring Your Own Key）路线，安全完全交给用户自己负责。

谁该用 Codex CLI

首选场景：

企业/金融/医疗等安全敏感行业：沙箱隔离是刚需，不是锦上添花
OpenAI 生态用户：已经用 GPT-5 系列，Codex CLI 是最自然的编程 Agent 选择
团队协作：自动审核功能让多人共用 Agent 时有统一的安全策略
CI/CD 集成：静默模式 + 沙箱 = 安全的自动化编程

不太适合的场景：

需要频繁切换多个 LLM 模型的用户（Codex 主要服务 OpenAI 模型）
超长上下文任务（Claude 的长上下文更稳定）
预算敏感的纯 API 用户（Codex-1 专用模型按 token 计费）

结论

AI 编程 Agent 的竞争正在从"谁能写更好的代码"转向"谁更值得信任"。Codex CLI 的五层安全防线不是营销话术，而是工程落地：操作系统级沙箱、最小权限白名单、Agent 审 Agent 的自动审核。

沙箱不是限制，是 Agent 自主运行的前提。 你得先确定它不会越界，才敢放手。Codex CLI 目前是安全机制最完善的终端编程 Agent。

OpenAI on Kalend's Blog