KK Blog

菜单

Administrator
Published on 2026-05-17 / 9 Visits
0
0

"Codex Windows 沙箱：OpenAI 安全编码环境架构内幕"

#权限提升#沙箱隔离#AI编码#Windows 沙箱#Codex#OpenAI#安全架构#Agent安全

当一个 AI Agent 可以在你的机器上执行任意 shell 命令时，问题不在于它会不会犯错，而在于你如何控制爆炸半径。OpenAI 的 Codex 赋予编码 Agent 正是这种能力：读取文件、写入代码、运行测试、安装依赖、执行 shell 命令。Agent 需要真实的系统访问权限才能完成有意义的工作，这也意味着如果出问题，它有真实的系统访问权限来造成真实的破坏。

2026 年 5 月，OpenAI 发布了一篇详细的工程博客文章，由技术团队成员 David Wiesen 撰写，记录了团队如何为 Codex 构建 Windows 沙箱。这篇文章是关于 AI 编码 Agent 安全架构的罕见窗口，揭示了一个重要事实：沙箱化 AI Agent 与沙箱化传统应用是根本不同的问题。OpenAI 在迭代了两种不同的架构后得到的方案，为任何构建让 AI Agent 与真实操作系统交互的系统的人提供了教训。

问题：为什么 Codex 需要沙箱

Codex 默认以真实用户的权限运行。编码模型告诉其 harness 在本地运行命令：跑测试、读写文件、创建 Git 分支。这既强大又危险。恶意的 prompt 注入、幻觉产生的命令、或者一个决定"清理"错误目录的模型，都可能删除源代码、修改系统配置、或向外部服务器泄露数据。

OpenAI 的默认模式试图平衡效果和安全性。Codex 可以读取几乎任何地方的文件，但只能在你的工作区（运行 Codex 的目录）内写入文件，除非你明确指定，否则没有网络访问权限。要自动执行这些约束，Codex 需要一个沙箱环境，一个由操作系统而非应用程序强制执行的约束环境。

在 macOS 上，Codex 使用 Apple 内置的沙箱机制 Seatbelt。在 Linux 上，它使用 seccomp 和 bwrap (bubblewrap) 的组合。这些都是成熟的、被广泛理解的内核级隔离工具。然而 Windows 并没有提供等效的能力。当 Wiesen 在 2025 年 9 月加入 Codex 工程团队时，Windows 用户面临两个糟糕的选择：手动批准几乎每条命令，这违背了自主 Agent 的初衷；或者启用完全访问模式，让 Agent 拥有无限制的控制权而没有任何监督。

为什么现有的 Windows 沙箱方案不适用

在构建自己的解决方案之前，Codex 团队评估了现有的 Windows 隔离机制。每一种都因为同一个根本原因而失败：它们是为已知、固定功能的应用设计的，不是为动态决定使用什么工具的 Agent 设计的。

AppContainer 是 Windows 原生沙箱，一种基于能力的隔离模型，专为预先明确知道需要访问哪些资源的应用设计。问题在于 Codex 不是一个功能固定的应用。它驱动开放式的开发者工作流：shell、Git、Python、包管理器、构建工具，以及 Agent 决定需要的任何其他二进制文件。AppContainer 提供强隔离，但适用的负载范围远比"让 Agent 像开发者一样操作"窄得多。

Windows Sandbox（基于 Hyper-V 的功能）创建一个完整的可丢弃虚拟机。它通过硬件虚拟化提供强隔离，但代价是：每条命令都产生 VM 启动开销，主机和客户机之间的文件共享复杂，VM 需要自己的开发环境副本。对于一个可能快速连续运行几十条短命命令的 Agent，延迟惩罚太高了。

Codex 团队需要介于两者之间的方案：隔离足够强以防止 Agent 逃逸，但足够轻量以支持真实的开发者工作流。他们自己构建了，分两次迭代。

迭代 1：非提升沙箱

第一个可用的原型组合使用现有的 Windows 概念来实现隔离，不需要管理员权限。设计目标很明确：Codex 不应该需要提示用户授予管理员权限才能设置或运行沙箱。

非提升沙箱聚焦于两个约束：文件写入和网络访问。

文件系统隔离方面，团队使用了从当前用户令牌派生的受限令牌。他们应用了 [Everyone, Logon, Synthetic] 的受限 SID 列表来创建一个 write_restricted 令牌。结合 Windows ACL（访问控制列表），这阻止了沙箱进程写入工作区以外的目录，同时仍允许读取。

网络隔离方面，做法更加临时。由于无法使用 Windows 防火墙（需要提权），团队通过环境变量让常见网络工具在子环境中以关闭状态失败：

HTTPS_PROXY=http://127.0.0.1:1
ALL_PROXY=http://127.0.0.1:1
GIT_HTTPS_PROXY=http://127.0.0.1:1
NO_PROXY=localhost,127.0.0.1,::1
GIT_SSH_COMMAND=cmd /c exit 1

他们在 PATH 前面加了一个小型 denybin 目录，并重新排序 PATHEXT，使 stub SSH 和 SCP 脚本先于真实二进制文件被解析。

这捕获了大量常规工具的网络流量，但本质上仍然是建议性的。进程可以忽略环境变量、绕过 PATH、或直接打开套接字。非提升沙箱作为合理的默认方案可以工作，但网络隔离在对抗压力下从根本上只是尽力而为。

迭代 2：提升沙箱

当前的实现需要在设置时授予管理员权限，因此被称为提升沙箱。关键的架构洞察是：提权只在设置时发生，正常运行时不需要任何提升权限。用户批准一次管理员访问，之后所有沙箱操作都在无提升权限下运行。

在 Codex 生成命令的边界上，提升沙箱看起来与非提升版类似。它仍然使用受限令牌运行子进程，SID 列表相同。关键区别在于：这个令牌的主体不再是实际的 Windows 用户，而是 Codex 自己创建的两个本地用户之一：

  • CodexSandboxOffline：被防火墙规则阻止所有出站流量
  • CodexSandboxOnline：不被防火墙规则阻止，当用户明确启用网络访问时使用

这个设计很精妙，因为它将网络隔离问题从"能否投毒足够多的环境变量"转变为"Windows 防火墙是否有效"，而 Windows 防火墙是经过实战检验的内核级安全边界。创建专用本地用户意味着沙箱有自己的安全身份，与用户的真实账户隔离。ACL、防火墙规则和登录权限都可以针对这个身份进行范围限定。

四层架构

最终架构由四个独立的二进制文件组成，每个都有明确的职责：

codex.exe 是主进程，执行 agent 循环的未提权 harness。它从不直接处理沙箱设置或提权操作。

codex-windows-sandbox-setup.exe 处理所有提权设置工作：创建两个本地沙箱用户、配置防火墙规则、设置本地安全策略、为沙箱会话创建私有桌面。将设置封装在独立二进制文件中有多个目的：仅在需要时跨越 UAC（用户账户控制）边界，保持 codex.exe 作为普通的未提权进程，防止 Windows 专用设置逻辑膨胀影响其他平台的 codex.exe，将较长的设置工作与主进程生命周期解耦，提供一个处理沙箱所需不同设置路径的单一位置。

codex-command-runner.exe 只做一件事：铸造受限令牌并启动请求的命令。团队没有让 codex.exe 自己完成整个流程（真实用户到沙箱用户到受限令牌到子进程），而是将流程拆分为两段。命令运行器架起了沙箱用户上下文与实际命令执行的受限令牌环境之间的桥梁。

子进程 在沙箱环境中运行，受受限令牌、专用用户的防火墙规则和基于 ACL 的文件系统边界约束。

Wiesen 引用了爱因斯坦的话："一切都应该尽可能简单，但不能更简单。"每一层只做一件事，系统的安全属性来自这些层的组合而非任何单一组件。

这个架构实际防止了什么

提升沙箱同时执行三重边界：

文件系统写入 被限制在工作区目录和任何明确配置的可写根目录。受限令牌结合 ACL 意味着沙箱进程在 Windows 权限层面就无法写入其他位置，即使 Agent 尝试也不行。

网络访问 在防火墙层面控制，绑定到专用沙箱用户身份。当 Codex 以默认离线模式运行时，防火墙阻止 CodexSandboxOffline 的所有出站连接。当用户为特定任务批准网络访问时，进程以 CodexSandboxOnline 身份运行，拥有不同的防火墙配置。

进程权限 受到约束，因为沙箱用户是标准本地用户，拥有最小权限。它无法安装系统级软件、修改其范围外的注册表、或访问其他用户的文件。

系统还支持 read-only 模式（Codex 可以检查文件但不能编辑任何内容或运行命令）和 danger-full-access 模式（移除所有边界）。可配置的批准策略（untrusted、on-request、never）决定 Codex 在跨越边界前何时需要暂停并询问用户。

这个设计对 AI Agent 安全的启示

Codex Windows 沙箱揭示了三个可以推广到其他产品的原则。

第一，沙箱化 AI Agent 与传统应用安全是不同的问题。Agent 的负载在设计上就是开放式的。它可能需要运行测试套件、安装包、编译代码、或执行自定义构建脚本。你无法预先枚举 Agent 需要的所有能力，这排除了像 AppContainer 这样的静态能力模型。沙箱必须足够强以包含未知行为，同时足够灵活以支持真实的开发者工作流。兼容性与执行力之间的张力塑造了每一个设计决策。

第二，提权应该是设置时的事件，而非运行时的要求。Codex 团队做出了明确的选择：只在初始配置时需要管理员权限。一旦沙箱用户、防火墙规则和安全策略就位，Agent 就完全在标准用户权限内运行。这是任何需要引导安全边界的系统的好模式：支付一次权限成本，然后一直在受限环境中操作。

第三，操作系统原生执行优于应用层建议性控制。从非提升沙箱（环境变量投毒、PATH 操纵）到提升沙箱（防火墙规则、专用用户、ACL）的转变，代表从"希望进程遵循我们的规则"到"操作系统强制执行我们的规则"的跃迁。对于可以运行任意代码的 AI Agent，这个区别是安全边界和建议之间的区别。

在更广泛的安全模型中的位置

Windows 沙箱是 Codex 多层安全架构的一层。在 Codex 的云环境中，Agent 在隔离的 OpenAI 托管容器中运行，采用两阶段运行时模型：设置阶段可以访问网络安装依赖，随后的 Agent 阶段默认离线运行。为云环境配置的密钥仅在设置阶段可用，在 Agent 阶段开始前被移除。

GPT-5.2-Codex 系统卡（发布在 OpenAI 部署安全中心）描述了额外的模型级缓解措施：针对有害任务和 prompt 注入的专门安全训练，结合产品级缓解措施如本文描述的沙箱。系统卡指出，GPT-5.2-Codex 是 OpenAI 在专业 CTF（夺旗赛）评估中表现最强的模型，部分原因是上下文压缩使其能够在多个上下文窗口中连贯工作。

对于本地运行 Codex 的组织，沙箱提供安全边界。对于云部署，容器隔离提供安全保障。两种情况的原则相同：Agent 在有边界的环境中运行，常规任务可以在明确限制内自主执行，跨越限制需要明确的用户批准。

其他 AI 编码工具如何处理这个问题

Codex 不是唯一需要执行代码的 AI 编码工具。以下是竞品的方法：

Claude Code（Anthropic）默认通过用户确认提示运行命令。它没有在 Windows 上实现操作系统级沙箱，而是依赖批准门控，用户必须在命令执行前确认。这对用户更安全，但需要大量小命令的工作流会更慢。

Cursor 在隔离的后端环境中运行代码执行（针对其 agent 模式），基本不触碰本地机器。代价是 Agent 无法像本地运行那样无缝交互用户的开发环境。

GitHub Copilot 主要作为代码建议工具而非自主 Agent 运行，因此面临不同的风险画像。当它确实执行代码时（如 Copilot Workspace 功能），使用沙箱化的云环境。

对比突显了 Codex 的独特定位：它需要同时具备真实的本地系统访问和强约束。其他工具通过限制其中一方来解决问题。

开发团队的实际操作指南

如果你在 Windows 上运行 Codex，提升沙箱是推荐配置。如果你的组织通过企业策略阻止本地用户创建或防火墙规则变更，需要与 IT 团队合作，允许 Codex 设置二进制文件执行这些特定操作。非提升沙箱作为后备方案可以工作，但网络隔离较弱。

关键配置在 config.toml 中：

[windows]
sandbox = "elevated"
sandbox_private_desktop = true

如果两种原生 Windows 沙箱模式在你的环境中都不工作，可以在 WSL2 中运行 Codex，它会使用 Linux 沙箱实现（seccomp + bwrap）。

对于大规模管理 Codex 部署的团队，沙箱架构意味着安全策略在操作系统层面而非应用层面执行。你可以使用标准 Windows 管理工具审计沙箱用户、防火墙规则和 ACL。安全边界是可检查和可测试的，这对于需要在部署前验证 AI 工具安全性的组织至关重要。

常见问题

Codex 尝试在工作区外写入会发生什么？ 受限令牌和 ACL 在操作系统层面阻止写入操作。Codex 收到权限拒绝错误并向用户报告失败。

提升沙箱能否被足够巧妙的 prompt 注入攻破？ 沙箱在操作系统层面运行，位于应用层之下。即使模型被欺骗生成恶意命令，这些命令也在沙箱用户上下文中执行，该上下文缺乏逃离配置边界的权限。主要剩余风险是社会工程：欺骗用户批准跨越沙箱边界的操作。

为什么不用 Docker 容器做隔离？ Windows 上的 Docker 依赖 WSL2 或 Hyper-V，引入与 Windows Sandbox 相同的 VM 开销。Codex 团队需要一个对单条命令增加最小延迟、同时仍执行真实操作系统级边界的方案。

沙箱在所有 Windows 版本上都工作吗？ 提升沙箱需要 Windows 10 Pro 或更高版本，支持本地用户创建和防火墙配置。Windows Home 版可能不支持所有必需功能。

参考资料

当一个人就是一家公司
"Codex Windows Sa...

Comment