OpenAI 为 Windows 上的 Codex 代理构建安全沙箱：从非提升方案到专用用户隔离

OpenAI 的编程代理 Codex 运行在开发者本地机器上，默认拥有与用户相同的权限，既可高效执行任务，也存在潜在安全风险。此前 Windows 用户只能在“逐个批准每条命令”（效率低）和“开启完全访问模式”（无监管）之间选择，原因在于 Windows 缺乏现成的隔离工具。

现有 Windows 隔离方案均不适用

• AppContainer：基于能力隔离，适用于预先声明所有需求的窄作用域应用，不适合 Codex 这种运行 Shell、Git、Python 等任意工具的开放式工作流。
• Windows Sandbox：一次性轻量虚拟机，隔离性强但无法直接操作宿主机的代码库、工具和环境，且 Windows Home 版本不可用。
• Mandatory Integrity Control（MIC）完整性标签：若将工作区标记为低完整性，则所有低完整性进程均可写入，会改变宿主机的信任模型，风险不可控。

第一个原型：“非提升沙箱”（Unelevated Sandbox）
为避免请求管理员权限，团队利用 Windows 的安全标识符（SID）和写入限制令牌（write-restricted token）来强制文件写入约束：

• 创建合成 SID sandbox-write，并通过 ACL 授予其对当前工作目录及配置的 writable_roots 的写入/执行/删除权限，同时显式拒绝 .git 等敏感目录。
• Codex 命令以包含 Everyone、当前登录会话 SID 和 sandbox-write SID 的写入限制令牌启动。
• 网络访问方面，采用“失败封闭”策略：设置代理环境变量（如 HTTPS_PROXY=http://127.0.0.1:9）、阻止 Git HTTP(S)/SSH 通信，并通过调整 PATH 和 PATHEXT 拦截 SSH/SCP 调用。
  该方案虽降低了批准频率，但网络限制仅靠环境变量，强度不足，无法阻止绕过代理或二进制替换的攻击。

重新设计：“提升沙箱”（Elevated Sandbox）
为获得真正的强隔离，团队改为需要一次管理员权限的方案：

• 在安装/更新时创建一个专用的低权限 Windows 用户（如 codex-user）。
• 利用 Windows Filtering Platform（或 Windows Firewall）为 Codex 进程设定严格的网络流量规则，只允许与 OpenAI API 及用户明确允许的域名通信。
• 通过文件系统 ACL 仅授予该用户对工作区及指定目录的写入权限，其他路径默认只读。
• Codex 所有命令在该用户上下文中运行，继承其受限的权限和网络规则。
  该设计实现了与 macOS Seatbelt 或 Linux seccomp 等效的强制隔离边界，同时保留了 Codex 在用户工作区内自由读写、执行命令的能力。