正在加载文章内容，请稍候。
《OpenAI 在 Windows 上为 Codex 搭建沙箱：从原型到可提权部署的取舍》
拆解 Windows 侧 Codex 沙箱从无需管理员权限到提权安装方案的演进，权衡安全、可用与部署成本。
精准输入
我的笔记
✍️ 写下你的想法，自由记录即可。如果没有灵感，试着回答上方的费曼输出问题。
登录后可记笔记
登录后可保存笔记、高亮、划线和批注。
正在加载文章内容，请稍候。
拆解 Windows 侧 Codex 沙箱从无需管理员权限到提权安装方案的演进，权衡安全、可用与部署成本。
精准输入
✍️ 写下你的想法，自由记录即可。如果没有灵感，试着回答上方的费曼输出问题。
登录后可保存笔记、高亮、划线和批注。
Codex 在 Windows 上的问题不是“能不能运行命令”，而是能不能让一个云端推理、本地执行的编码 Agent 在真实开发机上既有足够权限完成工作，又不会随意改文件、联网外传数据。Windows 没有现成的 Seatbelt / seccomp 等价物，OpenAI 只能自己拼出一个沙箱：从无管理员权限的 ACL 原型，走到需要提权安装、专用本地用户和防火墙规则的最终方案。
Codex 默认运行在开发者电脑上：CLI、IDE 扩展或桌面端负责把人类键盘前的对话和云端模型推理连接起来，模型再让本地 harness 执行命令。问题在于，Codex 默认拥有真实用户的权限：能读文件、改工作区、跑测试、建分支，也可能执行不该执行的命令。
默认模式的目标是平衡效率和安全：允许几乎到处读文件，只允许在工作区和配置的可写根目录内写文件，默认不允许联网。要把这些约束变成真实边界，而不是“请模型自觉”，就需要操作系统强制执行的沙箱。
沙箱本质上是受限执行环境：操作系统以更低权限启动命令，并让约束沿着进程树向下传播。每条 Codex 命令从一开始就被放进边界内，所有子进程也不能逃出去。macOS 有 Seatbelt，Linux 有 seccomp / bubblewrap，但 Windows 没有一个能直接满足“开放式开发者工作流”的内置能力。
AppContainer 是 Windows 原生沙箱，隔离边界真实，但更适合需求预先明确的应用。Codex 驱动的是 shell、Git、Python、包管理器、构建工具和任意二进制；它不是一个范围固定的应用，而是一组开放式工作流。强隔离如果只能支持窄场景，对编码 Agent 就会变成不可用。
Windows Sandbox 更像一次性轻量虚拟机，隔离更强，也能兼容更多软件。但 Codex 需要直接作用于用户真实 checkout、工具链和环境，而不是在另一个临时桌面里重建上下文；更现实的问题是，Windows Sandbox 不适用于 Windows Home。
Mandatory Integrity Control 看起来优雅：把 Codex 跑在 low integrity，把可写根目录也标成 low integrity，系统自然阻止它写其他 medium integrity 对象。但 integrity label 会修改真实主机文件系统语义。把工作区标为 low integrity，不只是“Codex 可写”，而是所有 low-integrity 进程都可写，这会改变整个 checkout 的信任模型。
第一版原型坚持不要求管理员权限。文件写入靠两个 Windows 原语完成：SID 和 write-restricted token。SID 是 Windows 权限身份，既可以属于用户/组，也可以是合成出来、只给沙箱使用的 synthetic SID；ACL 则定义谁能读、写、执行某个文件或目录。
write-restricted token 会让写操作多一道检查：正常用户身份必须允许写，并且 restricted SID 列表中至少一个 SID 也必须被授予写权限。这样，Codex 可以用 sandbox-write 这个合成 SID，只给当前工作目录和配置的 writable_roots 写、执行、删除权限，同时显式拒绝它写 .git、.codex、.agents 等“可写目录内的只读位置”。
这个设计粒度很好，也无需提权；真正的弱点在网络。没有管理员权限，就很难安装 Windows Firewall 级别的规则。团队只能通过环境变量和 PATH 做“失败关闭”：把 HTTPS_PROXY、ALL_PROXY、GIT_HTTPS_PROXY 指向 127.0.0.1:9，让 GIT_SSH_COMMAND 立即退出，把假的 SSH / SCP stub 放在 PATH 前面。
这些网络限制只能拦住遵守环境变量的普通工具，挡不住自己开 socket 的程序，更挡不住有对抗意图的代码。文件写入的边界可以靠 ACL 强制，网络边界却只是建议，这足以让无提权方案出局。
网络外传是编码 Agent 的关键风险：恶意代码可以把本机数据传到互联网；好意代码也可能因为不遵守代理变量而绕过限制。Windows Firewall 可以按用户或程序阻止出站流量，但它不能匹配“restricted token 里包含某个 synthetic SID 的进程”。
按程序路径限制也不够：阻止 codex.exe 不会阻止它拉起的 Git 或 Python；阻止 python.exe 又会影响系统里所有 Python。端口和地址规则也不是正确策略，因为目标不是封掉 443，而是封掉这一棵受限进程树的任意出站访问。
要让防火墙只作用于沙箱命令，命令必须以另一个 principal 身份运行。最终方案因此放弃“完全无需提权”，在安装阶段创建两个本地用户：CodexSandboxOffline 和 CodexSandboxOnline。Offline 用户被防火墙阻止所有出站网络，Online 用户不被阻止，用于需要联网且经用户批准的场景。
提权沙箱在命令边界上仍然像第一版：子进程使用 write-restricted token，restricted SID 列表仍包含 Everyone、Logon、Synthetic。但 token 的 principal 不再是真实 Windows 用户，而是 Codex 自建的 sandbox 用户。这个小变化带来真正可执行的防火墙规则，也带来一整套安装和运行复杂度。
安装阶段要创建 synthetic SID，创建在线/离线沙箱用户，把用户凭据用 Windows DPAPI 加密存储，并创建或校验阻止 CodexSandboxOffline 出站网络的防火墙规则。因为沙箱用户默认不能读取真实用户 profile 等目录，还要异步给常用目录补读权限，例如 C:\Users\、C:\Windows\、C:\Program Files\、C:\ProgramData\。
OpenAI 把安装逻辑放进单独的 codex-windows-sandbox-setup.exe，因为跨 UAC 边界、用户创建、防火墙配置和长期异步 ACL 工作，和普通 codex.exe 的职责不同。codex.exe 保持一个非提权 harness，Windows 专属设置不污染其他平台。
运行命令时，又需要一个新二进制 codex-command-runner.exe。codex.exe 先用 CreateProcessWithLogonW 以沙箱用户启动 runner；runner 已经站在 sandbox-user 边界内，再打开自己的 token，提取 logon SID，创建 restricted token，并用 CreateProcessAsUserW 启动真正的子进程。最终系统分成 4 层：codex.exe、沙箱安装器、命令 runner、真正的 child process。
Windows 版 Codex 沙箱的核心教训是：安全的 Agent 执行环境不能只靠提示词或产品确认弹窗，必须把权限边界落到操作系统原语上。无提权方案足够轻，但网络隔离不硬；提权方案复杂，却能把“可写范围”和“可联网范围”都变成真实约束。对编码 Agent 来说，安全不是把能力关掉，而是在不妨碍真实工作流的前提下，让每一次本地执行都处在可解释、可审计、可强制的边界内。
文章先说明 Codex 在 Windows 上缺沙箱时的两难：频繁审批太低效，Full Access 又太危险。随后逐一排除 AppContainer、Windows Sandbox、MIC 等现成方案，再拆解无提权原型如何解决文件写入却败在网络隔离。最后落到当前的提权架构，说明每一层复杂度都对应一个无法绕开的安全或可用性约束。
费曼输出