Agent沙盒

Agent 沙盒可以理解为一块受控的工作区：AI 可以在里面读文件、改代码、执行命令，但越过边界时，操作要么被系统直接拦截，要么进入审批流程。

这里的关键不在于提醒 AI 请谨慎操作，而在于让操作系统或隔离运行时强制执行限制。这样即使模型判断失误，安全边界也不会跟着失效。

1. Agent 沙盒解决什么问题

1.1 Sandbox 的两种含义

sandbox 在技术语境中有两种常见含义。一种是测试环境，例如支付平台提供的 Sandbox 不处理真钱，只用来模拟真实业务；另一种是安全隔离环境，用来限制程序能够访问的文件、网络、进程、凭证和系统资源。

Agent、Codex 和 WorkBuddy 所说的沙盒，通常是第二种。

1.2 Agent 为什么需要安全边界

普通聊天模型主要生成文本，而 Agent 还会调用工具，甚至直接改变外部状态。它可能执行下面这些操作：

• 读写本地文件；
• 运行 Shell、Python 或 Node.js；
• 安装依赖并启动服务；
• 操作浏览器；
• 调用企业系统与第三方 API；
• 上传、修改或删除真实数据。

其中一些操作会产生不可逆的副作用。模型可能误解用户意图，第三方网页也可能通过提示词注入诱导 Agent 执行危险命令，所以安全不能只依赖模型自觉。真正可靠的保护必须落在工具执行层，由系统给出无法随意绕过的硬边界。

1.3 沙盒到底隔离谁

严格来说，多数 Agent 并不会把大模型本身放进沙盒，因为模型很可能运行在远程推理服务中。真正受到限制的是 Agent 启动的工具进程，例如 Shell、Git、测试程序和浏览器；实际的文件读写与网络访问都由这些进程完成。

因此，Agent 沙盒更准确的定义是：限制 Agent 工具及其子进程的执行边界。

2. Agent 沙盒通常怎么实现

2.1 沙盒需要限制哪些能力

完整的 Agent 沙盒很少只依靠一种技术，实际产品通常会组合多项控制：

• 文件系统：规定哪些目录可读、可写或完全不可见；
• 进程：限制子进程创建、进程间通信和系统调用；
• 网络：默认断网，或者只允许访问指定域名与端口；
• 身份和凭证：使用低权限用户与短期令牌；
• 资源：限制 CPU、内存、磁盘和执行时间；
• 生命周期：任务结束后销毁环境，或者通过快照恢复状态；
• 审计：记录执行的命令、文件变更和审批结果。

不同产品会选择不同的组合。有的只限制文件写入，有的会把网络、凭证和运行资源一起隔离。因此支持沙盒本身提供不了多少信息，还要继续看它究竟限制了什么。

2.2 常见的底层实现

方案	主要机制	适用场景	主要限制
工具白名单	应用只暴露有限操作	简单 Agent	不能替代操作系统隔离
本机进程沙盒	操作系统策略限制进程能力	本地编程 Agent	仍然与宿主机共享内核
容器	Namespace、挂载和 cgroups	云端任务与 CI	通常共享宿主机内核
microVM 或 VM	独立虚拟机与内核	高风险代码执行	启动与维护成本更高

沙盒描述的是安全目标，容器和虚拟机则是实现手段。Docker 容器可以用来承载沙盒，但如果没有正确配置目录挂载、用户权限和网络，容器里的进程仍然可能拥有很大的访问范围。

Git Worktree 也不是安全沙盒。它只能把代码改动放在另一棵工作树中，无法阻止进程读取电脑上的其他文件。审批弹窗同样不是沙盒，它只是一次权限决策，真正执行限制的还是操作系统或隔离运行时。

2.3 沙盒不能解决所有问题

沙盒只能约束边界，不能判断每一个操作是否合理。如果工作区本来就是可写的，Agent 仍然可能在沙盒内误删代码；如果用户或自动审核错误批准了越界请求，命令也可能获得额外权限。

沙盒配置本身也可能出错。例如目录开放得过多、网络没有真正隔离，或者密钥已经通过环境变量暴露给进程，都会削弱保护效果。

因此，沙盒适合用来限制事故范围，但不能代替权限最小化、审批、备份和审计。

3. Codex 如何实现本地沙盒

下面的源码分析以 Codex commit 4ef836f 为准。Codex 后续如果调整权限模型或底层后端，具体实现也可能发生变化。

3.1 从工具调用到操作系统

Codex 不会拿到模型生成的字符串就直接执行，而是先把动作交给命令执行层。执行层结合当前权限和审批结果，决定是否执行命令，以及用什么限制来启动它。

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#3B82F6', 'primaryTextColor': '#1E3A5F', 'primaryBorderColor': '#2563EB', 'lineColor': '#60A5FA', 'secondaryColor': '#10B981', 'tertiaryColor': '#F59E0B'}}}%%
flowchart TD
    U["用户提出任务"] --> A["主 Agent 规划动作"]
    A --> T["生成工具调用"]
    T --> P{"当前权限是否允许"}
    P -->|"允许"| S["在沙盒内执行"]
    P -->|"越界"| R{"审批策略是否允许请求"}
    R -->|"不允许"| D["拒绝操作并返回错误"]
    R -->|"允许"| V["用户或 Auto-review 审核"]
    V -->|"拒绝"| D
    V -->|"批准"| E["生成有限的额外权限"]
    E --> S
    S --> O["操作系统强制执行边界"]
    O --> X["结果返回主 Agent"]

    classDef primary fill:#3B82F6,stroke:#2563EB,color:#fff
    classDef success fill:#10B981,stroke:#059669,color:#fff
    classDef decision fill:#F59E0B,stroke:#D97706,color:#fff
    classDef danger fill:#EF4444,stroke:#DC2626,color:#fff

    class U,A,T primary
    class S,E,O,X success
    class P,R decision
    class D danger

图里最容易混淆的是沙盒和审批。沙盒规定命令默认能碰什么，并由操作系统强制执行；审批只在动作越界时介入，决定是否为这一次操作增加有限权限。

3.2 PermissionProfile 如何描述权限

Codex 用 PermissionProfile 统一描述文件和网络权限，再把同一套规则交给不同操作系统的沙盒后端执行。在本文核对的版本中，PermissionProfile 定义了三种状态：

• Managed：Codex 创建并管理沙盒；
• Disabled：不应用 Codex 外层沙盒；
• External：隔离由外部环境负责。

内置权限配置包括：

• :read-only；
• :workspace；
• :danger-full-access。

在本文核对的版本中，默认策略可以读取根路径，再额外叠加禁止读取的敏感路径；.git、.agents 和 .codex 等元数据目录也会受到额外的写保护。

相关实现位于 models.rs 和 permissions.rs。

3.3 Full Access 的准确含义

在本文核对的 Codex 版本中，Full Access 的预设组合是：

approval: AskForApproval::Never
permission_profile: PermissionProfile::Disabled

这个组合会关闭 Codex 的常规沙盒，并且不再产生常规的越界审批，但 Full Access 不等于 root。命令仍然继承当前用户和 Codex 应用自身的权限，也继续受到以下机制约束：

• POSIX 文件权限；
• macOS TCC 隐私授权；
• System Integrity Protection；
• Windows ACL；
• 企业管理策略；
• 插件与外部工具自身的权限规则。

因此，界面里的 “ 可以访问任何文件 “ 只是一种简化描述。更准确的说法是：Codex 不再主动添加文件和网络限制。

源码中的预设映射位于 approval-presets。

3.4 不同系统使用不同后端

在本文核对的版本中，Codex 会根据宿主系统选择执行后端：

平台	主要后端	核心机制
macOS	Seatbelt	SBPL 策略与 sandbox-exec
Linux、WSL2	Bubblewrap	Namespace、挂载与 seccomp
Windows elevated	独立低权限用户	文件权限与防火墙规则
Windows unelevated	Restricted Token	ACL 与受限令牌

Linux 的源码枚举名是 LinuxSeccomp，不过这个名称已经不能概括完整实现了。该版本的 Linux 后端主要使用 Bubblewrap：根文件系统先按只读方式挂载，需要写入的目录再通过 Bind Mount 单独开放；进程还会设置 PR_SET_NO_NEW_PRIVS，网络隔离则结合 Namespace 与 seccomp。Landlock 仍保留为旧版后备路径。

Windows 有 elevated 和 unelevated 两种模式。elevated 模式会使用独立的低权限用户、文件权限和防火墙规则，隔离更强；unelevated 模式依靠受限令牌与 ACL，是无法完成前一种设置时的后备方案。具体说明可以参考 OpenAI 的 Windows sandbox 文档。

平台选择逻辑位于 manager.rs，Linux 的具体实现可以参考 linux-sandbox/README.md。

3.5 macOS 上的 Seatbelt

Seatbelt 是 Apple 沙盒机制的历史名称，Codex 也沿用了这个叫法来命名 macOS 后端。在 macOS 上，Codex 会动态生成一份沙盒策略，然后通过系统自带的 sandbox-exec 启动原始命令。

正常使用 Codex 时，用户不需要手动执行下面的命令。它由 Codex 的命令执行层在本机 Mac 上构造并运行：

/usr/bin/sandbox-exec \
  -p '<动态生成的 SBPL 策略>' \
  -DWRITABLE_ROOT_0=/当前工作区 \
  -- 原始命令 参数

Codex 固定调用 /usr/bin/sandbox-exec，不会从 PATH 中搜索同名程序，以免恶意程序冒充系统命令。策略内容通常从默认拒绝开始：

(version 1)
(deny default)

(allow process-exec)
(allow process-fork)
(allow signal (target same-sandbox))

这段内容不是 Shell 命令，而是 Sandbox Profile Language，简称 SBPL，其中以 ; 开头的内容才是注释。

SBPL 不会单独执行。Codex 会把它作为 sandbox-exec -p 的参数传入，再由 sandbox-exec 按照这份策略启动真正的命令。完整策略还会加入文件和网络规则，用来确定哪些路径可读、哪些目录可写，以及能否访问网络或 Unix Socket。

如果要手动实验，也可以把规则保存为 profile.sb，再执行：

/usr/bin/sandbox-exec -f profile.sb /bin/sh

这条命令只适用于提供 sandbox-exec 的 macOS，不是 Linux 或 Windows 命令。

在本文核对的 Codex 版本中，macOS 后端仍然使用 sandbox-exec。它不是容器或虚拟机：受限进程依然直接运行在本机，只是进程及其子进程受到同一份沙盒策略约束。

4. WorkBuddy 的沙盒属于哪一类

Codex 展示的是本地操作系统沙盒，而 WorkBuddy 可以用来观察另一种情况：同一个产品同时提供本地和云端能力时，两种模式的信任边界可能完全不同。

根据腾讯云的 WorkBuddy 产品页面，本地模式可以处理授权目录中的文件，安全重点是目录授权和本机权限控制。

WorkBuddy Managed Agents 则运行在云端。官方页面称每个 Agent 都有独享沙箱，并支持环境持久化、恢复和快速复制；不过公开资料没有说明它具体使用了哪种隔离原语，因此不能仅凭 “ 独享沙箱 “ 几个字就断言底层是容器还是 microVM。

这个对比说明，产品名称中的 “ 沙盒 “ 描述的是安全边界，不一定会公开底层实现。判断它是否适合自己的场景时，仍然要看文件、网络、凭证和生命周期分别怎么隔离。

5. 参考资料

• OpenAI：Sandbox
• OpenAI：Permissions
• OpenAI：Auto-review
• OpenAI：Windows sandbox
• Apple：Configuring the macOS App Sandbox
• Codex 源码：sandboxing
• 腾讯云：WorkBuddy
• 腾讯云：WorkBuddy Managed Agents