Codex Harness 安全沙箱机制原理

在软件系统里，"沙箱环境"并不是一个新概念。只要一个程序需要执行不完全可信的代码、不完全可控的命令，或者它的执行结果可能影响宿主机文件、网络、系统状态，工程上就一定会引入沙箱。

但到了 AI Agent 时代，沙箱这件事的含义开始发生变化。

过去我们谈沙箱，更多是在讨论"一个程序应该被关在哪里运行"。现在我们谈沙箱，讨论的已经不只是运行位置，而是"一个具备自主决策能力的执行体，到底应该被赋予多大的能力边界"。

所以如果要理解 Codex 的沙箱环境，就不能把它理解成一个简单的产品开关，更不能把它理解成"是不是起了一个虚拟机"。

Codex 的沙箱，本质上是一套把模型执行能力约束在可控边界内的工程化运行时安全架构。

这篇文章就从这个角度出发，把整个机制按顺序拆开讲清楚：

1. 什么是沙箱环境，它到底在解决什么问题。

2. 为什么 AI Agent 比传统程序更依赖沙箱。

3. Codex 的安全策略为什么不是单一机制，而是 sandbox mode + approval policy 的双层设计。

4. Codex 如何在执行前识别"跨界操作"。

5. Windows 原生安全机制是如何被 Codex 拿来构建本地沙箱的。

6. 最后从工程化角度，总结这套设计真正值得借鉴的地方。

什么是沙箱环境：它的本质不是目录，而是能力边界?

很多人第一次接触沙箱，会把它理解成"一个隔离目录"或者"一个受限容器"。这种理解不能说错，但不够本质。沙箱环境更准确的定义是：让一个执行体可以运行，但只能在被限制的能力边界内运行。这个"边界"不是抽象概念，而是具体的资源访问边界。最常见的通常有三类：

• 文件系统边界：它能读哪些目录，能写哪些目录。

• 网络边界：它能不能联网，能访问哪些目标地址。

• 系统能力边界：它能不能启动子进程，能不能访问桌面、设备、注册表、系统接口。

从安全视角看，沙箱解决的是一个非常现实的问题：系统希望某个执行体帮它完成任务，但又不希望这个执行体拿到超出任务所需的能力。

所以沙箱从来都不是"禁止执行"，它的本质是"允许执行，但限制能力"。

传统沙箱是怎么做的?

传统沙箱并没有统一实现。工程上常见的路径，大体可以分成四类。

（1）虚拟化隔离

比如虚拟机、微虚拟机。这类方案直接提供一套相对独立的 OS 运行空间，把目标程序扔进去执行。它的优点是边界清晰、隔离强，文件系统、网络、进程树天然分开。缺点也很明显，就是启动重、资源消耗大、集成成本高。

（2）容器和内核隔离

Linux 世界更常见的是 namespace、cgroup、capabilities、seccomp 这一套。它不一定创建完整虚拟机，但会通过"进程可见范围隔离 + 资源约束 + 权限裁剪 + 系统调用过滤"，把目标程序限制在一个更窄的执行面里。Docker、在线代码运行器、隔离型 CI 执行器，很多都属于这条思路。

（3）操作系统原生降权

这类方案不一定借助虚拟化，而是直接用操作系统自己的安全模型完成隔离。以 Windows 为例，常用的是 access token、restricted token、ACL、DACL、防火墙、本地安全策略、private desktop 等机制。它本质上不是"另起一个系统"，而是"构造一个低权限执行主体"。

（4）应用层边界治理

也就是程序自己先定义规则，例如"什么允许、什么禁止、什么需要审批"，然后再决定动作是否继续执行。单靠这一层，不能形成真正的硬隔离，因为规则最终还是应用代码在解释；但如果把它和 OS 级强制机制叠加起来，就会形成完整的治理链路。

而 Codex 采用的，恰恰就是第四类和第三类叠加的路径。

为什么 AI Agent 比传统程序更需要沙箱?

传统程序的执行逻辑通常是开发者提前写死的，即所有执行动作本身就是可预测和可控制的。但 AI Agent 不一样，它自身具备独立思考、决策、执行能力，这意味着系统面对的风险模型发生了变化。过去是开发者定义执行路径，系统只需要做隔离实现，现在是模型先根据上下文生成动作意图，系统再决定这个动作能不能真的落地。

因此，Agent 场景下的沙箱不能只解决"程序别乱访问资源"，还必须考虑两个更重要设计：

• 执行边界判断，即模型产生执行意图时，要进行权限边界判断，是否越界。

• 一旦动作需要越界，如何进行策略选择，例如用户审批授权、权限拦截等

这也是为什么 Codex 的沙箱不能只是 OS 级安全机制，而是结合Agent层安全治理策略 + 操作系统安全机制，形成沙箱环境。

Codex两层协同安全机制模型

Codex 的沙箱本质上不是"把代理放进当前工作区目录"这么简单，而是把代理放进一套能力边界里。这个边界同时约束文件系统、网络、子进程、以及需要人工或自动复核的高风险动作。

Codex 的沙箱安全控制工程化策略主要是两个相互协作的层面组成，这两个层次叠在一起，才构成真正的运行时安全模型（沙箱）：

• **沙盒模式 sandbox mode：**Codex 在执行模型生成的命令时，技术上可以做什么（例如，它可以在哪里写入以及是否可以连接到网络）。

• **审批策略 approval policy：**当 Codex 在执行操作之前必须征求您的同意时（例如，离开沙箱、使用网络或在受信任集之外运行命令）。

Codex 的安全模型，不是"审批代替沙箱"，也不是"沙箱代替审批"，而是两层协同：

• 如果只有沙箱，没有审批，那么很多业务上危险但技术上可执行的动作依然会直接发生。

• 如果只有审批，没有沙箱，那么一旦程序绕过流程，系统就没有真正的硬边界。

这是一种典型的"控制平面 + 数据平面"设计。

Sandbox Mode

可以通俗的理解为它就是运行时执行边界，Codex通过结合**"应用层边界治理"** 和**"OS 层强制执行"**叠加形成的双层运行时安全模型。

应用层工程化治理：Codex 负责"边界治理

这部分是整套架构最核心的环节，边界不是运行时"猜出来"的，而是启动前就被声明好的。Codex 用 permission profile （config.toml中一段）显式描述边界，例如哪些目录算 workspace_roots，*哪些路径是 read、write、deny，*网络是否启用、允许哪些域名(OpenAI: Permissions)。

Codex底层设计中提供一个config.toml配置文件，用于安全策略配置，其中核心包含以下3块内容：

🟥 权限边界设定 permission profile

你可以理解问题，它是用于定义执行边界的详细配置，是本地命令执行的权限模板。例如哪些路径可读、哪些路径可写、是否允许联网...，这种约束机制本身也是一种沙箱手段。例如：

网络访问边界： 对于 Codex 应用、CLI 或 IDE 扩展，默认的workspace-write沙盒模式，会默认关闭网络访问，除非在配置中启用它：

[sandbox_workspace_write] 
​​​​​​​network_access = true

网络隔离设定： 针对目标网络的访问进行控制，如果已启用命令网络访问，请启用此network_proxy功能以将流量限制在配置的网络策略范围内。

[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "example.com" = "deny" }

🟥 沙箱级别设定 sandbox mode

sandbox mode是整体沙箱级别或预置运行模式，它从更高维度来实现的一套控制：

sandbox_mode = "workspace-write"

常用策略如下：

• **read-only：**只有读取权限

• **workspace-write：**只有工作区内可以写入

• **danger-full-access：**完全放开权限

OS 层沙箱约束：操作系统负责"真正拦住资源访问"

如果只有应用层约束，沙箱其实并不牢靠，因为应用层规则终究只是平台逻辑。真正让沙箱成立的，是下层操作系统把这些边界变成了硬约束。

OpenAI 官方明确说明，本地 Codex 使用的是 OS-enforced sandbox（操作系统强制沙箱），默认会把写权限限制在活动工作区，并且默认关闭网络。这里我们以Windows系统来说明OS系统级别沙箱能力。

首先我们需要知道Windows原生沙箱能力，本质上是基于操作系统的安全机制来实现的一种低权限安全主体。通俗的说，就是消弱用户主体权限，实现功能边界约束。

（1）Windows 沙箱底层原理：Token、DACL、ACE、AccessCheck

要真正理解 Codex 在 Windows 上的本地沙箱，就必须把 Windows 安全模型本身讲清楚。

Windows 访问控制模型的两大核心对象是：Access Token、Security Descriptor

🟥 access token

用户登录时，系统会将用户的密码与安全数据库中存储的信息进行比较，以验证密码的有效性。如果密码验证通过，系统将生成一个访问令牌 access token（这个令牌里带着用户 SID、所属组、权限和完整性级别）。每个以该用户身份执行的进程都拥有此访问令牌的副本。

后续当进程或者线程与对象进行交互，或尝试执行需要权限的系统任务时，系统使用访问令牌access token来识别用户信息。

🟥Security Descriptor

Windows 上的文件、目录、进程、线程、桌面对象、注册表键等，很多都属于 securable object。

这类对象背后都有一份安全描述信息，也就是 security descriptor。在这个 descriptor 里，最关键的一部分就是 DACL。

🟥 DACL 自主访问控制列表

在 Windows 里，很多资源都被当成"可保护对象"来看待，比如文件、目录、注册表键、进程、线程、命名管道、事件、互斥锁。

这些对象不会直接写死"谁能访问"，而是挂着一份安全描述信息。这个安全描述里最重要的一部分，就是 DACL访问控制列表。可以简单理解成"这份对象的权限规则表"。DACL中核心就是权限规则，也就是ACE

🟥 ACE 访问控制条目

全称Access Control Entry，就是 DACL 里的"一条规则"。每条 ACE 通常会包含三类信息：

• 作用对象是谁：某个用户 SID，或者某个组 SID，比如 Andrew、Group A、Everyone

• 规则类型是什么：Allow 允许，或者 Deny 拒绝

• 允许或拒绝哪些权限位：比如 Read、Write、Execute

🟥 Access Check

当进程尝试访问某个对象时，Windows 会把：进程持有的 access token、象持有的 security descriptor / DACL放到一起做一次访问判定，也就是 Access Check

（2）Windows 原生沙箱在 Codex 架构里是怎么被用起来的

当在 Windows 上原生运行 Codex 时，代理模式使用 Windows 沙箱来阻止对工作文件夹之外的文件系统进行写入，并防止未经确批准的网络访问。原生 Windows 沙盒支持包括两种模式，可以在以下位置进行配置 config.toml：

[windows]
sandbox = "elevated" # or "unelevated"

🟥 Elevated 高级模式

Elevated 是首选的 Windows 原生沙箱。它使用专用的低权限沙箱用户、文件系统权限边界、防火墙规则以及在沙箱中运行命令所需的本地策略更改。通俗的可以理解为，该模式会走一个管理员批准的 setup 流程，在这个 setup 过程中准备沙箱所需的用户/组/防火墙/本地策略。

通俗的理解，它不是"当前用户降一点权继续跑"，而是"先构造一个新的低权限安全主体，再让命令在这个主体下运行"。

🟥UnElevated 非高级模式

UnElevated 是 Windows 原生的备用沙箱。它使用从当前用户派生的受限 Windows 令牌运行命令 ，应用基于 ACL 的文件系统边界，并使用环境级脱机控制而不是专用的脱机用户防火墙规则。它比 弱elevated，但当管理员批准的安装因本地或企业策略而被阻止时，它仍然很有用，可以简单理解为用户还是这个用户，只不过做了权限消弱。

​​​​​​​Windows-sandbox

Codex 的审批策略

官方定义很直接：approval policy 决定 Codex 什么时候必须停下来，先请求用户审批许可。

approval_policy = "on-request"

常用策略如下：

on-request：边界内自动执行，越界时请求用户审批

untrusted：默认更保守，也称为自动化审批，只有低风险动作自动通过，是交给大模型来判断是否为低风险。

never：永不审批，超出边界就不再继续申请，注意，这是不给审批通过，不是永远通过。

通常这三种设定都是配合使用，官方默认预设里，Codex 在本地通常以workspace-write + on-request组合运行：可以在当前工作区读写、运行常规本地命令，但一旦要访问网络或越过工作区边界，就进入审批流程。

 workspace-write + on-request组合
 是 Codex 里最常见、默认的一组安全配置，无需任何标志或--sandbox workspace-write --ask-for-approval on-request。
 它代表：Codex 可以在工作区内读取文件、进行编辑和运行命令。Codex 需要获得授权才能在工作区外进行编辑或访问网络。

Auto Review 策略代理先审

OpenAI 官方文档说明，默认审批请求是直接路由给用户的：

approvals_reviewer = "user"

如果开启：

approval_policy = "on-request"
approvals_reviewer = "auto_review"

那么符合条件的审批请求，会先经过一个 reviewer agent，而不是直接弹给用户。它只审查那些"本来就已经需要审批"的动作。也就是说，边界内自动通过的动作，不会凭空多出一层审查。它没有取消原有沙箱边界，也没有让模型获得新的系统权限。它做的是审批流中的"风险分类和策略裁决"。

如果我们自己设计 Agent 沙箱，真正应该学什么

（1）不要把沙箱等同于容器或虚拟机

容器和虚拟机只是沙箱的一种实现形式。真正的沙箱设计，核心在于"能力边界如何声明、如何判定、如何强制执行"。

（2）Agent 的安全治理一定要比传统程序多一层执行前控制

因为传统程序主要防运行时越权，而 Agent 还要防"模型生成高风险意图"这一层。

（3）审批策略必须独立成层

只靠 OS 权限不够，因为有些动作技术上能做，但业务上不应该自动做。审批策略解决的是"是否允许继续"，而不是"有没有物理能力执行"。

（4）真正安全的本地沙箱，一定要把平台规则和 OS 级强制机制叠加起来。

如果只有应用规则，没有 OS 级约束，它更像"软约束"。如果只有 OS 级约束，没有意图级治理，它又无法应对 Agent 特有的风险模型。

所以，Codex 这套沙箱设计最有价值的地方，不是某个 Windows API，也不是某个配置项，而是它把 Agent 执行安全拆成了一条完整的工程闭环。

参考资料

https://developers.openai.com/codex/concepts/customization

https://developers.openai.com/codex/agent-approvals-security

https://developers.openai.com/codex/concepts/sandboxing

https://learn.microsoft.com/en-us/windows/win32/secauthz/access-control-lists