Codex CLI 沙箱机制深度解析：Seatbelt、Bubblewrap、Landlock 与 Docker

Codex CLI 的 read-only、workspace-write 和 danger-full-access 是策略层配置，真正的隔离由操作系统后端执行。本文把源码级分析和常见 Linux/macOS 沙箱原语放在一起，说明每层解决什么问题、边界在哪里。

总体架构

命令请求
  ↓
Approval Policy（是否需要用户确认）
  ↓
SandboxType（read-only / workspace-write / full-access）
  ↓
平台后端：Seatbelt / Bubblewrap + seccomp / Restricted Token

审批和沙箱不是同一件事：审批决定“是否允许执行”，沙箱决定“即使执行了，进程最多能触碰什么”。

macOS：Seatbelt

macOS 后端通过 sandbox-exec 加载 SBPL profile。profile 通常先拒绝默认能力，再按工作区路径、临时目录、解释器和网络策略添加例外。

• read-only 不允许写入工作区。
• workspace-write 只开放工作区及显式 writable_roots。
• 网络访问可以作为单独策略开启，不能从“能写工作区”推断出“能联网”。
• profile 是进程级约束，子进程通常继承限制。

Linux：Bubblewrap、seccomp 和 Landlock

Bubblewrap 负责构造进程看到的文件系统视图，例如只读绑定系统目录、把工作区以读写方式绑定，并隔离临时目录和 /proc 等资源。

seccomp-BPF 负责系统调用过滤，常用于禁止高风险调用或限制网络行为；它不是文件路径权限系统。Landlock 提供面向路径的内核访问控制，可以限制打开、写入、执行和删除文件，适合补充 namespace，但依赖内核版本和运行环境。

no_new_privs 阻止进程通过 setuid 或 file capabilities 获得额外权限，是叠加 seccomp/Landlock 时的重要保护。

Windows：Restricted Token

Windows 后端通过受限 token 降低进程权限，再结合系统 ACL 和子进程策略限制访问。它与 macOS profile、Linux namespace 并非一一对应，不能简单按“读写目录”模型理解。

与 Docker 的区别

Docker Desktop on macOS 通常在 Apple Virtualization.framework 提供的 Linux VM 中运行容器。容器隔离发生在 VM 内部，和 Codex 对宿主机进程施加的 Seatbelt 不是同一层。

机制	主要隔离对象	典型能力
Seatbelt	macOS 进程	路径、网络、系统调用能力
Bubblewrap	Linux 进程视图	mount namespace、用户和网络隔离
seccomp	Linux 系统调用	按 syscall 过滤
Landlock	Linux 文件系统访问	路径和操作类型限制
Docker	容器/VM	namespace、cgroup、镜像和网络隔离

安全边界与排查

• 沙箱不是恶意代码检测器；已获准执行的程序仍可能破坏允许范围内的数据。
• workspace-write 不是“只能修改当前文件”；构建工具可能写缓存、临时文件和生成目录。
• 网络关闭不能替代凭据保护；环境变量、配置文件和工作区中的密钥仍应主动清理。
• Docker 容器不是虚拟机，宿主挂载、特权模式、Docker socket 都会改变隔离边界。

遇到“命令能执行但访问失败”时，依次检查审批策略、当前沙箱类型、可写根目录、Seatbelt/Bubblewrap 参数、seccomp/Landlock 状态，并区分路径拒绝、系统调用拒绝和网络策略拒绝。

总结

Codex 的沙箱是“策略 + 平台强制”的组合：审批控制交互风险，Seatbelt、Bubblewrap、seccomp、Landlock 和 Restricted Token 负责实际边界。理解这些层次，才能准确判断一次失败究竟由审批、路径、系统调用还是网络策略造成。