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 有 SeatbeltLinux 可使用 seccomp 或 bubblewrapWindows 没有一个现成机制能直接表达“像开发者一样运行任意工具但只允许写指定目录且默认断网”。技术要点一现有 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保持普通、非提权 Harnesscodex-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 EngineeringBuilding a safe, effective sandbox to enable Codex on Windowshttps://openai.com/index/building-codex-windows-sandbox/