OpenAI 为在 Windows 上运行的 Codex 设计并实现了一个自有沙箱，解决了系统级隔离工具不足的问题；通过组合 Windows SIDs、写限制令牌以及受控网络策略，团队在无需管理员权限的前提下实现对文件写入和网络访问的精细约束。该方案在兼顾安全与可用性后迭代出“未提权”和“提权”两种实现，目标是在不破坏开发者常用工作流的前提下提供可靠的执行边界。
背景
- 问题：Codex 在 Windows 上默认以用户权限运行，需限制其读写和网络能力以兼顾安全与生产力。
- 原因：Windows 缺乏像 macOS 的 Seatbelt 或 Linux 的 seccomp/bubblewrap 那样的现成沙箱机制。
现有 Windows 方案为何不合适
- AppContainer：提供强隔离但适合事先限定权限的单体应用，无法满足 Codex 对任意开发工具和工作流的开放需求。
- Windows Sandbox：兼容性强但运行在独立临时 VM 中，无法直接作用于用户真实工作区，且部分 Windows 版本不可用。
- MIC（完整性标记）：可通过将 workspace 标记为低完整性来限制写入，但会改变文件系统信任模型，使整个工作区成为低信任对象，风险过高。
首次原型：未提权（unelevated）沙箱
- 设计目标：在不要求管理员权限的前提下限制文件写入和网络访问，保持开发流畅。
- 关键技术：
- SIDs（安全标识符）：为沙箱创建合成 SID，使其在 ACL 中有独立身份，不影响系统其它主体。
- 写限制令牌（write-restricted tokens）：通过进程令牌在写操作上触发额外访问检查，限制可写目标。
- 优点：无需修改主机文件系统全局标签或要求提权，能针对性地允许工作区写入并阻止越界写入。
后续重设计：提权（elevated）沙箱
- 团队在初版基础上迭代出需提权的实现（文章中称为“提权沙箱”），以解决初版在可用性或更严格隔离上的局限。
- 产物平衡：在更强的操作系统边界下仍保留对开发工具和工作区的可用性支持，同时加强网络与文件访问的强制执行。
安全与可用性的权衡
- 目标：既要防止模型驱动的任意命令造成损害，也要避免过度提示或阻碍开发者的常见工作流（如运行测试、编辑文件、使用包管理器等）。
- 方案要点：对写入做有针对性的允许，对其它位置施以禁止；网络默认阻断，需显式授权。
结论
- OpenAI 在 Windows 上为 Codex 开发了一套自定义沙箱，通过组合 Windows 原语和工程化设计在无需破坏用户环境或要求普遍提权的前提下实现了细粒度的执行约束，为在 Windows 上安全运行智能编码代理提供了可行路径。
这是面向开发者的务实工程方案，避免了用广泛改动宿主系统信任模型来换取隔离。