OpenAI 刚刚在 GitHub 上发布了 codex-security —— 这是一款可通过 npm 安装的扫描器，它会对代码库进行三阶段分析，并尝试自动修复漏洞。
此次发布所掩盖的是一个更深层次的缺陷，而最近的沙箱绕过演示已经揭示了这一点。研究人员表明，在 Cursor、Codex CLI、Gemini CLI 和 Google Antigravity 等工具的“封闭式”环境中运行的代理（agents），仍然可以通过利用连接沙箱与宿主系统的接口来逃避预期的保护。新的 OpenAI 扫描器并未触及这一攻击面。
绕过原理
代理虽然留在容器内部，但它们写入磁盘的所有内容都会立即被外部辅助工具（如 git 钩子、Python 扩展、Docker 守护进程及类似服务）所信任。这些辅助工具会读取文件，将其视为合法文件，并在不提示用户的情况下在宿主系统上执行它们。
- Cursor 允许代理注册一个在沙箱之外运行的 git 钩子。
- Codex CLI 未能验证 git 命令中的参数，从而为任意执行打开了路径。
- 若干代理获得了对 Docker socket 的直接访问权限，这是一个特权入口点，允许代码在宿主机器上启动容器。
- DuneSlide 漏洞允许攻击者覆盖执行沙箱强制约束的组件，从而有效地彻底拆除这道“围墙”。
在每种情况下，漏洞利用都是静默发生的——它可能是一个网页搜索结果，或者是代理所消耗的一个多选提示 (MCP) 工具的响应。恶意负载执行后随即消失，从未出现在静态代码扫描中。
为什么 OpenAI 的工具没能解决问题
Codex-security 专注于静态分析：它检查你提交的源文件，标记不安全模式，并可以自动重写它们。这种方法可以在代码发布前捕获粗糙或危险的代码，但它扫描的是你发布的代码，而攻击却发生在代理自身的运行时环境中。
沙箱绕过表明，真正的危险在于 AI 沙箱与开发者其余工具链之间的运行时桥接 (runtime bridge)。攻击者不需要向代码库注入恶意代码；他们只需要说服沙箱内的代理写入一个文件，随后由外部进程执行该文件即可。
谁是赢家，谁是输家
- 开发者
- 工具厂商
- OpenAI
- 攻击者
社区现在可以做什么
真正重要的修复是操作层面的，而不仅仅是代码层面的。以下是任何集成 AI 编程代理的人都应该采取的实际步骤：
- 固定代理版本，并在升级前阅读变更日志。新版本可能会在无意中开启新的钩子或套接字。
- 将“克隆并探索”视为运行未知代码。在没有额外隔离的情况下，切勿让代理指向你不控制的代码库。
- 审计每一个辅助工具（git 钩子、Python 扩展、Docker 访问权限）。如果一个工具可以根据代理的输出修改目录或符号链接，请假设它可以被武器化。
- 从沙箱中移除 Docker socket 访问权限。
- 弄清楚“谁在读取什么”。映射从沙箱到宿主的数据流；任何消耗代理所写文件的进程都必须经过严格审查。
反方观点：为什么 codex-security 仍然重要
该扫描器改善了问题的一个侧面，但它并不能取代加强运行时桥接的需求。
下一步值得关注的内容
- 社区驱动的加固指南，这类指南会为 AI 代理配合常用的开发者工具链提供安全配置目录。
标题可能在庆祝一个新的安全扫描器，但真实的情况是，如果周围的生态系统继续信任 AI 编程代理写入的一切，那么它的沙箱就仅仅是一个幌子。下一波保护浪潮必须开始将目光从代码本身转向执行代码的流水线。