OpenAI 披露 Codex 的 Windows 沙盒架构，重点解决编码智能体本地运行时的权限隔离与安全边界问题。
原文标题：OpenAI 为 Codex 智能体打造安全的 Windows 沙盒
原文作者：AI前线
冷月清谈：
他们评估过 Windows Sandbox、强制完整性控制等机制，但前者隔离性虽强，却难以直接访问开发者现有工具、代码仓库和工作环境，且并非所有 Windows 版本都支持。
OpenAI 最初采用“非提升权限沙盒”，结合 SID、ACL 和写入限制令牌，只允许 Codex 写入指定目录，并保护 Git 元数据等敏感路径。随后方案演进为“提升权限沙盒”，通过专用本地 Windows 账户与受限令牌运行命令，并用防火墙规则控制网络访问。
这套设计反映出编码智能体在真实开发场景中的核心挑战：既要足够自动化，又不能让智能体拥有无限制的本机权限。
怜星夜思：
2、Windows 原生安全机制为什么不能直接满足这类 AI 编码智能体的需求？是系统问题还是场景太新？
3、编码智能体的安全设计里，你觉得文件隔离更重要，还是网络隔离更重要？
4、如果未来 IDE 都内置智能体沙盒，开发者还需要懂这些底层权限机制吗？
原文内容
OpenAI 发布了旗下 Codex 编码智能体所使用的 Windows 沙盒架构 的详细技术细节，重点阐述了在微软操作系统上为兼顾安全性、可用性与开发者效率所做出的工程权衡。OpenAI 解释称，在发现现有的 Windows 隔离机制无法完全满足自主编码智能体的需求后，他们构建了一套自定义的沙盒方案。正如 OpenAI 提到，Windows 系统本身并没有一个能够直接与智能体工作负载安全执行环境映射的原生组件。
Codex 是 OpenAI 旗下的编码智能体，可通过命令行界面、IDE 扩展和桌面应用程序在开发者的本地机器上运行。由于该智能体可以执行命令、读取文件、修改源代码并执行开发任务，OpenAI 需要一种机制来限制其访问权限，同时尽量减少对开发者工作流程的干扰。据 OpenAI 技术团队成员 David Wiesen 介绍，用户此前面临着一个两难选择：要么需要逐一批准智能体的每一个操作，要么通过完全访问模式授予其不受限制的系统权限。
OpenAI 在 LinkedIn 的发布 帖子 中写道：
这套方案让运行在 Windows 系统上的 Codex 兼顾性能与安全性，开发者也能更放心地在实际工作场景中使用这款编码智能体。
OpenAI 评估了多种现有的 Windows 安全技术，包括 Windows Sandbox 和 强制完整性控制（Mandatory Integrity Control，MIC）。虽然 Windows Sandbox 通过一次性虚拟机提供了强大的隔离性，但 OpenAI 认为它并不适用，因为 Codex 需要直接访问开发者的工作环境、工具和代码仓库。此外，Windows Sandbox 并非所有 Windows 版本都支持，从而限制了它的使用场景。
第一个实现方案在内部被称为“非提升权限沙盒”（Unelevated Sandbox），它结合了 Windows 安全标识符（SID）、访问控制列表（ACL）和写入限制令牌。OpenAI 引入了一个合成安全标识符 sandbox-write，仅授予对指定目录（如当前工作区和手动配置的写入位置）的写入权限。敏感路径（包括 Git 元数据目录）则通过 ACL 强制执行保持受保护状态。
OpenAI 随后将系统重新设计成“提升权限沙盒”（Elevated Sandbox）。在部署过程中，沙盒会创建专术的本地 Windows 账户，包括 CodexSandboxOffline 和 CodexSandboxOnline。相关命令会在这些隔离账户下通过受限令牌运行。网络访问可以通过防火墙规则进行控制，从而在保留常用开发者工作流兼容性的同时严格划定文件系统和网络边界。
完整的沙盒架构（来源：OpenAI 博客文章）
该公告也引发了开发者对编码智能体安全影响的讨论。Marcus 在 X 平台上 评论 道：
这个沙盒架构简直就是幕后英雄。其他编码智能体都会随意读写你的文件系统，而运行在 Windows 上的 Codex 实现了环境隔离，你大可放心让它运行，无需时刻提防。
随着编码智能体越来越能够代表用户执行操作，供应商必须在严格的安全约束与流畅的自动化体验之间找到平衡。与传统应用程序不同，自主编码智能体需要访问源代码、开发工具和操作系统资源，又要维持有效的隔离边界。OpenAI 的方案也说明，现有操作系统原生功能需要整合与适配，才能适配这类新兴工作场景，兼顾可用性、兼容性与安全管控。
查看英文原文：
https://www.infoq.com/news/2026/06/codex-windows-sandbox-design/
会议推荐
