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 的核心卖点,也是它与其他工具拉开差距的地方。
第一层:三级沙箱模式
| |
默认是 workspace-write——Agent 只能修改当前项目目录的文件,不能动系统文件、不能改其他项目。想突破这个边界?必须显式声明 danger-full-access,名字本身就提醒你这是危险操作。
第二层:审批控制
沙箱管"能做什么",审批管"什么时候需要问人":
| 策略 | 行为 |
|---|---|
untrusted | 非信任命令都要问 |
on-request | 沙箱内自由操作,越界时才问(推荐) |
never | 完全自动,不问任何人 |
最佳实践:--sandbox workspace-write --ask-for-approval on-request。Agent 在项目目录里自由干活,一旦要访问目录外的资源、使用网络、执行敏感命令,就停下来等你确认。
第三层:可写目录白名单
如果 Agent 需要写多个目录(比如同时改前端和后端),不用开 full-access,用 writable_roots 白名单:
| |
精确控制哪些目录可写,其余一律只读。最小权限原则的工程实现。
第四层:平台原生隔离
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
| |
Linux 需要先装 bubblewrap:
| |
Windows
| |
认证
两种方式:
- ChatGPT 账号:运行
codex后选 “Sign in with ChatGPT”,Plus/Pro/Business 套餐包含 Codex 额度 - API Key:设置
OPENAI_API_KEY环境变量
AGENTS.md
在项目根目录放一个 AGENTS.md,告诉 Agent 项目上下文:
| |
Codex 启动时会自动读取这个文件,相当于给 Agent 一份项目手册。
实战演示
场景 1:安全模式下重构代码
| |
在这个模式下,Agent 可以自由读写项目文件、运行测试。但当它尝试 npm install 一个新包(需要网络)时,会弹出审批提示。你确认后才继续。
场景 2:CI/CD 管道中的静默模式
| |
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。