bingdada本文详细介绍了OpenAI工程团队为Windows版Codex构建自定义沙箱的历程。面对现有Windows隔离工具的不足，团队从零开始设计并实现了无需管理员提权的沙箱方案，在保障安全的同时提升了开发体验。
2025年9月，当我加入Codex工程团队时，发现Windows版的Codex尚未实现沙箱功能。这意味着Windows用户在使用OpenAI的编程代理时，只能在两种不理想的选项之间做出选择：要么批准几乎每条命令（甚至包括读取操作），效率低下且烦人——毕竟使用Codex的一大好处就是不必亲自处理所有繁琐工作；要么启用“完全访问模式”，让Codex无需审批或限制即可运行所有命令，虽然消除了操作摩擦，却牺牲了监督控制。
Codex作为我们的编程代理，运行在开发者的笔记本电脑上——无论是通过CLI、IDE扩展还是桌面应用。它管理着键盘前的人类用户与云端模型之间的对话，以完成推理任务。默认情况下，Codex以真实用户的权限运行，这意味着它可以执行用户能做的所有操作。这种能力既强大又潜在危险。编程模型可能会指示执行器在本地运行命令，从运行测试、读取或编辑文件，到创建Git分支，因此Codex的默认模式试图在有效性与安全性之间找到恰当的平衡。该默认模式允许Codex几乎在任何位置读取文件，并在工作区（即运行Codex的目录）内写入文件，除非用户明确指定，否则无法访问互联网。为了实现这种在安全范围内自动限制文件写入和网络访问的能力，Codex需要一个真正实施这些约束的沙箱环境。
沙箱是一种受限的执行环境。当开发者使用Codex时，其计算机操作系统会以降低的权限启动命令，这些约束会沿着进程树向下传播。每个Codex命令从一开始就被沙箱化，所有子进程都保持在相同的边界内。
要实现有效的沙箱，Codex需要操作系统提供的隔离特性。某些操作系统提供了出色的工具（如macOS的Seatbelt、Linux的seccomp或bubblewrap），但Windows目前并未提供这种开箱即用的能力。为了让Codex在Windows上像在其他平台上一样安全且令人愉悦，我们必须自行实现沙箱。
Windows提供了一些隔离工具和原语，但均未完全满足我们的需求。我们评估了多种潜在方案，包括AppContainer、Windows Sandbox和强制完整性控制（MIC）标签。
AppContainer是Windows原生沙箱，一种基于能力的隔离模型，专为事先确切知道需要访问什么的应用而设计。它很有吸引力，因为提供了真正的操作系统边界，而非尽力而为的限制。然而，Codex并非一个严格限定范围的应用。它驱动着开放式的开发者工作流：shell、Git、Python、包管理器、构建工具以及代理决定需要的任何其他二进制文件。实际上，这使得AppContainer不适合当前问题。它提供了强隔离，但针对的工作负载范围远比“让代理像开发者一样操作”要窄。
Windows Sandbox是微软的一次性轻量级虚拟机。用户获得一个全新的Windows桌面，具有强大的隔离边界，会话结束后其中的所有内容都会消失。它显然很有趣，因为比AppContainer与任意软件的兼容性高得多，从安全角度看也是更强大的“盒子”。但Codex需要直接作用于用户的实际代码库、工具和环境，而非一个需要设置和主机/客户机桥接的独立临时桌面。此外，它还有一个根本的产品问题：Windows Sandbox甚至不在Windows Home版SKU上提供。
Windows具有“完整性级别”的概念（如低、中、高），用于确定系统对对象和进程的信任程度。基本规则是，低完整性进程无法写入高完整性对象，即使常规ACL允许也不行。例如，低完整性进程被认为不太可信，因此Windows会阻止它写入正常的中完整性对象，除非这些对象被明确重新标记以允许写入。MIC在纸面上看起来很优雅：以低完整性运行Codex，将可写根目录重新标记为低完整性，让Windows在其他地方强制执行禁止写入。这将提供一个非管理员路径，背后有真正的操作系统机制。但问题在于，与ACL一样，完整性标签会修改真实的主机文件系统，且语义变化尤为广泛。将工作区标记为低完整性不仅意味着“Codex可以在此写入”，还意味着低完整性进程通常可以在此写入。在真实的开发者机器上，这会将用户的实际代码库变成主机上的低完整性“接收池”，远比向一个沙箱设计授予精心定位的ACL更危险。即使中完整性开发工具继续工作，工作区底层的信任模型也已改变，难以控制且更难合理化。
在评估所有选项均不可行后，我们开始设计自己的解决方案，为Windows用户带来良好的Codex体验。我们的第一个工作原型结合了多种Windows概念和工具来实现所需的隔离。从一开始，一个目标就是让沙箱无需提权即可工作，即Codex不需要提示用户输入管理员权限来设置或运行沙箱。这意味着要弄清楚如何对两件事施加合理限制：文件写入和网络访问。
（注：由于原文在此处截断，后续内容无法提供。但根据上下文，团队应该成功实现了自定义沙箱方案，并可能涉及用户账户控制（UAC）、作业对象、令牌限制等技术细节。完整的文章会详细描述实现过程、遇到的挑战及最终解决方案，以及如何通过沙箱在Windows上提供与macOS和Linux相当的安全性与用户体验。）
通过构建自定义沙箱，我们成功让Codex在Windows上实现了安全高效的运行，无需用户频繁审批或完全开放权限。这一解决方案不仅提升了Windows用户的使用体验，也展示了OpenAI在跨平台安全工程上的创新能力。未来，我们将继续优化沙箱性能，并探索更多Windows原生隔离机制，确保Codex始终在安全与效率之间找到最佳平衡。
SEO & GEO 技术探索者，专注于搜索引擎优化和生成式引擎优化。
OpenAI销售团队规模一年增长三倍，通过构建GTM Assistant智能助手，将顶尖销售经验系统化，实现销售生产力提升20%，让销售代表每周多出一天时间专注于客户关系。
OpenAI 正式发布 AI 视频生成模型 Sora，通过水印溯源、肖像权控制、青少年保护、内容过滤等多维安全策略，在推动视频创作创新的同时，构建了负责任的 AI 应用框架。
OpenAI 发布 Sora 2，视频生成模型迎来 GPT-3.5 时刻。新模型在物理准确性、可控性上大幅提升，支持同步音效和对话，并推出基于‘角色’功能的社交 iOS 应用。
获取最新的 SEO 与 GEO 技术资讯。
我们尊重您的隐私，随时可以取消订阅。
