Codex Windows沙箱解读：受限Token、双账户与防火墙如何组成安全边界

摘要

Coding Agent 为了运行测试、修改文件和调用开发工具，必须获得真实的本地执行能力。但如果直接继承用户权限，它也可能写入工作区之外、读取敏感文件或把数据发送到网络。OpenAI 在 2026 年 5 月披露了 Codex Windows 沙箱的设计演进：最初采用合成 SID、ACL 和 Write-Restricted Token 限制文件写入，再从"代理环境变量阻断网络"升级为双本地账户、Windows Firewall、独立 Setup 与 Command Runner 的组合架构。本文分析这些机制如何协作，以及为什么 Agent 安全不能只靠提示词和用户审批。

背景：Coding Agent 需要"能工作但不能越界"

Codex 在开发者电脑上运行，模型可以要求 Harness 执行 Shell、Git、Python、包管理器和构建工具。理想默认模式是：能够读取多数本地文件，只在工作区和明确配置的 writable_roots 中写入，默认不能访问互联网。

这种边界必须由操作系统执行。Prompt 只能表达策略，无法阻止恶意脚本、依赖包或子进程绕过规则。沙箱还必须覆盖整个进程树，否则 Agent 启动的 Python、Git 或测试程序仍会继承完整用户权限。

macOS 有 Seatbelt，Linux 可使用 seccomp 或 bubblewrap；Windows 没有一个现成机制能直接表达"像开发者一样运行任意工具，但只允许写指定目录且默认断网"。

技术要点一：现有 Windows 方案为什么不合适

OpenAI 评估了 AppContainer、Windows Sandbox 和 Mandatory Integrity Control。

AppContainer 提供强能力隔离，但更适合预先知道全部资源需求的单一应用。Coding Agent 会动态调用 Shell、Git、Python 和各种构建工具，工作负载过于开放。

Windows Sandbox 是一次性轻量虚拟机，隔离更强，但 Codex 需要直接操作用户真实仓库和工具环境。宿主与虚拟机之间的同步、配置和桥接会增加大量复杂度，而且 Windows Home 不提供该能力。

MIC 可以把进程设为低完整性，并将可写目录标记为低完整性。但这会改变真实工作区的信任语义：不仅 Codex，所有低完整性进程都可能写入该目录。影响范围过宽，不适合作为精确沙箱策略。

技术要点二：合成 SID 与 Write-Restricted Token

第一版"非提权沙箱"使用合成 SID sandbox-write 表示沙箱写权限，并通过 ACL 将它授权给当前工作目录和额外 writable_roots。

同时，对工作区内仍需只读的目录显式拒绝写入，例如：

.git；
.codex；
.agents。

命令在 Write-Restricted Token 下执行。Windows 对写操作进行双重校验：正常用户身份必须允许写入，受限 SID 列表中也至少有一个 SID 获得授权。只有两个条件都满足，写入才成功。

这套机制的优势是粒度明确，且不需要管理员权限。但它需要修改宿主文件系统 ACL。大型仓库应用 ACL 可能较慢，策略变化也可能触发昂贵的重写。

技术要点三：环境变量不能构成网络安全边界

早期方案无法在非管理员模式下配置 Windows Firewall，因此尝试把常用网络工具导向失败路径，例如设置无效 HTTPS_PROXY、ALL_PROXY、Git Proxy，禁用 Git SSH，并在 PATH 前放置假的 SSH/SCP。

这种方式能阻止大量正常工具流量，却只是建议性限制。程序可以忽略代理变量、绕过 PATH，或直接创建 Socket。即使代码没有恶意，使用自定义网络栈的合法程序也可能绕过。

这说明网络隔离不能以"常见工具会遵守配置"为安全假设。只要目标是防止数据外传，策略就必须由操作系统网络层强制执行。

技术要点四：双本地账户让防火墙可以准确匹配

最终"提权沙箱"在安装阶段创建两个独立 Windows 用户：

CodexSandboxOffline：匹配防火墙规则，禁止出站网络；
CodexSandboxOnline：不匹配该阻断规则，用于明确允许联网的操作。

命令不再以真实用户作为 Token 主体，而以对应沙箱账户运行，同时继续叠加 Write-Restricted Token 和合成 SID。

这个变化解决了 Windows Firewall 的匹配问题。防火墙无法根据 Restricted Token 中的非主体 SID 精确识别某次沙箱调用，也不能只阻断"这一次由 Agent 启动的 python.exe"。使用独立账户后，整个进程树可以按主体统一阻断网络。

代价是首次设置需要管理员权限：创建账户、加密保存凭据、配置并校验防火墙规则，以及补充必要的读取 ACL。

技术要点五：为什么需要独立 Setup 与 Command Runner

架构最终拆成四层：

codex.exe：保持普通、非提权 Harness；
codex-windows-sandbox-setup.exe：只在安装或修复时跨越 UAC 边界；
codex-command-runner.exe：以沙箱账户身份创建受限 Token；
真正执行用户命令的子进程。

codex.exe 不能可靠地从真实用户侧使用 CreateProcessAsUserW 启动受限沙箱账户进程，因此先通过 CreateProcessWithLogonW 启动 Runner。Runner 已位于沙箱账户边界内，再读取自身 Token、创建最终 Restricted Token，并启动子进程。

这种拆分把高权限设置与日常命令执行分开，缩小了提权代码面，也避免 Windows 专用逻辑进入所有平台的主程序。

研发视角：安全设计的核心不是"禁止更多"

Agent 沙箱需要同时满足三个目标：权限由 OS 强制、策略覆盖所有后代进程、正常开发流程仍可运行。过强隔离会导致每个命令都请求批准，最终诱导用户开启 Full Access；过弱隔离则只是安全外观。

这套设计体现了几条可复用原则：

文件写入使用允许列表，而不是枚举禁止目录；
网络默认离线，联网使用不同身份或明确升级；
高权限操作集中到一次性 Setup；
运行时子进程使用独立主体，便于防火墙和审计；
将 .git、Agent 配置和策略目录视为更高信任级别；
权限必须沿进程树继承，不能只限制入口程序。

实践建议

企业内部 Agent 应先定义读、写、执行、联网四类权限矩阵，并为每次升级保留原因和审计记录。

测试不能只验证"正确命令被允许"，还要加入绕过场景：直接 Socket、绝对路径执行、子进程链、符号链接、路径穿越、工作区内只读目录和规则失效后的 Fail-Closed 行为。

安装阶段应验证账户、ACL 和防火墙规则是否完整；运行阶段若检测到配置漂移，应停止执行或要求修复，不能静默退化。

凭据应使用操作系统密钥保护，并确保沙箱账户无法读取。在线和离线身份还应使用不同日志标签，方便追踪网络授权是否被滥用。

风险与限制

该方案仍会修改本地账户、ACL 和防火墙配置，安装、升级、卸载和企业策略兼容性都需要严格处理。给沙箱账户补充读取 ACL 也可能较慢，并且只能是对复杂 Windows 目录权限的尽力覆盖。

独立账户与防火墙能显著强化边界，但不等于完整虚拟机隔离。内核漏洞、错误 ACL、特殊设备、命名管道或其他本地 IPC 仍需要单独评估。

官方文章说明了架构选择，但没有给出完整攻击面评估、性能开销和所有兼容性数据。因此生产部署仍应结合组织自己的终端安全策略和红队测试。

结语

Codex Windows 沙箱的关键经验是：Agent 安全不是找到一个万能 API，而是组合身份、Token、ACL、防火墙和进程边界。真正可靠的默认模式既要让 Agent 能完成开发任务，也要保证越界行为由操作系统拒绝，而不是寄希望于模型自律或工具主动遵守环境变量。

参考来源

OpenAI Engineering：Building a safe, effective sandbox to enable Codex on Windows
https://openai.com/index/building-codex-windows-sandbox/