OpenAI 的 Windows 安全缺口获得了专门打造的修复方案
OpenAI 详细说明了其如何为 Windows 上的 Codex 构建一个自定义沙箱，并将这一工作描述为有必要把相同的实际安全控制带到微软的操作系统上，而该公司的编码代理在其他平台上已经在使用这些控制。该公司表示，问题很直接：如果没有 Windows 上的沙箱，用户就会被迫在两个糟糕的选择之间做决定。他们要么手动批准大量命令，包括常规读取操作，要么授予无限制访问权限并放弃有意义的安全护栏。
Codex 通过 CLI、IDE 扩展和桌面应用等工具在开发者的机器上运行，而模型推理则发生在云端。这种本地执行模式很强大，因为代理可以在真实环境中运行测试、读取和编辑文件，并执行软件开发任务。但它也有风险，因为软件会继承用户的权限，除非有某种机制对这些权限进行收紧。
OpenAI 表示，其默认模式旨在在中间地带取得平衡：广泛的读取权限、写入权限仅限于当前工作区，以及除非用户明确允许，否则没有互联网访问权限。只有当操作系统能够强制执行这些策略时，它们才真正有意义，这也是为什么缺失的 Windows 沙箱会成为一个实际的产品问题，而不仅仅是一个设计上的不便。
为什么 Windows 需要不同的方法
据 OpenAI 介绍，该公司依赖操作系统的隔离功能，将每条 Codex 命令及其后代进程从启动那一刻起就限制在一个受控边界内。在 macOS 和 Linux 上，有成熟的机制能够契合这种模式。OpenAI 表示，Windows 没有提供一个开箱即用、且足够接近这些要求的方案。
工程团队评估了多种 Windows 选项，包括 AppContainer、Windows Sandbox 以及强制完整性控制标记。该公司的说法表明，问题并不在于 Windows 完全缺乏安全原语，而在于现有工具无法同时满足 Codex 所需的具体组合：开发者笔记本上的低摩擦使用、工作区限定写入、受限网络，以及这些限制在整个进程树中可预测地继承。
因此，OpenAI 选择构建自己的实现，而不是勉强把一个不合适的原生功能硬塞进这个场景。按照该公司的描述，最终结果是一个专门围绕代理工作流设计的 Windows 沙箱，而不是围绕更广泛的虚拟化或应用容器模型设计的方案。
这个沙箱的目标是什么
从实际层面看，这个沙箱是为了在保留 Codex 可用性的同时，降低错误、提示注入或不安全工具建议所造成的影响范围。编码代理之所以有价值，是因为它们可以在不要求持续确认的情况下完成繁琐工作。但如果底层进程可以随意写入任意位置、自由访问网络，或者在没有监督的情况下以完整用户权限启动子进程，这种自治性也会变得危险。
OpenAI 的描述强调，所有命令都从边界内部启动，并且会一直留在其中。这一点很重要，因为开发任务通常会层层调用其他工具。一个测试命令可能会调用构建系统，后者又可能调用脚本、包管理器、编译器或 Git。如果沙箱只作用于第一步，它就解决不了太多问题。该公司的表述暗示，从一开始就通过后代进程树实现隔离，是核心设计要求。
更广泛的产品意义在于，Windows 用户应该能够以更接近 macOS 和 Linux 的方式使用 Codex，且比手动批准模式更少中断，比完全访问模式有更多监管。这正是 OpenAI 试图维护的平衡：既要有足够的能力完成真实的软件工作，又不能让安全变成可选项。
为什么这不仅仅关乎一个功能
OpenAI 的这篇说明也凸显了编码代理更广泛的现实。它们的质量不仅取决于模型推理能力，也取决于围绕模型的外壳：执行控制、文件权限、网络规则以及操作系统行为。随着这些工具从辅助自动补全走向执行型代理，安全模型本身也成为产品的一部分。
这使得 Windows 沙箱不仅仅是一次平台平价更新。它也是一个例子，说明要把一个出色的模型变成在日常机器上可用的工具，还需要额外的工程投入。如果摩擦太大，用户就会绕过保护；如果限制太弱，工具就会变得难以信任。OpenAI 的说明展示了 AI 输出与本地执行之间那一层中间系统承担了多少工作。
该公司的解释还暗示了更广泛的采用前景。Windows 仍然是企业和开发者环境中的核心平台。一个在不同操作系统上都能安全且一致运行的编码代理，更容易部署，更容易治理，也更容易让重视安全的团队接受。通过在平台缺乏合适默认设置的地方构建自定义沙箱，OpenAI 传递出的信号是：安全的本地代理执行不是锦上添花的附加功能，而是基础设施。
