Codex 自动化沙箱与 Unsafe Mode 详解：Windows 上的 Agent 隔离安全架构

工程团队评估 coding agent 时，最该问的问题不是"模型有多聪明"，而是：这个 agent 在我们的开发机上实际能执行什么，什么机制阻止它越界？ OpenAI 发布的 Codex Windows 沙箱工程详解，把这个问题变得具体可查——其中的架构决策，对部署 Codex、Claude Code、OpenCode 或任何本地执行 coding agent 的团队都直接相关。

发生了什么

OpenAI 发布了一篇详细工程文章，解释 Codex 现在如何在 Windows 上实现 OS 级进程隔离。问题是真实的：此前，Windows 用户只有两个选择——几乎对每个命令单独审批（彻底破坏自动化价值），或者开启 Full Access 模式让 agent 无限制运行（彻底破坏安全保障）。Mac 和 Linux 早已有 OS 级别的沙箱原语（分别是 Seatbelt 和 seccomp/bubblewrap），而 Windows 没有。

工程团队评估了三种现有 Windows 机制，最终全部否决：

• AppContainer：隔离效果强，但设计前提是应用的权限集在启动前就已明确。Codex 驱动的是开放式开发者工作流（shell、Git、Python、构建工具、各类二进制），AppContainer 的形状不合适。
• Windows Sandbox：类似轻量级 VM，隔离强，但需要单独环境搭建、不支持 Windows Home 版，且无法直接在用户真实代码目录上操作。
• 强制完整性控制（MIC）标签：将工作目录标记为低完整性可以让 Codex 写入，但这同时意味着机器上所有低完整性进程都可以写入该目录——信任模型的改变比预期宽泛得多。

最终方案使用 写限制进程令牌（write-restricted token） 和 合成安全标识符（SID） 来约束沙箱进程的写范围，无需管理员提权。工作目录获得针对沙箱 SID 的定向 ACL 写权限，文件系统其余部分则由受限令牌保护。网络访问通过独立机制额外控制。

为什么对 AI 工程团队重要

这个架构故事的价值远超 Windows 本身。大多数部署本地 coding agent 的团队从未明确回答过一个问题：agent 进程在操作系统层面的边界在哪里？

macOS 上 Codex 使用 Seatbelt，大多数工程师视为理所当然。Linux 上 seccomp/bubblewrap 存在，但需要针对具体包管理器和构建工具链进行验证。Windows 上——如这篇文章所示——差距大到需要自研实现。

对工程团队的实际影响：

1. "默认模式"在不同平台上并不等价。 macOS 上 agent 的默认文件访问策略与本次改动前的 Windows 不同。基于单一平台测试设定 agent 策略的团队，可能对其他平台上的行为有错误预期。

2. Full Access 模式是企业安全策略决定，不只是便利开关。 OpenAI 明确将 Full Access 定义为不安全选项。如果你的 Windows 开发者此前因为找不到更好的替代方案而使用 Full Access，这个暴露窗口现在可以关闭——但这也意味着有团队曾在生产相邻的工作流中以几乎无写范围限制的方式运行 agent。

3. 安全沙箱不应要求管理员提权。 Codex 的设计明确避免管理员权限。如果你正在评估的 coding agent 需要提权才能建立沙箱，这是一个值得关注的安全信号。无提权沙箱是可实现的基线预期。

4. 进程继承行为决定了真实隔离效果。 Codex 的沙箱从进程启动起生效，并向下传播至整个进程树。agent 启动的所有子进程都继承相同约束。这是正确的模型，但容易出错：只在父进程层面应用、子进程不继承的沙箱会给出虚假的安全感。

路由与运营视角

对于通过路由网关将 coding agent 请求分发到不同后端模型的团队，沙箱问题与路由问题是两个独立层面，但两者存在交叉：

切换提供商改变的是后端模型，不是本地沙箱。 当你通过 OpenAI 兼容网关将请求路由到不同模型时，本地 Codex harness 仍以其沙箱配置运行。改变的是模型端点，本地执行环境不变。这意味着沙箱是 harness 的属性，而非 模型 的属性。换模型但保持 harness，沙箱约束依然有效。

不同 harness 可能有不同的沙箱约定。 如果你的团队使用 Claude Code、OpenCode 或自定义 coding agent harness，沙箱实现是该 harness 特有的。Claude Code 在 macOS 的默认模式使用 Seatbelt；Windows 上有自己的配置。在同一路由网关后运行多种 harness 的团队（不同开发者使用不同工具指向同一模型），应为每个 harness 独立审计其沙箱约定。

治理需要的不只是模型层可见性。 大多数 AI 网关记录请求被路由到哪个模型、消耗了多少 token，但不记录 agent 在开发机上访问或修改了哪些文件。这种可见性存在于 harness 层，而非路由层。如果你的治理要求需要 agent 文件系统操作的可审计性，答案是 harness 级日志（如 Codex 的审批日志），而非路由层遥测。

接下来要关注什么

• 审计 Windows 开发者机器的 Codex 配置。 如果开发者此前以 Full Access 模式作为折中方案，现在是重置为默认模式的时机。新的沙箱应该让 Windows 上的默认模式可以正常使用，无需频繁审批。

• 评估新 coding agent 时审查沙箱实现。 对于你正在考虑的任何本地执行 agent，应问：(a) 哪种 OS 级机制强制写边界？(b) 是否需要管理员提权？(c) 约束是否传播到子进程？(d) 网络访问场景下如何处理？这些现在是可以核查的问题，不只是理论设想。

• 将 harness 版本更新视为安全变更。 Codex、Claude Code 或类似工具的 harness 更新，可能同时改变沙箱实现。从 seccomp 切换到不同隔离机制的版本更新，是安全策略变更，不只是版本号递增，应以此对待。

• 使用针对工作目录的定向 ACL，而非宽泛的目录信任。 Codex 的设计将写访问限定在具体工作目录，而不是一类宽泛目录。这是正确模式。配置 agent 工作空间时，应将写权限限定在 agent 实际需要的具体目录，而不是更宽泛的根路径。

TheRouter 在提供商之间路由模型 API 请求，并在计费层记录 token 级使用情况。Coding agent 的文件系统操作在开发机本地进行，超出 API 路由范围。治理因此是双层的：路由网关处理模型访问策略，harness 配置处理本地执行策略。两个层面都需要明确配置——其中一个不能替代另一个。