夜雨聆风在 macOS 和 Linux 上，Codex 有系统级沙箱保护；而在 Windows 上——什么都没有。OpenAI 工程师不得不从零开始造轮子。
项目地址：OpenAI Codex[1] | 官方博客：Building a safe, effective sandbox to enable Codex on Windows[2]
给 AI Agent 一个在你电脑上跑命令的权限，等于给它一把你家所有房间的钥匙。
这不是比喻。OpenAI 的 Codex 默认以真实用户权限运行——它能读你几乎所有文件、写你工作区里的任何文件、甚至创建 Git 分支。当你的 AI 助手说"帮我跑一下测试"时，它背后可能正在执行几十条本地命令。
问题来了：macOS 有 Seatbelt，Linux 有 seccomp 和 bubblewrap，而 Windows——没有现成的沙箱。
OpenAI 的工程师团队在 2025 年 9 月加入 Codex 项目后发现：Windows 用户在用 Codex 时，只能在"逐个确认每条命令"和"完全放开所有权限"之间二选一。这根本不是一个可持续的方案。
于是他们做了一件工程师最该做的事：自己造一个。
为什么 Windows 没有现成方案可用？
OpenAI 团队先后评估了三种 Windows 原生隔离方案，全部不合格。
先看看各操作系统的沙箱能力对比：
这张图说明了一个残酷的现实：Windows 在 AI Agent 沙箱方面几乎是"裸奔"状态。macOS 和 Linux 在各项能力上都达到了 80% 以上，而 Windows 在自研方案之前，各项能力只有 10%-30%。这也是为什么 OpenAI 必须从零开始。
AppContainer：隔离太强，兼容性太差
AppContainer 是 Windows 原生的能力型沙箱，隔离强度确实高。但它的核心假设是：应用事先就知道自己需要访问什么。
Codex 不是这样。它需要驱动开放的开发者工作流——shell、Git、Python、包管理器、构建工具，以及 Agent 决定使用的任何二进制文件。AppContainer 的隔离范围太窄，根本罩不住"让 Agent 像一个开发者那样工作"这个需求。
简单说：AppContainer 是给单一应用设计的，不是给万能 Agent 设计的。
Windows Sandbox：强隔离，但不可用
Windows Sandbox 是微软自家的轻量级 VM，隔离边界非常强。但它有两个致命问题：
- • 无法直接操作用户文件：Codex 需要在用户的实际代码仓库上工作，而不是在一个隔离的 VM 里
- • Windows Home 版本不支持：大量开发者用的就是 Home 版
这就像你要修房子，微软给了你一个独立的工地——但工地和你家完全不连通。
MIC 完整性标签：理论完美，实际危险
Mandatory Integrity Control (MIC) 的思路很优雅：把 Codex 进程设为"低完整性"，把工作区目录也标记为"低完整性"，Windows 就会自动阻止低完整性进程写入其他目录。
但问题在于：标记工作区为低完整性，不只会影响 Codex——它会改变整个系统的信任模型。
任何低完整性进程都能往那个目录写东西。用户的真实代码仓库变成了一个"低权限陷阱"，这对整台机器的安全意义是不可接受的。
OpenAI 的自研方案：四个 Windows 原语拼装出的沙箱
既然现成方案都不行，OpenAI 团队用四个 Windows 安全原语（security primitives），从零拼出了一个沙箱。
从这张雷达图可以看到：OpenAI 的自研方案在兼容性和免管理员权限上显著优于所有原生方案，同时保持了足够高的隔离强度。
核心构件一：SIDs + Write-Restricted Token
这是沙箱的文件系统写保护基础。
SID（Security Identifier）是 Windows 用来标识身份的。OpenAI 的做法很聪明：为 Codex 沙箱创建合成 SID——这个 SID 不对应任何真实用户，只出现在 ACL 中。
然后用 Write-Restricted Token 来限制写权限：
# 伪代码示意：创建一个写受限的进程令牌
# 1. 为 Codex 沙箱创建专用 SID
sid = CreateSidForSandbox("codex-sandbox-sid")
# 2. 用这个 SID 创建工作区目录的 ACL
# → 只有携带此 SID 的进程能写这个目录
SetAcl(workspace_dir, sid, WRITE_ACCESS)
# 3. 创建 Write-Restricted Token
# → 任何写入操作都需要额外的 SID 检查
token = CreateWriteRestrictedToken(parent_token)
token.restrictSids = [sid]Write-Restricted Token 的工作原理是：Windows 在每次写操作时做一次额外检查——不仅看普通 ACL，还要看这个 Token 的 Restricting SIDs 列表。如果你的 SID 不在目标对象的 ACL 中，写入就会被拒绝。
关键设计选择：不用管理员权限。整个沙箱在普通用户权限下运行，不需要 UAC 提权。
核心构件二：Job Object
解决了文件写入，接下来要解决进程管理。
Job Object 是 Windows 的进程组管理机制。OpenAI 用它来：
- • 确保所有子进程都在沙箱内：Codex 启动的 shell、Python 脚本、构建工具——所有后代进程都被 Job Object 约束
- • 防止沙箱逃逸：即使 Agent 试图
CreateProcess启动新进程，新进程也会自动被 Job Object 捕获 - • 资源限制：可以设置 CPU、内存上限，防止 Agent 失控
# 伪代码示意：Job Object 进程树管控
# 1. 创建 Job Object
job = CreateJobObject(NULL, "codex-sandbox-job")
# 2. 设置限制（可选）
SetInformationJobObject(job, JOBOBJECT_LIMITS, {
memory_limit: 4GB,
cpu_rate: 80%
})
# 3. 将沙箱主进程加入 Job
AssignProcessToJobObject(job, sandbox_pid)
# 4. 关键：设置 JOB_OBJECT_LIMIT_BREAKAWAY_OK = false
# → 所有子进程自动继承 Job 约束，无法逃逸核心构件三：Windows Filtering Platform (WFP)
文件写限制了，进程树管控了，但 Agent 还能联网——这可能泄露数据、下载恶意代码、或者做其他未授权操作。
WFP 是 Windows 的网络过滤框架，OpenAI 用它来实现细粒度网络控制：
- • 默认禁止所有出站连接
- • 允许用户通过配置白名单特定域名或端口
- • 在网络层做拦截，而不是在应用层——更底层、更难绕过
核心构件四：ACL 文件系统隔离
最后一环是读权限的精细控制：
- • 工作区目录：可读可写（通过上面的 SID + Write-Restricted Token 实现）
- • 系统目录：只读
- • 用户其他目录：只读或不可访问
- • 所有权限通过 ACL 绑定到沙箱专用 SID，不影响主机其他进程
这四层构成了一个完整的沙箱：最外层管控进程树，中间层控制写权限和网络，最内层用 ACL 做细粒度文件隔离。
技术选型决策链
整个选型过程不是一拍脑袋就定了的。OpenAI 团队走了一条完整的决策链：
这条决策链的核心教训是：在安全领域，"足够好"不等于"能用"。 AppContainer 隔离够强，但兼容性不够；Windows Sandbox 兼容性好，但隔离边界不对；MIC 理论上最优雅，但语义影响太大。
最终方案是组合拳——每个原语负责一个维度的管控，合在一起才构成完整的沙箱。
对开发者的实际影响
这篇文章虽然讲的是 OpenAI 的内部工程实践，但对每个在 Windows 上用 AI 编码工具的开发者都有直接意义。
你该关注什么
- • 权限模型：了解你的 AI 工具到底在什么权限下运行。"以用户权限运行"意味着它能做你能做的一切——包括删文件、发邮件、装软件
- • 沙箱是否存在：不是所有 AI 工具都有沙箱。Codex 在 Windows 上直到 2026 年才有了一个完整的沙箱实现
- • 网络控制：AI Agent 能否联网？能访问哪些域名？这些问题决定了数据泄露的风险边界
如果你也在做类似的事
如果你正在构建一个需要在用户机器上运行命令的 AI 工具，OpenAI 的方案提供了一些可复用的思路：
# Codex Windows 沙箱设计原则总结
sandbox_design:
- 不用管理员权限：普通用户即可运行
- 不依赖 VM：直接在主机上隔离
- 组合使用多个安全原语：没有银弹，要组合拳
- 保持兼容性：Agent 需要能运行任意开发者工具
- 语义最小化：不改变主机已有的安全模型当前限制
OpenAI 自己也承认，这个方案还有一些限制：
- • 仅支持 Windows 10 及以上版本
- • 某些极端场景下可能需要用户授权
- • 与部分第三方安全软件可能存在冲突
写在最后
OpenAI 这篇博客最值得学习的地方，不是他们最终造出了什么，而是他们坦诚地讲了为什么其他方案不行。
在工程实践中，"为什么不用 X"往往比"为什么用 Y"更有价值。AppContainer 不够通用、Windows Sandbox 不够灵活、MIC 语义影响太大——这些失败评估本身就是一个完整的技术案例。
对于每个在 Windows 上构建安全沙箱的工程师来说，这篇文章就是一张现成的排雷图。
你觉得 AI Agent 的安全沙箱应该是 OS 层面的责任，还是应用层面的责任？ 欢迎在评论区聊聊。
本文基于 OpenAI 官方博客 Building a safe, effective sandbox to enable Codex on Windows 整理，发布日期：2026-05-13。文中代码为简化示意，非原始实现。
引用链接
[1] OpenAI Codex: https://openai.com/codex/
[2] Building a safe, effective sandbox to enable Codex on Windows: https://openai.com/index/building-codex-windows-sandbox/
