我在 2025 年 9 月加入 Codex 工程团队时，Codex Windows 版还未实现沙箱功能。这意味着 Windows 用户在使用 OpenAI 的编程智能体 (coding agent) 时，需要在以下两种不理想的选项中做出选择：
作为我们的编程智能体，Codex 运行在开发者的笔记本电脑上 — 无论是通过 CLI、IDE 扩展还是桌面应用程序。它负责管理键盘前的用户与在云端进行推理的模型之间的对话。
默认情况下，Codex 以真实用户的权限运行，这意味着它拥有和用户完全相同的操作能力。这很强大，但也伴随着潜在的危险。编程模型可能会指示框架 (harness) 在本地运行命令，从运行测试、读取或编辑文件，到创建 Git 分支。因此，Codex 的默认模式试图在“有效性”与“安全性”之间找到恰当的平衡。在这种默认模式下，Codex 可以读取几乎任何地方的文件，并在你的工作空间（即运行 Codex 的目录）内写入文件，同时除非你明确指定，否则它无法访问网络。为了在安全范围内自动实现对文件写入和网络访问的约束，Codex 需要一个能够真正执行这些限制的沙箱环境。
沙箱是一个受限的执行环境。当开发者使用 Codex 时，其计算机的操作系统会启动一个运行权限降低的命令，并且这些限制会向下传递到进程树 (process tree)。每一个 Codex 命令从一开始就处于沙箱之中，且其所有子进程 (descendant process) 也都保持在相同的边界内。
为了实现行之有效的沙箱，Codex 需要利用计算机操作系统强制执行的隔离特性。一些操作系统提供了能够很好实现这一功能的工具，例如 macOS 上的 Seatbelt，以及 Linux 上的 seccomp 或 bubblewrap。然而，Windows 目前并未内置此类功能。
若 Windows 用户希望享受到与其他平台一样安全且顺畅的 Codex 使用体验，则需要实现自己的沙箱方案。
Windows 确实提供了一些用于隔离的工具和原语。虽然它们都无法完全满足我们的需求，但我们评估了过多种潜在的解决方案，具体包括 AppContainer、Windows Sandbox 以及 Mandatory Integrity Control 标签。
AppContainer
Windows Sandbox
Mandatory Integrity Control (MIC) 完整性标签
在评估完所有方案并确认均不可行后，我们开始设计自己的解决方案，以便为 Windows 用户带来出色的 Codex 体验。
我们的第一个可用原型结合了多种 Windows 概念和工具，从而实现了所需的隔离。从一开始，我们的目标之一就是让沙箱在不要求提权 (elevation) 的情况下运行，这意味着 Codex 无需为了配置或运行沙箱而向用户申请管理员权限。这就需要我们想出办法，对两件事施加合理的限制：文件写入和网络访问。
如果对文件写入完全不加限制，就会带来安全问题；但如果限制得过于严苛，沙箱又需要频繁请求用户审批，从而损害用户的生产力。为了解决这一问题，我们依赖了两个关键的 Windows 构建基块：安全标识符 (SID) 和写入受限令牌 (write-restricted token)。
SID，即安全标识符 (security identifier)，是 Windows 与权限绑定的身份证明。每个用户都有一个 SID，各种组有 SID，甚至单次登录会话也会获得专属的 SID。例如，当前登录的会话可能拥有类似于 S-1-5-5-X-Y 的 SID，而本地管理员组被分配的 SID 可能是 S-1-5-32-544。
Windows 还允许创建合成 SID，它们并不对应真实的用户，但仍能出现在访问控制列表 (ACL) 中。ACL 负责定义谁可以对特定的文件或目录进行读取、写入或执行操作。这使得 SID 成为我们沙箱中一个非常有用的原语：我们可以创建仅供 Codex 沙箱使用的专属 SID，而不会干扰计算机上的其他任何东西。
在 Windows 中，进程令牌 (process token) 是一种安全对象，用于定义运行中进程的身份和特权。它们决定了进程可以执行哪些操作。而写入受限令牌 (write-restricted token) 是一种特定类型的进程令牌，它会让 Windows 在处理写入操作时执行额外的访问检查。
为了成功进行写入，必须通过以下两项检查：
在实际应用中，这些检查让我们可以利用 ACL 来精确定义沙箱可以在文件系统的哪些位置进行修改，从而为我们提供了写入操作所需的细粒度控制。
结合 SID 和写入受限令牌，“未提权沙箱”的工作流程如下：
sandbox-write 的合成 SID。sandbox-write SID 被授予对以下位置的写入、执行和删除权限：config.toml 中配置的任何其他 writable_roots<cwd>/.git<cwd>/.codex<cwd>/.agentsEveryone、当前登录的会话 SID 以及 sandbox-write 合成 SID。这一流程有效地解决了限制文件写入的问题，并且看起来很有前景。接下来，我们需要一个能够限制沙箱网络访问的解决方案。
限制网络访问是沙箱设计的重要组成部分。如果不加限制，恶意代码就可能将计算机中的数据窃取并上传到互联网。由于我们希望避免提权要求，因此在强力阻断网络流量方面的选择非常有限。我们原本想使用的工具（如 Windows 防火墙）通常都需要管理员权限才能配置。
在无法使用 Windows 防火墙的情况下，我们只能尽力限制我们所能控制的部分。我们尝试让子环境对开发者实际使用的各类网络工具表现为“故障关闭” (fail-closed) 状态，从而使沙箱内的 Git 命令、包安装程序等运行失败，迫使用户必须对任何面向互联网的操作进行审批。我们的核心思路是“毒化”那些显而易见的逃逸通道：将具备代理感知能力的流量重定向到一个死端（无效端点），让 Git 的 HTTP(S) 传输层也执行同样的操作，并使基于 SSH 的 Git 操作立即失败。此外，我们还在 PATH 的最前端添加了一个小型的 denybin 目录，并重新调整了 PATHEXT 的顺序，以便让 SSH 和 SCP 存根脚本先于真实的二进制文件被解析执行。
作为参考，以下是我们用于限制网络访问的部分具体环境覆写配置：
HTTPS_PROXY=http://127.0.0.1:9ALL_PROXY=http://127.0.0.1:9GIT_HTTPS_PROXY=http://127.0.0.1:9NO_PROXY=localhost,127.0.0.1,::1GIT_SSH_COMMAND=cmd /c exit 1这种做法虽然拦截了大量由常规工具驱动的流量，但它仍然只是建议性的。任何进程都可以忽略环境变量、绕过 PATH，或者直接建立套接字 (socket) 进行连接 — 这带来很大风险。
与任何复杂的软件实现一样，第一个原型也同时具备优缺点。虽然它仅靠几项标准的 Windows 功能就完成了任务，实现了非常明确且细粒度的文件系统写入限制，并且能够在未提权的状态下运行（让用户免于频繁点击烦人的提权提示，也无需拥有本地计算机的管理员权限），但它也存在一些缺陷，其中部分缺陷甚至使其无法成为我们的最终设计方案：
.sbpl 文件的生成方式；而在 Windows 上，调整 ACL 则可能需要执行一次缓慢且繁重的操作。前三个问题是定制沙箱实现所固有的代价 — 因为沙箱必须具备足够的灵活性来应对智能体工作流。然而，网络抑制的情况却截然不同。
除了恶意智能体可以轻松绕过基于环境变量的网络抑制之外，许多出于好意的正常代码或二进制文件，只要它们不遵循环境代理变量，或者实现了自己基于套接字 (socket) 的网络代码，也会轻易绕过这一限制。我们认为，仅凭这一点就足以让我们决定去投入研发更好的沙箱模式。
为了获得更好的网络抑制效果，我们希望使用 Windows 防火墙，因为它允许我们阻止用户或程序的出站网络流量。然而，由于以下几个原因，我们无法有效创建一条仅适用于由 Codex 框架 (harness) 启动的命令的有效防火墙规则：
codex.exe 本身的网络访问。它无法应用于智能体代表用户启动的其他进程，例如 Git 或 Python 进程。codex.exe 或 python.exe，但无法阻止本次被沙箱隔离的特定 python.exe 调用。基于端口或地址的规则在策略上也是完全错误的。例如，我们并不想阻止 443 端口，而是想阻止这个特定受限进程树的任意出站访问。为了将防火墙规则专门应用于我们沙箱化的命令，我们需要让它们作为一个独立的外部主体 (principal) 运行，而不是作为“真实”用户。这种方法引领我们走上了一条新路径。在这条路径上，我们放宽了“不提权”这一限制条件。
沙箱的下一次迭代（即我们目前的实现方案）在配置时需要管理员提权权限。因此，我将其称为“提权沙箱 (elevated sandbox)”。在 Codex 向系统启动命令这一环节上，提权沙箱与未提权沙箱看起来非常相似。它仍然在受限令牌 — 同样是包含 [Everyone, Logon, Synthetic] 相同受限 SID 列表的 write_restricted 令牌 — 下运行子进程。然而，该令牌的主要身份不再是真实的 Windows 用户，而是由 Codex 自身创建的两个本地用户之一：
CodexSandboxOffline（受防火墙规则管辖的用户）CodexSandboxOnline（不受防火墙规则管辖的用户）这个看似微小的细节，实际上对沙箱、其适用人群，以及配置和运行时的执行复杂度产生了巨大影响。
它在视觉结构上与未提权的原型相似，但引入了防火墙规则和负责实际运行命令的专属 Windows 用户。（然而，这些新概念的引入，意味着在沙箱能够启动运行并开始保护命令之前，还有更多的配置工作要做。）
未提权沙箱设计的配置步骤非常简单，且工作量相对较小：
然而，提权沙箱需要做更多的工作：
CodexSandboxOffline 用户所有出站网络访问的防火墙规则；如果规则已存在，验证其是否正确在配置阶段还有一个额外的复杂问题。Codex 的沙箱预计需要拥有与真实 Windows 用户等同的读取权限。在未提权沙箱中，由于受限令牌的主要身份 SID 就是该 Windows 用户，这一需求自然得以实现。然而，当该主体成为新的 CodexSandbox 用户时，这并非毫无代价。Windows 上的许多相关目录会向“Authenticated Users”（已认证用户）授予读取/执行权限。一个显著的例子就是用户的个人资料 (profile) 目录。默认情况下，Windows 用户无法读取其他 Windows 用户的个人资料目录，因此在许多场景下，即使是简单的文件读取操作也会失败。
为了解决这个问题，我们在沙箱配置流程中增加了另一层机制，用于在相关读取 ACL 可能尚不存在的情况下，向沙箱用户授予读取 ACL。例如，针对一些常用的 Windows 目录：
C:\Users\<real-user>C:\Windows\C:\Program Files\C:\Program Files (x86)\C:\ProgramData\由于这个目录列表是尽力而为的，且在每个目录上配置 ACL 的开销可能非常高，因此我们采用异步方式运行该逻辑，这样对用户产生阻塞的沙箱配置步骤就无需等待它们执行完毕。
我们将配置逻辑封装在独立的二进制文件中，部分原因是为了仅在需要时才跨越 UAC 边界。但更深层次的原因在于架构设计：沙箱配置与 codex.exe 有着本质上不同的职责。将沙箱配置逻辑保留在专属的二进制文件中，可以让 codex.exe 保持为普通的未提权框架 (harness)；防止仅适用于 Windows 的配置机制导致其他平台上的 codex.exe 体积膨胀；将运行时间较长的配置工作与主进程的生命周期解耦；并为我们提供一个统一的地方来处理沙箱所需的各种不同配置路径。
由于 Windows 用户与令牌登录边界的工作机制限制，我们无法再像未提权沙箱那样，直接创建一个受限令牌并在其下生成进程。为了真正以不同的 Windows 用户身份生成命令，我们最初设想的流程如下：
codex.exe 作为真实的 Windows 用户运行。随后，Codex 依次执行以下操作：LogonUserW(...)。CreateRestrictedToken(...)。CreateProcessAsUserW(...) 来启动最终的子进程。在实际应用中，由于 CreateProcessAsUserW(...) 存在特权壁垒，这一设想的流程无法正常工作。这意味着 codex.exe 虽然可以为沙箱用户创建受限令牌，但它无法从边界的真实用户一侧，稳定地利用该令牌启动子进程。我们需要一个已经作为沙箱用户运行的进程 — 这样就能让限制步骤和最终启动进程发生在边界的沙盒用户一侧，而不是真实用户侧。
这一需求促成了 codex-command-runner.exe 的诞生，这是一个全新的二进制文件，其唯一职责就是生成受限令牌并启动请求的命令。我们没有让 codex.exe 自身独立完成整个流程（真实用户 → 沙箱用户 → 受限令牌 → 子进程），而是将流程一分为二：
第 1 部分
codex.exe 调用 CreateProcessWithLogonW(...)，以沙箱用户的身份启动 codex-command-runner.exe，此时暂不使用受限令牌。第 2 部分
OpenProcessToken(GetCurrentProcess(), ...) 会打开运行器自身的令牌，该令牌已然属于沙箱用户。GetTokenInformation(...) 来提取沙箱登录 SID，然后调用 CreateRestrictedToken(...) 来构建最终的受限令牌。CreateProcessAsUserW(...)，从而启动真正的子进程。阿尔伯特·爱因斯坦曾说：“一切都应该尽可能简单，但不能过于简单。”秉承这一原则，我们的设计恰到好处地解决了每一个问题。最终的架构由我们前面提到的四个层级组成：
codex.exe 本身codex-windows-sandbox-setup.exe：用于处理所有与提权配置相关的工作codex-command-runner.exe：用于在受限令牌下运行命令当我最初着手这个项目时，我并没有一个明确的预判，不知道它最终会走向何方。我的方法是，首先在 Codex 与操作系统之间的边界上构建沙箱功能。这种方法与 Codex 在 macOS 和 Linux 上的沙箱实现方式非常相似。
随着我对 Windows 提供的特定工具有了更深入的了解，并通过数十次在安全性与易用性之间进行权衡的决策，系统逐渐演变成了现在的形态 — 包含多个二进制文件、定制用户、防火墙规则、提权的配置步骤、异步进程等。
这并不是一个特别简单的系统，但每一处复杂性的引入都是出于必然，目的是为了构建一个既安全又尽可能不打扰用户的沙箱环境。
为了给 Windows 上的 Codex 用户带来优秀的体验，我们的目标是打造一个既安全又不牺牲实用性的东西 — 毕竟使用 Codex 的核心意义，就在于让智能体能够在无需你持续关注的情况下独立完成工作。
这个项目给我们的最大启示之一，是 Windows 并没有直接为我们提供一个能够完美对应“安全自主编程智能体”的原语。我们组合了多种工具和概念，才构建出一个连贯的整体。一些早期的想法最终被证明是死胡同，而最终的设计方案，则是对那些各自解决了部分问题的早期原型进行融合的产物。
另一个教训是，编程智能体的安全问题与更传统的应用程序安全有着本质的不同。Codex 必须适用于真实的开发者工作流。我们的工程重心，始终是在兼容智能体工作负载与保障真实强制力之间找到平衡。这种博弈决定了最终设计方案中的各种权衡与取舍。
想体验 Codex 沙箱的实际运行效果吗？不妨亲自尝试一下。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。