OpenAI 详解 Windows 版 Codex 沙箱设计：用合成 SID 告别频繁弹窗

让一个 AI 帮你在电脑上写代码，就像把键盘借给一个刚认识的实习生。在 Mac 和 Linux 上，系统自带现成的防盗锁；但在 Windows 上，很长一段时间里你只有两个极端选择：要么每读一个文件都要你点确认，要么直接把大门完全打开，让它在你的硬盘里随意折腾。

OpenAI 工程师 David Wiesen 披露了他们为 Windows 版 Codex 打造原生沙箱的完整技术内幕。David 在 2025 年 9 月加入 Codex 团队时发现，Windows 上的 Codex 根本没有沙箱环境，用户只能在烦琐的频繁弹窗与彻底放任自流的危险之间二选一。

微软自家方案为何全军覆没

要在本地安全运行代码智能体，关键是控制两件事：不准乱改工作区之外的文件，不准未经允许悄悄往外网发数据。macOS 依靠 Seatbelt，Linux 依靠 seccomp 或 bubblewrap 就能轻松做到，但 Windows 系统开箱并不提供这类通用的轻量隔离工具。

OpenAI 团队首先调研了微软自带的三种隔离方案，结果全部落选。

第一个被排除的是 AppContainer。它是 Windows 原生的应用沙箱，但要求程序预先明确知道要访问什么。然而 Codex 驱动的是任意 shell、Git、Python 解释器和编译工具，这类开放式的开发者工作流根本无法被装进这么死板的容器里。

第二个是 Windows Sandbox 轻量虚拟机。它虽然隔离彻底，但它每次启动都是个干净的独立虚拟桌面，开发者真实的项目环境、工具链都在宿主机上，打通两者极其麻烦。更致命的是，Windows 家庭版系统压根就没有这个功能。

第三个是微软的强制完整性控制（MIC）。OpenAI 曾尝试让 Codex 以低完整性运行，并把项目目录标记为低完整性。但这意味着宿主机上的任何低完整性恶意进程都能随意写入开发者的代码仓库，反而把用户的实际工作区变成了全系统的安全泄洪口。

既不要管理员权限，又要锁死读写与网络

为了不要求用户每次都以管理员权限启动，David Wiesen 带着团队用 Windows 底层的安全积木搭了一套属于自己的无提权沙箱。

在控制文件写入方面，他们组合了合成安全标识符（Synthetic SID）与写入受限令牌（Write-restricted token）。在 Windows 底层，写入受限令牌在执行写入操作时会进行双重核查：既要求当前用户有权限，又要求令牌限制列表中的某个 SID 也具备权限。

利用这一特性，Codex 生成了一个名为 sandbox-write 的虚拟身份，只对当前工作目录和配置文件里指定的额外根目录赋予写和执行权限。与此同时，它对目录内的 .git、.codex 和 .agents 等关键文件夹显式拒绝写入，确保 AI 绝不可能擅自改动版本库本身。

在控制网络访问上，因为没有管理员权限无法调用 Windows 防火墙，团队在首个原型中采取了阻断常见通道的思路。他们将环境变量中的代理地址全部指向死端口 127.0.0.1:9，让 Git 的 HTTP 请求直接撞墙，把 Git SSH 命令替换为直接退出的脚本，并在环境变量最前端插入打桩命令拦截 SSH。

不过团队也承认，这种毒化环境变量的做法虽然能拦住绝大多数标准命令行工具，但属于建议性质的软拦截，如果底层进程强行直接打开网络套接字，理论上依然有逃逸的风险。

为什么重要

对于每天在 Windows 上写代码的开发者来说，这项改进的价值是立竿见影的。此前使用本地 AI 智能体，你要么忍受无休止的手动确认弹窗，要么在关闭防护后时刻提心吊胆，生怕代码执行弄坏整个系统。自研沙箱终于让 Windows 开发者获得了与 Mac 和 Linux 平起平坐的安全体验。

从行业角度看，智能体落地最大的阻碍正在从模型智商转向客户端权限治理。模型生成代码越来越快，但把它下放到真实操作系统中执行时，操作系统的传统权限模型已经远远落后于需求。Windows 缺乏类似 Linux namespace 的开箱即用隔离原语，迫使上层应用厂商不得不自行下潜到底层去组装补丁方案。

我们认为，OpenAI 坚持不依赖管理员权限的做法非常聪明，这保住了极佳的开箱即用体验。但在网络层面的软拦截暴露出 Windows 客户端沙箱依然存在隐患。未来如果 Windows 官方不出面提供系统级的免提权隔离 API，这类智能体客户端的安全博弈恐怕还会继续消耗开发者的大量精力。