Coding Agent 沙箱对照：从沙箱赛道视角看生产 Agent

调研时间：2026-06-22 | 环境：macOS arm64，无 KVM 本篇从沙箱隔离技术视角对照生产 Coding Agent，补 A 线盲区（密度、microVM 需求、隔离层级差异）

一句话定位

同一个问题——「AI 生成的不可信代码该怎么安全执行」——Codex 用 OS 沙箱、Claude Code 用权限分类器、Cursor 用用户确认、E2B/CubeSandbox 用 microVM。本篇从隔离层级、启动成本、多实例密度三个维度做系统对照。

Harness 内沙箱调用见 Codex 沙箱精读 / Claude Code 工具与权限 CubeSandbox 架构概览见 精读: cubesandbox（已有）

日常类比

想象你是一个快递站站长，每天收到大量来路不明的包裹（Agent 生成的代码），需要拆包检查（执行）。不同的安全策略对应不同的成本和安全等级：

• Codex 路线（OS sandbox）：你戴上手套、穿上防护服，在一个有通风系统的房间里拆包——你的手是自由的，但有毒气体不会泄漏到外面
• Claude Code 路线（Permission + classifier）：你在包裹上扫描条码，危险品直接退回——快，但只防已知威胁
• CubeSandbox/E2B 路线（microVM）：每个包裹单独放进一个密封的防爆箱里拆——最安全，但需要很多防爆箱
• Cursor 路线（用户确认）：每拆一个包之前先喊你来看——安全但极慢

类比边界：真实的代码执行比拆包裹复杂得多——代码可以创建文件、发网络请求、spawn 子进程，每个动作都需要独立的安全判定。

全维度对比表

关键问题一：何时 OS sandbox 够用，何时必须 microVM？

这是隔离技术选型的核心分歧。

OS sandbox 够用的场景（Codex 路线）

Codex 的沙箱设计思路是「OS 进程级隔离 + 策略控制」[已有] deep-dive-codex-sandbox：

• macOS 用 Seatbelt（SBPL 策略语言）做文件系统白名单 + 网络控制
• Linux 用 bwrap（Namespace 隔离）+ seccomp-BPF（syscall 过滤）+ Landlock（备用文件系统控制）
• 三层防线协同：exec policy → 用户审批 → OS sandbox

够用的条件：代码在单一信任域内执行（同一个用户的代码）、不需要强多租户隔离、不需要完整的内核独立。Codex 的典型场景是「开发者自己的代码在自己的机器上跑」——攻击者和受害者是同一个人，OS sandbox 主要防的是误操作和 prompt 注入导致的意外命令。

必须 microVM 的场景（E2B/CubeSandbox 路线）

当满足以下任一条件时，OS sandbox 不够 [社区]：

1. 多租户：不同用户的代码在同一台机器上执行——内核共享意味着内核漏洞可以跨租户攻击
2. 不可信代码源：代码来自外部（用户上传、AI 生成后未经人类审查直接执行）——攻击面包含 LLM 被 prompt 注入后生成的恶意代码
3. 合规要求：金融/医疗等行业要求 VM 级隔离，OS namespace 隔离不满足审计标准
4. 内核 exploit 防护：Linux 内核每年有数十个 CVE，共享内核意味着沙箱逃逸攻击面持续存在

分水岭判断：如果你的 Agent 只执行自己生成的代码、在单用户环境下运行、不暴露给外部输入，Codex 的 OS sandbox 够用。如果你要做一个”代码执行即服务”（像 E2B 那样给第三方 Agent 调用），microVM 是最低安全标准。

关键问题二：并行密度与 Swarm/Workflow 的需求

Claude Code 的并行架构 [已有]

从 A 线 多 Agent 编排 的研究，Claude Code 有四层递进的多 Agent 模式：

1. Subagent：派生一次性子 agent，共享同一个进程
2. Coordinator：通过环境变量激活多 agent 协调
3. Swarm/Teams：三种后端（in-process/tmux/iTerm2），文件邮箱通信
4. Dynamic Workflow：JS 脚本编排百级 subagent

关键观察：Claude Code 的并行全部在 L0（应用层） 进行——子 agent 之间没有内核级隔离，共享同一个文件系统和网络栈。这在开发者自用场景下没问题，但如果要把这个架构用于多租户生产环境，每个 subagent 都需要独立的隔离容器。

CubeSandbox 的密度优势

CubeSandbox 的 <5MB 单实例内存意味着 [源码] [已有]：

• 一台 64GB 内存的服务器理论上可以跑 ~12,000 个沙箱实例（假设 5MB/实例 + 系统开销）
• 实际生产中考虑 CPU、网络等资源竞争，千级并行是可行的

对比其他方案：

Dynamic Workflow 场景：如果未来的 Agent 编排需要「同时跑 100 个 subagent，每个都在独立沙箱里」，CubeSandbox 的密度优势是决定性的——100 个实例只需要 500MB 内存。Kata Containers 同样的规模需要 1-3GB。

关键问题三：Claude Code 有独立 microVM 吗？

结论：没有 [已有] [源码]。

从 A 线精读可知，Claude Code 的安全模型是四层纵深防御：

1. System Prompt 层（指令约束）
2. Permission Rules 层（.claude/settings.json 配置）
3. Tool 层（每个工具的 isReadOnly() / needsPermissions() 声明）
4. 用户确认层（interactiveHandler 的 4 源竞赛判定）

这四层全部在 应用层和用户态 运行——没有 KVM、没有 namespace、没有 seccomp。Claude Code 执行 Bash 命令时，命令直接在用户的 shell 环境里跑，没有额外隔离。

与 CubeSandbox 的差异：

Claude Code 的策略是「信任但验证」——通过 classifier 和 hook 过滤危险操作，而不是阻止所有操作。CubeSandbox 的策略是「默认不信任」——所有代码都在隔离的 VM 里跑，即使有恶意行为也无法影响宿主机。两种策略的适用场景不同，不是简单的优劣关系。

Agent Harness 到沙箱的调用路径

graph TD
    AGENT[AI Agent / Harness] --> REQ{代码执行请求}

    REQ -->|"Codex 路线"| OS[L2: OS Sandbox<br>bwrap + seccomp]
    REQ -->|"Claude Code 路线"| PERM[L0: Permission Classifier<br>→ BashTool 直接执行]
    REQ -->|"E2B 路线"| CLOUD[L4: 云端 microVM<br>Firecracker + API]
    REQ -->|"CubeSandbox 路线"| LOCAL[L4: 自托管 microVM<br>RustVMM + E2B SDK]

    OS --> EXEC1[执行结果]
    PERM --> EXEC2[执行结果]
    CLOUD --> EXEC3[执行结果]
    LOCAL --> EXEC4[执行结果]

    OS -.->|"A 线已有"| CODEX_DOC["deep-dive-codex-sandbox.md"]
    PERM -.->|"A 线已有"| CLAUDE_DOC["deep-dive-claude-code-tools-permissions.md"]
    CLOUD -.->|"C 线已有"| E2B_DOC["sandbox-deep-dive-e2b.md"]
    LOCAL -.->|"C 线已有"| CUBE_DOC["sandbox-deep-dive-cubesandbox.md"]

    style OS fill:#e3f2fd
    style PERM fill:#fff3e0
    style CLOUD fill:#e8f5e9
    style LOCAL fill:#fce4ec

Codex 的 OS 沙箱与 microVM 的具体差异

从隔离技术视角补充 A 线盲区：

启动成本

Codex 的 sandbox 启动是进程级的——fork() + 设置 namespace/seccomp/Landlock 策略，总耗时 <10ms [已有]。CubeSandbox 的 60ms 虽然是 microVM 中最快的，但仍然是 Codex 的 6 倍。

影响：在交互式 Agent 场景下（用户等待每一步执行结果），10ms 和 60ms 的差异可以忽略。在批量执行场景下（Agent 连续发起 100 个命令），差异累积到 5 秒 vs 0.5 秒——仍然可接受。真正的差异在于 microVM 的首次 boot（冷启动），CubeSandbox 通过 CoW 预池化把这个成本压到了 60ms。

多实例密度

网络 egress 策略

与 6 开源项目的关系映射

                    ┌──────── 引擎层 ────────┐
                    │ Firecracker (L4 引擎)   │
                    │ gVisor Sentry (L1 引擎) │
                    └─────────┬──────────────┘
                              │ 构建于
            ┌─────────────────┼─────────────────┐
            │                 │                   │
     ┌──────▼──────┐  ┌──────▼──────┐  ┌────────▼────────┐
     │ E2B (L3 云) │  │ CubeSandbox │  │ Kata (L4 OCI)  │
     │ 云端 API    │  │ (L4 自托管) │  │ K8s 安全容器    │
     └──────┬──────┘  └──────┬──────┘  └─────────────────┘
            │                 │
            └────── SDK ──────┘  E2B SDK 兼容
                    兼容

     ┌─────────────────────────────────────────────────────┐
     │            Agent 内建沙箱（非独立项目）              │
     │  Codex (L2 OS)    Claude Code (L0 Permission)      │
     │  Cursor (L0 确认)  Daytona (L3 容器级三层)          │
     └─────────────────────────────────────────────────────┘

核心发现总结

1. OS sandbox vs microVM 的分水岭是多租户和信任边界——单用户自用场景 Codex 的 L2 方案够用，多租户代码执行服务必须 L4

2. Claude Code 没有独立 microVM，完全依赖应用层权限控制。安全模型的核心假设是「代码由可信 LLM 生成，用户在场监督」

3. CubeSandbox 的密度优势在 Agent 并行场景下是决定性的——<5MB/实例让千级并行在单机上可行，这是 Codex 的 OS sandbox（共享进程，无密度问题但安全弱）和 Kata（10-30MB/实例）都无法匹敌的安全-密度组合

4. E2B SDK 正在成为事实标准——CubeSandbox 选择兼容而非另起炉灶，让 Agent 框架可以零改动从 E2B 切换到 CubeSandbox

5. 启动成本差异在实际场景中可忽略——60ms vs <10ms 在交互式 Agent 使用中感知不到，但在高频批量执行中会累积

证据等级