OpenAI 揭秘:如何为 Codex 打造 Windows 安全沙箱?

OpenAI 深度解析在 Windows 上为 Codex 编程智能体构建安全、高效沙箱的工程历程与技术架构。

🚀 引言

当我（作者）在 2025 年 9 月加入 Codex 工程团队时，Windows 版本的 Codex 还没有沙箱实现。这意味着 Windows 用户在使用 OpenAI 的编程智能体时，只能在两个不太理想的选项中做出选择：

Codex 是一款编程智能体（Agent），它运行在开发者的笔记本电脑上——无论是通过 CLI、IDE 插件还是桌面应用。它负责人类开发者与云端推理模型之间的对话。

默认情况下，Codex 以真实用户的权限运行，这意味着它能做用户能做的一切。这虽然强大，但也存在潜在危险。编程模型可能会指示系统运行本地命令，从运行测试、读取/编辑文件到创建 Git 分支。因此，Codex 需要在效率与安全之间寻找平衡。

为了实现对文件写入和网络访问的自动化约束，Codex 需要一个能够强制执行这些约束的沙箱环境。

Windows 提供了一些隔离工具和原语，但没有一个能完全满足我们的需求。我们评估了以下方案：

原理
：Windows 原生沙箱，一种基于能力的隔离模型，适用于预先明确知道需要访问哪些资源的 App。
局限
：Codex 驱动的是开放式的开发者工作流（如 Shell、Git、Python、包管理器等）。AppContainer 的隔离虽然强，但对于这种“像开发者一样操作”的工作负载来说过于狭隘。

原理
：微软提供的轻量级临时虚拟机。
局限
：Codex 需要直接在用户的实际代码仓库、工具和环境中操作，而不是在一个独立的、需要繁琐设置的虚拟机里。此外，Windows 家庭版（Home SKU）甚至不支持此功能。

原理
：通过“低、中、高”完整性级别决定系统对对象和进程的信任度。低完整性进程无法写入高完整性对象。
局限
：修改完整性标签会对主机文件系统产生广泛且有风险的语义更改。将工作空间标记为低完整性，意味着所有低完整性进程都能写入该区域，这比向特定沙箱授予 ACL 权限的风险更大。

我们的第一个工作原型结合了多种 Windows 概念，目标是**无需管理员权限（非提权）**即可运行。

我们使用了两个关键的 Windows 构建模块：SID 和 写入受限令牌。

SID（安全标识符）
：它是 Windows 绑定权限的身份。我们可以为 Codex 沙箱创建专属的合成 SID，而不干扰机器上的其他任何东西。
写入受限令牌
：这种令牌会让 Windows 在执行写入操作时进行额外的访问检查。只有当普通用户身份和受限 SID 列表中的 SID 同时被允许时，写入才能成功。

在非提权环境下，我们无法使用 Windows 防火墙（它需要管理员权限）。因此，我们尝试通过环境变量来“投毒”常见的网络出口（如设置 HTTPS_PROXY 到一个死地址）。

虽然这能拦截大部分工具流量，但它只是建议性的。恶意进程可以轻易忽略环境变量，直接打开 Socket 绕过限制。

为了获得更强大的网络抑制能力，我们决定放宽“无需提权”的约束，转而采用提权设计。

目前的实现方案在设置时需要管理员权限。关键改变在于：进程的运行主体不再是真实的 Windows 用户，而是 Codex 创建的两个本地专用用户：

专属设置步骤
：创建合成 SID、创建专用用户、加密存储凭据、配置 Windows 防火墙规则。
权限对齐
：为了让沙箱用户拥有与真实用户相当的读取权限，我们需要异步地为常用的 Windows 目录（如 C:\Users\<real-user>）授予读取 ACL。
命令运行器（Command Runner）
：我们引入了一个新的二进制文件 codex-command-runner.exe。

爱因斯坦曾说：“一切都应该尽可能简单，但不能更简单。”

Codex 沙箱的最终架构包含四个层级：

这次工程实践最大的教训是：Windows 并没有提供一个能直接对应“安全自主编程智能体”的原语。 我们必须组合多种工具和概念，在安全性和智能体的工作效率之间寻找那个微妙的平衡点。

OpenAI 团队在 Windows 上的沙箱探索，本质上是在一个缺乏底层隔离支持的系统上“戴着镣铐跳舞”。

反观国内的很多 AI 应用，要么在权限申请上“狮子大开口”，要么在安全性上“听天由命”。OpenAI 这种为了保护用户安全，不惜增加工程复杂度（多进程架构、自定义 SID、异步 ACL 等）的极客精神，非常值得国内开发者学习。

对于编程智能体（Agent）来说，安全不是一个补丁，而是一个底座。如果底座不稳，再强大的智能体也无法在生产环境中大规模落地。

求点赞 👍 求关注 ❤️ 求收藏 ⭐️你的支持是我更新的最大动力！