@thsottiaux: 我们持续投资，让代理在Windows上运行得更好。强烈推荐阅读David的工程博客文章…

我们正在继续投资，让智能体在 Windows 上工作得更好。强烈推荐阅读 David 关于我们为 Codex 实现 Windows 沙箱的独特方法的工程文章：https://t.co/V3WsYjMJbg — # 构建一个安全、有效的沙箱，以在 Windows 上启用 Codex 来源：https://openai.com/index/building-codex-windows-sandbox/ 当我于 2025 年 9 月加入 Codex 工程团队时，Codex for Windows 还没有沙箱实现，这意味着 Windows 用户在使用 OpenAI 的编码智能体时，被迫在两种不太理想的选择中做出选择：1. 批准编码智能体想要运行的几乎每个命令（即使是读取命令），这既低效又烦人。使用 Codex 的一大好处是你无需亲自完成所有繁琐的工作。2. 启用完全访问模式：让 Codex 无需批准或限制即可运行所有命令，这虽然消除了摩擦，但牺牲了监督。 Codex (https://openai.com/codex/)，我们的编码智能体，运行在开发者笔记本电脑上——无论是通过 CLI、IDE 扩展还是桌面应用程序。它管理着键盘前的人类与云端运行模型之间的对话以处理推理。默认情况下，Codex 以真实用户的权限运行，这意味着它可以执行用户可以做的所有事情。这既强大又可能危险。编码模型可能会指示 harness 在本地运行命令，从运行测试、读取或编辑文件，到创建 Git 分支，因此 Codex 的默认模式试图在有效性和安全性之间找到恰当的平衡。该默认模式允许 Codex 在几乎任何地方读取文件，并在你的工作区（即你运行 Codex 的目录）内写入文件，除非你指定需要网络访问，否则不允许访问互联网。为了实现对写入文件和网络访问的自动约束，Codex 需要一个能实际强制执行这些约束的沙箱环境。 沙箱是一个受限的执行环境。当开发者使用 Codex 时，其计算机操作系统会以降低权限的方式启动一个命令，并且这些约束会沿着进程树向下传播。每个 Codex 命令从一开始就在沙箱中运行，并且所有子进程都保持在同一边界内。 Codex 需要由操作系统强制执行的隔离功能来实现有效的沙箱。有些操作系统提供了能很好地做到这一点的工具（例如 macOS 上的 Seatbelt，Linux 上的 seccomp 或 bubblewrap）；然而，Windows 目前并没有直接提供这种类型的能力。为了让 Codex 在 Windows 上与其他地方一样安全且使用愉快，我们需要实现自己的沙箱。 Windows 提供了一些用于隔离的工具和原语。虽然它们都不完全满足我们的要求，但我们研究了几个潜在的解决方案——即 AppContainer、Windows Sandbox 和强制完整性控制标签。 AppContainer - 是什么： AppContainer 是 Windows 原生沙箱，是一个基于能力的隔离模型，专为预先确切知道需要访问什么的应用而构建。 - 为什么有吸引力： 因为它提供了真正的操作系统边界，而不是尽力而为的限制。 - 为什么不适用： Codex 不是一个严格限定范围的应用。它驱动开放的开发者工作流：Shell、Git、Python、包管理器、构建工具，以及智能体决定需要的任何其他二进制文件。实际上，这使得 AppContainer 形状不适合该问题。它是强大的隔离，但针对的是一类比“让智能体像开发者一样操作”要窄得多的工作负载。 Windows Sandbox - 是什么： Windows Sandbox 是 Microsoft 的可丢弃轻量级虚拟机。你会得到一个具有强隔离边界的全新 Windows 桌面，会话结束时你在其中的所有操作都会消失。 - 为什么有趣： 原因显而易见——比 AppContainer 与任意软件的兼容性更好，并且从安全角度来看，它是一个更强的盒子。 - 为什么不适用： Codex 需要直接作用于用户的真实检出、工具和环境，而不是在一个需要设置和宿主机/客户机桥接的单独可丢弃桌面内部。它还有一个基本产品问题：Windows Sandbox 甚至不在 Windows 家庭版 SKU 上可用。 强制完整性控制 (MIC) 完整性标签 - 是什么： Windows 有一个称为“完整性级别”的概念，例如低、中、高，用于确定系统信任对象和进程的程度。基本规则是，较低完整性级别的进程不能写入较高完整性级别的对象，即使正常的 ACL 否则会允许它。例如，低完整性级别的进程被视为不太受信任，因此 Windows 会阻止它写入正常的中间完整性级别的对象，除非这些对象被明确重新标记以允许它。 - 为什么看起来不错： MIC 在纸面上看起来很优雅——以低完整性运行 Codex，将可写根目录重新标记为低完整性，让 Windows 在其他所有地方强制执行禁止写入。这将为我们提供一个非管理员路径，背后有真正的操作系统机制支持。 - 为什么不适用： 与 ACL 一样，完整性标签会修改真实的主机文件系统，并且在这种情况下，语义变化尤其广泛。将工作区标记为低完整性不仅仅意味着“Codex 可以在这里写入”。它意味着通常低完整性的进程也可以在那里写入。在真实的开发者机器上，这会将用户的真实检出变成主机的低完整性接收器，这比为单个沙箱设计授予精心定制的 ACL 要危险得多。即使中间完整性的开发者工具继续工作，工作区的底层信任模型也发生了变化，这种变化难以控制且更难以证明合理。 在评估了所有选项并认为它们不可行之后，我们开始设计自己的解决方案，以便为 Windows 用户带来良好的 Codex 体验。 ## 第一个原型：“非提升沙箱” 我们的第一个工作原型结合使用了 Windows 概念和工具来实现我们需要的隔离。从一开始，一个目标就是使其无需提升权限即可工作，这意味着 Codex 不需要在设置或运行沙箱时提示用户授予管理员权限。这意味着要弄清楚如何对两件事施加合理限制：文件写入和网络访问。 如果我们完全不限制文件写入，就会出现安全问题。如果我们限制文件写入太多，沙箱会损害用户的工作效率，需要不断请求批准。为了解决这个问题，我们依赖于两个重要的 Windows 构建块：SID 和写入限制令牌。 SID，即安全标识符，是 Windows 关联权限的身份。每个用户都有一个 SID，组有 SID，甚至单个登录会话也有自己的 SID。例如，当前登录的会话可能有一个像 S-1-5-5-X-Y 这样的 SID。分配给本地管理员组的 SID 可能是 S-1-5-32-544。Windows 还允许你创建不对应于真实用户但仍可出现在 ACL（访问控制列表）中的合成 SID，ACL 定义了谁可以读取/写入/执行特定文件或目录。这使得 SID 成为我们沙箱的一个有用原语：我们可以创建专门用于 Codex 沙箱的 SID，而不会干扰机器上的任何其他内容。 进程令牌是 Windows 中的安全对象，用于定义正在运行的进程的身份和权限。它们决定了进程可以执行哪些操作。写入限制令牌是一种特定类型的进程令牌，它使 Windows 对写入操作执行额外的访问检查。为了使写入成功，必须通过两项检查： 1. 正常用户身份（令牌“所有者”）必须被允许执行该操作 2. 令牌受限 SID 列表中的至少一个 SID 也必须被授予访问权限 实际上，这些检查让我们可以使用 ACL 精确定义沙箱可以修改文件系统的位置，这为我们提供了围绕写入操作所需的粒度。 使用 SID 和写入限制令牌，我们的非提升沙箱的工作方式如下： 1. 沙箱设置创建一个名为 sandbox-write 的合成 SID。 2. sandbox-write SID 被授予对以下位置的写入、执行和删除访问权限： 1. 当前工作目录 2. 在 config.toml 中配置的任何其他 writable_roots。 3. 沙箱设置明确拒绝该相同 SID 对“可写内部只读”位置的写入访问权限，例如： 1. /.git 2. /.codex 3. /.agents 4. Codex 在写入限制令牌下启动命令，其受限 SID 列表包括 Everyone、当前登录会话 SID 和 sandbox-write 合成 SID。 这个流程有效地解决了限制文件写入的问题，看起来很有希望。现在我们需要一个解决方案来限制沙箱的网络访问。限制网络访问是沙箱的重要组成部分；如果没有它，恶意代码可能从机器中窃取数据到互联网。因为我们希望避免提升权限的要求，所以可用的强阻止网络流量的选项有限。我们想要使用的工具，如 Windows 防火墙，通常需要管理员权限才能安装。 由于没有 Windows 防火墙作为选项，我们所能控制的内容有限。我们尝试让子环境对开发者实际使用的网络工具采用封闭失败模式，这样 Git 命令、包安装程序等会在沙箱中失败，用户必须批准任何面向互联网的操作。其想法是“毒化”明显的逃逸途径：将代理感知流量发送到死端点，使 Git 的 HTTP(S) 传输也做同样的事情，并使 Git over SSH 立即失败。除此之外，我们在 PATH 前添加了一个小的 denybin 目录，并重新排序了 PATHEXT，以便存根 SSH 和 SCP 脚本在实际二进制文件之前解析。 例如，以下是我们用于限制网络访问的一些特定环境覆盖： - HTTPS_PROXY=http://127.0.0.1:9 - ALL_PROXY=http://127.0.0.1:9 - GIT_HTTPS_PROXY=http://127.0.0.1:9 - NO_PROXY=localhost,127.0.0.1,::1 - GIT_SSH_COMMAND=cmd /c exit 1 这捕获了大量正常工具驱动的流量，但仍然只是建议性的。一个进程可以忽略环境变量、绕过 PATH 或直接打开套接字——这太危险了。 与任何有趣的软件实现一样，第一个原型既有优点也有缺点。虽然它仅使用几个标准 Windows 功能就完成了任务，允许非常明确和精细的文件系统写入，并且在非提升状态下运行——减少了用户需要接受过多提升提示或成为本地机器管理员的需求——但它也有一些真正的缺点，其中一些使其无法成为我们的最终设计： - 设置速度：根据工作区目录的拓扑结构，应用工作区 ACL 可能代价高昂。 - 占用空间：我们对开发者的系统应用了真实的 ACL，尽管占用空间并非特别具有侵入性，因为所有应用的 ACL 都与仅为沙箱使用的自定义创建的合成 SID 相关。 - 难以更改的语义：依赖 ACL 进行文件限制意味着更改沙箱语义的成本高昂且复杂。而在 macOS 上，我们可以动态更改用于生成 Seatbelt 配置的 .sbpl 文件的方式，Windows 沙箱可能需要缓慢且密集的操作来调整 ACL。 - 网络保护薄弱。如前所述，它是“建议性的”，肯定会被某些实现了自己网络堆栈的程序绕过，并且并非设计用于抵御对抗性代码。 前三个问题对于足够灵活以适应智能体流程的自定义沙箱实现来说是固有的。但网络抑制的情况则不同。除了恶意智能体能轻松规避基于环境的网络抑制之外，许多善意的代码/二进制文件也会仅仅因为不尊重环境代理变量，或者实现了自己的基于套接字的网络代码而规避它。我们认为这一方面足以考虑投资更好的沙箱模式。 为了获得更好的网络抑制，我们希望使用 Windows 防火墙，它允许我们阻止用户或程序的出站网络流量。不幸的是，我们无法有效地创建一个仅适用于由 Codex harness 生成的命令的功能性防火墙规则，原因如下： - Windows 不允许将防火墙规则与受限令牌的非主体身份匹配。这意味着我们无法将防火墙规则应用于“在其受限 SID 列表中包含我们合成 SID 的任何令牌”。 - 虽然我们可以创建一个与特定二进制文件匹配的防火墙规则，但这只允许我们限制 codex.exe 本身的网络功能。它不适用于智能体代表用户生成的进程，如 Git 或 Python 进程。 - 其他防火墙匹配维度也形状不符。用户范围的规则仍然匹配非提升设计中的真实 Windows 用户，而不仅仅是受限子进程。程序路径规则过于粗粒度：它们可以普遍阻止 codex.exe 或 python.exe，但不能阻止这一次沙箱调用的 python.exe。基于端口或地址的规则也完全是错误的策略。例如，我们不想阻止端口 443；我们想阻止这个特定受限进程树的任意出站访问。 为了将防火墙规则专门应用于我们的沙箱命令，我们需要将它们作为单独的主体运行，而不是作为“真正的”用户。这种方法引导我们走上了一条新道路，一条我们放宽了“不提升权限”约束的道路。 ## 重新设计：“提升沙箱” 沙箱的下一个迭代，也就是我们当前的实现，需要在设置时具有提升的管理员权限。因此，我将其称为“提升沙箱”。 在 Codex 在系统上生成命令的边界处，提升沙箱看起来像非提升沙箱。它仍然在受限令牌下运行子进程——类似地是一个 write_restricted 令牌，具有相同的受限 SID 列表 [Everyone, Logon, Synthetic]——然而，这个令牌的主体不再是实际的 Windows 用户，而是 Codex 自身创建的两个本地用户之一： - CodexSandboxOffline（防火墙规则针对的用户） - CodexSandboxOnline（防火墙规则不针对的用户） 这个看似微小的细节实际上对沙箱、谁可以使用它以及其设置和运行时执行的复杂性有着重大影响。它在视觉上与非提升原型相似，但引入了防火墙规则和一个专用的 Windows 用户，该用户实际运行命令。（然而，这些新概念的引入意味着在沙箱可以开始运行和保护命令之前，有更多的设置工作需要完成。） 非提升沙箱设计的设置步骤很简单，但相对较小： - 如果需要，创建一个合成 SID - 为 sandbox-write 合成 SID 应用 ACL 然而，提升沙箱有更多的工作要做。 - 如果需要，创建一个合成 SID - 如果需要，创建在线和离线沙箱用户 - 将新创建的用户凭据本地存储，并使用 Windows 数据保护 API (DPAPI) 加密，存储在沙箱用户无法实际读取的位置 - 创建防火墙规则，阻止 CodexSandboxOffline 用户的所有出站网络访问，或者如果已存在，验证其正确性 在设置阶段还有一个额外的问题。Codex 的沙箱预期具有与实际 Windows 用户等效的读取访问权限。在非提升沙箱中，受限令牌的主体 SID 是 Windows 用户，这实现了。然而，当主体成为新的 CodexSandbox 用户时，这并非免费获得。Windows 上的许多相关目录将…