ginobefun@hongming731 · XOpenAI团队为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 设置为低完整性级别、把工作区标记为低完整性，让操作系统强制拒绝向外写入。问题是把工作区标记为低完整性会改变整台机器上所有低完整性进程的信任模型，影响范围太广，对用户真实的开发环境语义改变过大。