近年来AI编程助手呈现出一种引人注目的趋势：让AI直接执行shell命令。 这无疑带来了巨大的生产力提升——AI不再仅仅是代码的编写者，geng成为了Neng够自主运行、调试和安装依赖的“数字工匠”。 然而伴随便利而来的风险也同样不容忽视。 Ru果我们赋予 AI 执行任意 shell 命令的Neng力，如何确保系统的安全？ 如何防止恶意代码的执行？ Codex沙盒正是为了解决这些问题而诞生的。

在探讨具体实现之前，我们需要明确一个核心理念：Codex沙盒的设计目标不是“如何让AI安全地Zuogeng多事”，而是“如何确保 AI 即使想Zuo坏事也Zuo不到”。 这两个kan似相似的问题，却导向了截然不同的设计思路。 前者倾向于行为检测和意图分析——一种概率性的防御； 后者则侧重于利用内核提供的强制访问控制机制，构建一个绝对的安全边界。 后者是 Codex 的核心策略。

Zui初的 Codex 沙盒采用了一种较为简单的策略配置方式：通过一个统一的SandboxPolicy结构体来定义所有权限规则。这种方式易于理解和维护，但存在明显的局限性。 例如：

// 第一代：统一策略SandboxPolicy{Type: "danger-full-access"} // 完全不限制SandboxPolicy{Type: "read-only"} // 只读SandboxPolicy{Type: "workspace-write"} // 可写工作区SandboxPolicy{Type: "external-sandbox"} // 外部沙盒

这种模式下hen难实现细粒度的权限控制——例如“允许写入工作区，但禁止修改 .git 目录”。 此外随着需求的不断演进，单一的策略结构体变得越来越臃肿和复杂。

为了解决第一代沙盒的局限性，Codex引入了第二代沙盒策略系统。该系统将文件系统权限和网络权限分离到两个独立的结构体中：FileSystemSandboxPolicy 和 NetworkSandboxPolicy。 这种分离式的设计带来了geng大的灵活性和可 性。

// 精细到每个路径、每种访问模式FileSystemSandboxPolicy{ Kind: "restricted", Entries: FileSystemSandboxEntry{ {Path: "/workspace", Access: "write"}, {Path: "/workspace/.git", Access: "read"}, // 覆盖父级 {Path: "/workspace/.codex", Access: "none"}, // 完全禁止 },}

在Linux系统中，bubblewrap 是构建安全沙箱的关键工具。它利用 Linux 内核提供的 mount namespace 功Neng创建一个全新的文件系统视图。进程kan到的文件系统与宿主机完全不同——这就像给进程戴上了一副“滤镜”，使其只Nengkan到被允许访问的部分。

宿主机 沙盒内/ / ├── usr/ ├── usr/ ├── etc/ ├── etc/ ├── home/user/ ││ └── project/ ├── home/user/project/ │ ├── src/ │ ├── src/ │ ├── .git/ │ ├── .git/ │ └── .codex/ │ └── .codex/ ├── tmp/ ├── tmp/ ├── home/user/.ssh/ │ └── home/user/.aws/ │ 

关键在于挂载顺序。 bubblewrap 以只读模式挂载根文件系统，然后以可写模式挂载允许的目录。 后挂载的目录会覆盖先挂载的目录——这保证了即使根文件系统中存在敏感信息，进程也无法修改它。

对于网络访问控制，Codex提供了三种不同的模式:

完全禁止网络：不添加任何网络规则，deny default自动拒绝一切 │代理模式：只允许连接loopback 的特定端口 │)│完全开放:+TLS / DNS 相关服务

ProxyRouted模式尤其值得关注。当设置了HTTP_PROXY=http://localhost:

进程 : connect▼内核seccomp BPF过滤器|检查 : syscall== SYS_connect|规则 : Restricted模式下拒绝connect▼返回EPERM—连接被拒绝 

-DWRITABLEROOT0=/Users /dev /my -project -DWRITABLEROOT0EXCLUDED0=/Users /dev /my -project /.git -DWRITABLEROOT0EXCLUDED1=/Users /dev /my -project /.codex