OpenAI Codex 的 Windows 沙箱架构：从未提权到提权方案的决策链

摘要

OpenAI 官方工程博客（2026-05-13）详细披露了 Codex CLI 在三大平台上沙箱实现的不对称性：macOS 有 Seatbelt（Codex 会动态生成 .sbpl profile 调整沙箱语义），Linux 有 seccomp/bubblewrap，但 Windows 没有对应的内置强制访问控制机制，只能自行拼装。这是目前公开资料中对"同一个 Agent 在不同 OS 上如何拼装隔离能力"描述最细的一手技术文档，也是第一份公开的、工程级别的 Windows 平台补课记录。

OpenAI 评估了三种 Windows 原生方案（AppContainer、Windows Sandbox 一次性 VM、Mandatory Integrity Control）均予以否决，转而自研两代方案：第一代"未提权沙箱"因网络限制强度不达标被放弃，第二代"提权沙箱"（当前生产架构）创建两个专属合成 Windows 用户以让防火墙规则可以真正约束沙箱进程。

核心创新与差异

原研究贡献：OpenAI 公开承认了未提权版本"网络抑制只是建议性、设计上无法抵御对抗代码"这一结构性弱点，并给出了从"文件系统限制够用但网络限制不够用"到"为了让防火墙规则可执行，不得不引入两个合成用户和管理员级配置步骤"的完整决策链——这是少见的、由厂商自己披露的"安全强度 vs 部署摩擦"权衡案例。

本站分析认为，这套方案本质上仍是命名空间/seccomp/Landlock 一档的 Windows 平替——共享宿主内核，靠 ACL、受限令牌和防火墙做策略过滤，不涉及 microVM/独立内核，理论强度上限和 Linux 容器同级，不会超过 gVisor/Firecracker（参见Agent 沙箱市场地图的隔离原语分级）。其价值在工程决策的透明度，而非隔离强度本身。文中的结论也呼应了一个更普遍的判断："编程 Agent 的安全问题与传统应用安全有本质不同"——因为必须兼容真实开发者的开放式工作流（任意二进制、任意工具链），没法像 AppContainer 那样用能力声明模型提前圈定权限边界。

威胁模型与攻击链

威胁模型不是某个具体攻击链，而是"Codex 需要驱动 shell/Git/Python/包管理器/构建工具等任意二进制的开放式工作流，同时不能让被攻陷的沙箱内进程获得对宿主文件系统和网络的无限制访问"。OpenAI 评估并否决的三种原生方案说明了这个约束有多紧：

方案	否决理由
AppContainer	能力模型要求应用启动前声明所需权限，与 Codex 的开放式工作流不匹配
Windows Sandbox（一次性 VM）	隔离强，但 Codex 需要直接操作用户真实签出代码/环境，而不是独立桌面里的副本；且 Windows 10/11 家庭版不支持
Mandatory Integrity Control（完整性标签）	修改的是真实主机文件系统的信任语义——把工作区标为低完整性，意味着所有低完整性进程（不只是 Codex）都能写入，风险面比精心设计的 ACL 大得多

实验设计与实际过程

以下均为 OpenAI 官方工程博客披露内容，本站未独立复现。

第一代"未提权沙箱"（配置无需管理员权限）：

• 文件写入限制：创建合成 SID（sandbox-write），配合写入受限令牌（write-restricted token）——一次写入必须同时通过"令牌所有者身份检查"和"受限 SID 列表中至少一个 SID 被授权"两层校验；对 .git、.codex、.agents 等目录显式拒绝写入。
• 网络限制：因为不提权就调不动 Windows 防火墙，只能靠环境变量污染（HTTPS_PROXY/ALL_PROXY 指向死端口 127.0.0.1:9、GIT_SSH_COMMAND=cmd /c exit 1）+ PATH 前置 denybin 目录拦截 SSH/SCP 存根。OpenAI 原文直接承认这只是"建议性"（advisory）限制：任何自行实现 socket 通信、或不遵守代理环境变量的程序都能绕过，"设计之初就无法抵御恶意对抗代码"。
• 这一版本最终被放弃，直接原因是网络防护强度不达标，而不是文件写入限制的问题。

第二代"提权沙箱"（当前生产架构，配置阶段需要管理员权限）：

• 核心改动：创建两个专属本地 Windows 用户——CodexSandboxOffline（受防火墙规则约束，禁止一切出站）和 CodexSandboxOnline（不受防火墙规则约束）——把写入受限令牌的主身份从真实用户换成这两个合成用户之一。这一步是关键：Windows 防火墙规则无法绑定到受限令牌的非主体身份（即无法直接对着 sandbox-write 这个 SID 下规则），只能绑定真正的 principal（用户/程序路径/端口），而按二进制路径下规则又太粗（会连坐所有 python.exe 调用，不区分是不是沙箱内启动的）——这正是促成从"未提权"推倒重来到"提权"的根本技术原因。
• 配置复杂度显著上升：创建/管理两个本地用户，用 DPAPI（Windows 数据保护 API）加密存储其凭据（存在沙箱用户自己读不到的位置）；创建并校验防火墙规则；异步给沙箱用户在常见目录（用户 profile、Windows、Program Files、ProgramData）补读权限 ACL——因为 Windows 默认不允许跨用户读取彼此的 profile 目录，换了合成用户身份后这类读操作会直接失败。
• 架构拆成四层，职责分离清晰：codex.exe（保持无需提权的主程序）→ codex-windows-sandbox-setup.exe（独立二进制，只在需要提权配置时跨越 UAC 边界）→ codex-command-runner.exe（解决"真实用户侧无法直接用 CreateProcessAsUserW 以沙箱用户身份+受限令牌启动子进程"这一特权壁垒的两跳方案：先用 CreateProcessWithLogonW 以沙箱用户身份启动 runner，再让 runner 在沙箱用户上下文里自行调用 CreateRestrictedToken+CreateProcessAsUserW 启动真正的子进程）→ 子进程。

关键结果与实际影响

第二代方案已作为生产架构部署，实现了防火墙规则可真正约束沙箱进程出站网络的目标，代价是配置复杂度和管理员权限依赖显著上升。该方案共享宿主内核，理论隔离强度上限与 Linux 容器方案同级，不构成 microVM/独立内核级别的隔离；它解决的是"如何在 Windows 上让策略层限制真正生效"，不是"如何达到硬件级隔离"。结果只描述 OpenAI 自己的工程决策与已部署架构，不代表其他 Windows 沙箱化 Agent 产品采用相同设计或达到相同强度。

局限与待验证问题

• 证据等级为强（厂商官方一手工程披露），但本站未独立复现或验证该沙箱在对抗性输入下的实际抗性。
• 未提权版本的"建议性"网络限制细节（环境变量污染、PATH 拦截）已被 OpenAI 自己认定不可靠，公开文档同样提示这类方法不构成真正的安全边界，只应视为已放弃方案的历史记录，不应作为当前防护参考。
• 未说明该架构在 Windows 10/11 各版本、企业域环境或非默认权限模型下的兼容性与已知绕过方式。
• 需要跟踪后续版本是否进一步收紧或调整该架构，以及是否有独立第三方对其实际隔离强度做过测试。

参考链接

• OpenAI, Building a secure and efficient sandbox for Codex on Windows, 2026-05-13