Windows 没给 Codex 留沙箱：从「劝」到「换个用户跑」的两次重做

Mon, 05 Oct 2026 07:50:00 +0800

2025 年 9 月，David Wiesen 加入 Codex 团队的时候，Windows 上的 Codex 还没有沙箱这回事。

那时 Windows 用户只有两个选择。第一，几乎每条命令都点一次批准，连读文件也要问，用起来像在给自己的电脑做审核。第二，直接开 Full Access，把所有限制关掉，爽是爽，等于把笔记本交给一个会自己敲命令的程序。

中间那条路才是大多数人想要的：能读文件，能改当前项目里的文件，不能随手把系统改了，也不能偷偷联网。这条路不难描述，难的是谁来执行。它必须由操作系统强制，而不是靠模型自觉。

macOS 有 Seatbelt，Linux 有 seccomp 和 bubblewrap，把这两件事做得挺顺手。Windows 没有对应的现成东西。所以 Codex 团队自己造了一个。

沙箱约束的到底是什么

沙箱是一个被削了权限的执行环境。开发者敲下命令时，操作系统用的是降权后的身份启动它，而这个约束会沿着进程树往下传：每个 Codex 执行的命令从一开始就在盒子里，它自己拉起来的子进程也在同一个盒子里。

这里有个区分值得记牢。沙箱决定技术上能做什么，审批决定什么时候必须停下来问你。前者是操作系统层面的硬边界，后者是交互策略。很多人把两件事混着说，结果既高估了沙箱（以为它会问），也低估了沙箱（以为它只是提示）。

三个现成方案，形状都不对

OpenAI 先看了 Windows 上现成的隔离能力：AppContainer、Windows Sandbox，以及 Mandatory Integrity Control 完整性标签。三个都是真东西，但都对不上 Codex 的需求。

AppContainer 是 Windows 原生的沙箱，一套能力模型，为那种事先就知道自己要访问什么的 app 设计。这个前提就挡住了 Codex。它不是一个小而明确的 app，它是一堆开放式工作流的驱动者：shell、Git、Python、包管理器、构建工具，以及模型当场决定要用的任何二进制。拿一个为窄场景设计的隔离机制去装一个开放式 agent，形状不对。

Windows Sandbox 是微软的一次性轻量虚拟机，进去是个全新的 Windows 桌面，隔离边界很硬，会话结束里面发生的一切就没了。问题也在这儿：一个每天要改本机仓库的人，用这个等于另开一台机器，还得想办法把成果搬回来。另外它只在专业版及以上的版本里提供，家庭版用户根本用不上。

MIC 纸面上最优雅。Windows 有完整性级别的概念，低、中、高，规则是低完整性进程不能写高完整性的对象，哪怕 ACL 允许。按理说可以这样干：让 Codex 在低完整性下跑，把可写的根目录标成低完整性，其他地方交给 Windows 挡。但这个方案的真实语义是，把一个工作区标成低完整性，不等于「Codex 能写这里」，而等于「所有低完整性进程都能写这里」。开发者真实的 checkout 目录就这样变成了宿主机上的低完整性落点，信任模型被改宽了，而且很难收回来。

Windows on Codexer

Windows 没给 Codex 留沙箱：从「劝」到「换个用户跑」的两次重做

沙箱约束的到底是什么

三个现成方案，形状都不对