# 在 Windows 上为 Codex 构建安全有效的沙箱

- 来源：ginobefun (@hongming731)
- 发布时间：2026-05-14 08:25
- AIHOT 分数：59
- AIHOT 链接：https://aihot.virxact.com/items/cmp4rw8v90896sljxvyaz5boo
- 原文链接：https://x.com/hongming731/status/2054719723276063016

## AI 摘要

OpenAI团队为Codex在Windows上构建沙箱时，因系统缺乏原生内核级工具，评估并否决了AppContainer、Windows Sandbox和强制完整性控制（MIC）三个现成方案。最终自研方案结合专属Windows SID与写受限令牌，在内核层实现无需管理员权限的文件系统隔离；网络隔离则通过创建特定本地用户账户绑定防火墙规则来强制执行。该架构虽复杂，但为所有需在Windows上实现文件系统隔离的AI Agent系统提供了关键设计范式。

## 正文

在 Windows 上为 Codex 构建安全有效的沙箱

https://openai.com/index/building-codex-windows-sandbox

这篇来自 OpenAI 工程博客，记录了 Codex 团队为在 Windows 上实现真正的沙箱隔离所走的完整路径。写法很好：逐一说清楚每个被否掉的方案以及被否的原因，最后再解释自研方案的设计逻辑。整个记录的过程本身就值得学习。

起点是 2025 年 9 月加入 Codex 团队时面对的实际问题：Windows 用户要么批准几乎每一条命令（低效到让 Agent 失去意义），要么开启完全访问模式（安全风险无法接受）。Linux 有 seccomp，macOS 有 Seatbelt，这两个系统有成熟的内核级沙箱工具，Windows 没有对应能力。

团队评估了三个现成方案。AppContainer 是 Windows 内置的应用沙箱，有真实的操作系统级边界，但它是为权限需求明确且固定的应用设计的，Codex 需要驱动开放式的开发工作流（Shell、版本管理、包管理器……），AppContainer 根本没法灵活控制这类需求的写入权限。Windows Sandbox 是一个一次性轻量虚拟机，沙箱边界更强，但 Codex 需要直接访问用户的真实文件和环境，一个需要单独设置和主客通信的虚拟机桌面解决不了问题，而且 Windows Home 版本根本没有这个功能。MIC（强制完整性控制）用标签机制看起来优雅：把 Codex 设置为低完整性级别、把工作区标记为低完整性，让操作系统强制拒绝向外写入。问题是把工作区标记为低完整性会改变整台机器上所有低完整性进程的信任模型，影响范围太广，对用户真实的开发环境语义改变过大。

最终的自研方案核心是两层机制的组合。第一层是为 Codex 创建一个专属的 Windows SID（安全标识符），这个 SID 只属于 Codex 沙箱，外部没有任何普通进程拥有它。第二层是写受限令牌：任何写操作要通过，必须同时满足两个条件，普通用户身份有权限，且受限 SID 列表中也有相应授权。这个双重检查机制让操作系统在内核层面直接执行文件系统隔离，不需要管理员权限，也不依赖进程树里的任何软件层配合。

网络隔离是另一层：要做到真正的强制执行而不是依赖约定，需要防火墙规则，而 Windows 上的防火墙规则必须绑定到特定用户账户。最终方案是创建两个本地用户：一个在线账户、一个离线账户，沙箱内的 Codex 命令以离线账户身份运行，防火墙规则针对这个账户生效。

最终架构是四个独立二进制文件处理不同的信任边界，并不简单，工程博客也坦诚说了这一点。每一层复杂度的增加都是因为更简单的方案留下了真实的安全缺口。这套设计范式的参考价值超出 Codex 本身：所有需要在 Windows 上隔离文件系统的 Agent 系统（AI 编码工具、自动化测试框架、RPA 产品），都可以借鉴这个通过专属 SID 加写受限令牌实现隔离的思路。