AI编程工具集体翻车:沙箱没拦住宿主机

大家好，我是宇哥，专注AI编程、智能体，解决小白AI编程问题。

AI 编程工具这次又把一个老问题放大了。

很多人以为，只要把 Coding Agent 放进沙箱，它就不会碰到宿主机。

但 Pillar Security 最近披露的一组研究显示，事情没这么简单。

Cursor、OpenAI Codex CLI、Google Gemini CLI、Antigravity 等工具都被研究人员复现过沙箱逃逸或边界绕过链路。BleepingComputer、CSO Online、Techzine、The Next Web 等媒体也陆续跟进报道。

最值得注意的是：

这些案例里，Agent 很多时候并没有“正面打穿沙箱”。

它只是写了一个文件，然后宿主机上某个被信任的工具，把这个文件当成配置、脚本、任务或元数据执行了。

也就是说，真正危险的不是“Agent 自己跑出去了”。

而是：Agent 留下的文件，被宿主机当成可信输入继续执行。

这对每天用 Cursor、Codex CLI、Gemini CLI、Claude Code、各种 AI IDE 的开发者来说，比单个 CVE 更重要。

因为它提醒我们：

AI 编程时代，项目目录不再只是代码仓库，它正在变成 Agent 和宿主机之间的信任边界。

01｜这次到底曝出了什么？

先把事件讲清楚。

Pillar Security 把这组研究称为 The Week of Sandbox Escapes。

他们在数月时间里，复现并披露了多个 AI 编程工具里的沙箱逃逸和边界绕过问题，涉及 Cursor、Codex CLI、Gemini CLI、Antigravity 等。

公开资料里提到的关键点包括：

Cursor 中，一个 workspace 控制的 .claude hook 配置可变成非沙箱命令执行路径；该问题被标记为 CVE-2026-48124，Cursor 在 3.0.0 中修复；
Cursor 另有问题涉及 Python virtualenv interpreter，被编辑器的 Python 扩展在发现流程中执行；
Cursor 还出现过 Git metadata 绕过路径规则、触发 fsmonitor 的链路；
Codex CLI 中，一个看似安全的 git show allowlist 只信任命令名，没有充分约束实际调用和副作用；OpenAI 在 v0.95.0 修复，并支付高危漏洞赏金；
一个 Docker socket 相关问题同时影响 Codex CLI、Cursor 和 Gemini CLI，因为本地 privileged daemon 本身在沙箱外；
Antigravity 相关问题涉及 macOS Seatbelt denylist 绕过和 .vscode task config 绕过 Secure Mode；Google 对部分问题降低了严重性评级，认为需要社会工程或用户信任恶意仓库。

这些细节听起来很安全圈。

但抽象成一句话，其实很好懂：

Agent 没有必要直接越狱。

它只要能写下未来会被宿主机信任的文件，就可能间接越界。

这才是这次事件的核心。

▲ 这次关键不是 Agent 正面打穿沙箱，而是它写入的项目文件被宿主机上的可信工具继续执行。

02｜为什么“沙箱内写文件”也会危险？

很多开发者对沙箱的直觉是：

沙箱内可以随便折腾，宿主机是安全的。

这个直觉在传统场景里大体成立。

但 AI 编程工具的特殊之处在于：它工作的位置就是项目目录。

项目目录里有很多东西，本来就会被宿主机上的工具读取和执行：

.vscode/tasks.json 可能触发任务；
Git 配置和 metadata 可能影响 Git 行为；
Python virtualenv 会被编辑器扩展扫描；
hook 配置可能在某个生命周期点执行命令；
Docker socket 可能让本地 daemon 帮你跑容器；
package manager、language server、test runner、IDE 插件都会读项目文件。

以前这些文件主要由人写。

人写的时候，大家默认它们经过某种人工判断。

现在 Agent 也能写。

而且 Agent 会读 README、issue、diff、依赖说明、网页内容、日志、错误信息。

这些内容里一旦混入恶意提示，Agent 就可能被引导去生成某个看似正常、但会被外部工具消费的文件。

它不需要自己执行危险命令。

它只需要把“下一步要执行的东西”放到宿主机会读取的位置。

这就是最麻烦的地方。

沙箱限制的是 Agent 直接能做什么，但不一定限制宿主机后来会如何相信它写下的东西。

▲ AI 编程工具的真实边界不是一个进程，而是 Agent、项目文件、IDE 插件、Git、Docker、语言运行时之间的信任传递。

03｜这不是某一家工具的问题

如果只有一个工具出问题，那可以写成“某某工具翻车”。

但这次不适合这么写。

Pillar 把这些案例归纳成四类重复出现的失败模式：

第一，denylist 跟不上操作系统复杂度。

如果沙箱策略是“默认允许，再列出禁止项”，那它永远可能漏掉新的系统能力、本地服务、挂载方式、启动路径和组合玩法。

AI Agent 还特别擅长试错、组合和绕路。

这会放大 denylist 的天然短板。

第二，workspace config 本质上经常是代码。

很多项目配置不是静态说明，而是会触发构建、测试、启动、hook、task、formatter、linter、语言服务行为。

当 Agent 能写这些配置，而宿主机工具又直接信任这些配置，沙箱边界就被绕开了。

第三，safe command 不能只按命令名判断。

git show 看起来像只读命令。

但真实世界里，命令是否安全要看参数、目录、配置、helper、hook、副作用。

只看命令名，很容易把“看起来安全”误判成“实际安全”。

第四，本地 privileged daemon 本来就在沙箱外。

Docker Desktop、语言服务器、包管理器、云 CLI、本地数据库、构建 daemon，很多都不是 Agent 进程的一部分。

如果 Agent 能碰到这些入口，危险动作可能不是 Agent 执行的，而是这些本地服务替它执行的。

所以这次真正暴露的不是单点漏洞。

而是一个新现实：

AI 编程工具把开发者机器变成了多主体协作环境。Agent、IDE、CLI、Docker、Git、语言扩展都在同一个项目目录里传递信任。

只保护 Agent 进程，已经不够了。

▲ 这类问题不是某个产品的偶发 bug，而是 AI 编程工具共同面对的新型信任边界问题。

04｜Prompt Injection 为什么在这里更危险？

很多人听到 prompt injection，会觉得只是“让模型说错话”。

但在 Coding Agent 场景里，它不是让模型说错话。

而是让模型做错事。

更准确地说，是让模型写下会让别的系统做错事的文件。

攻击入口可能很普通：

一个 README；
一个 issue；
一个 PR diff；
一个依赖包说明；
一段日志；
一个网页文档；
一段注释；
一个项目模板。

Agent 的工作就是阅读这些东西，然后动手改项目。

如果恶意提示混在里面，Agent 可能把它当成任务要求的一部分。

传统聊天机器人被注入，最坏可能输出敏感信息或错误答案。

Coding Agent 被注入，可能修改项目状态、写入配置、改变测试流程、污染构建脚本、影响本地工具行为。

这就是为什么 AI 编程安全不能只看模型有没有“守规则”。

你还要看：

它读了哪些不可信输入；
它能写哪些文件；
哪些文件会被宿主机自动消费；
哪些本地工具会在不询问用户的情况下执行；
哪些动作绕过了原本给 Agent 的审批提示。

换句话说：

Agent 的输出，不应该天然被当成可信开发者输入。

这是很多工具现在还没完全适应的地方。

05｜开发者现在应该怎么做？

这类问题不代表你不能用 AI 编程工具。

恰恰相反，AI 编程工具已经足够强，才会触碰这些真实边界。

但使用方式要升级。

下面这份清单，比“恐慌不用”更有价值。

第一，马上升级相关工具。

如果你用 Cursor、Codex CLI、Gemini CLI、Antigravity 或类似工具，先检查版本。

公开资料显示，Cursor 多个问题在 3.0.0 中修复；Codex CLI 相关问题在 v0.95.0 修复；其他工具也有对应修复或缓解措施。

不要长期停在旧版本。

第二，不要在不可信仓库里直接开 Agent。

陌生 repo、别人发来的 demo、面试题仓库、开源依赖复现项目、issue 里贴的压缩包，都不要直接让 Agent 全权限处理。

至少先做：

单独目录；
无敏感凭据；
不挂载 SSH key；
不连生产云账号；
不暴露 Docker socket；
禁止自动运行任务。

第三，把 workspace 配置当成高风险文件。

以前你可能只 review 业务代码。

现在还要重点看：

.vscode/；
.claude/；
.cursor/；
Git config / hooks / metadata；
virtualenv；
package scripts；
CI 配置；
Docker compose；
Makefile；
shell 脚本；
language server 配置。

这些文件一旦被 Agent 改动，不能只看成普通文本变化。

要看它们会不会触发执行路径。

第四，限制 Docker socket 和本地 daemon。

Docker socket 是很多开发环境里的隐形高权限入口。

如果 Agent 能访问它，就可能让 Docker daemon 在沙箱外执行动作。

如果没有明确需要，不要把宿主机 Docker socket 暴露给 Agent 环境。

同理，本地云 CLI、数据库、构建 daemon、包发布工具，也应该按最小权限处理。

第五，审批不能只审批“命令名”。

看起来安全的命令，带上特定参数、配置、目录和环境变量后，可能完全不同。

以后 AI 工具的审批提示最好不要只显示：

“要执行 git show，是否允许？”

而要让用户看见：

完整命令；
工作目录；
影响文件；
是否读取或写入配置；
是否触发 hook/helper；
是否访问本地 daemon；
是否由 Agent 新写文件触发。

只有这样，审批才不是安慰剂。

▲ 开发者使用 AI 编程工具时，真正要管的是 Agent 能写什么，以及宿主机会不会自动相信这些文件。

06｜企业采购 AI IDE，要问哪些问题？

如果你在企业里推动 AI 编程工具，不能只问“有没有沙箱”。

这个问题已经不够了。

更应该问供应商这些问题：

Agent 能写哪些路径？
哪些 workspace 配置会被视为敏感？
Agent 写入的文件有没有 provenance 标记？
宿主机哪些组件会读取 Agent 写的文件？
helper 进程是否套用同一套安全策略？
本地 Docker socket、云 CLI、语言服务器如何隔离？
safe command allowlist 是按命令名、参数，还是副作用建模？
Agent 修改 hook、task、CI、package script 时是否强制人工审批？
是否能区分人写的文件、仓库原有文件、Agent 新写文件？
当宿主机工具执行了 Agent 影响过的内容时，有没有日志和告警？

这些问题听起来细。

但这才是 AI 编程进入企业后的真实采购问题。

以前 IDE 是开发工具。

现在 Agentic IDE 更像一个 endpoint actor。

它能读代码、改代码、跑命令、触发工具、调用 API、改配置、连接云服务。

如果企业只把它当“更聪明的代码补全”，风险一定会被低估。

07｜这件事说明 AI 编程进入新阶段了

我不觉得这次事件应该被解读成“AI 编程工具不能用”。

恰恰相反，它说明 AI 编程工具已经进入真实生产环境。

只有当 Agent 真的开始改仓库、跑测试、调用工具、处理复杂项目，才会暴露这类边界问题。

早期 Copilot 时代，模型只是补全几行代码。

那时安全问题主要是代码质量、许可证、幻觉和漏洞建议。

现在 Coding Agent 要做的是：

读完整仓库；
理解上下文；
自己改文件；
自己跑命令；
自己修测试；
自己调用工具；
自己推进任务。

这已经不是“补全工具”。

它是一个能在开发者机器上行动的自动化主体。

所以安全模型也必须变化。

未来 AI 编程工具比拼的不只是：

哪个模型更会写代码；
哪个 benchmark 更高；
哪个上下文更长；
哪个 token 更便宜。

还要比拼：

权限边界；
审批设计；
文件来源追踪；
host-side automation 管控；
本地 daemon 隔离；
企业策略；
运行日志和事后审计。

开发者体验和安全治理，不再是两个独立问题。

AI 编程工具越自动化，越需要可解释、可审计、可限制的边界。

08｜结尾：沙箱不是终点，信任边界才是重点

这次 Cursor、Codex CLI、Gemini CLI、Antigravity 相关研究，最值得记住的不是某个漏洞编号。

而是一句话：

Agent 的爆炸半径，不是 Agent 进程本身，而是它能写下、并被宿主机信任的一切东西。

以前我们说“把 Agent 放进沙箱”。

现在要继续追问：

它能写什么？
谁会读它写的东西？
谁会执行它写的东西？
哪些动作绕过了用户审批？
哪些本地服务其实在沙箱外？
哪些日志能证明边界真的被守住？

AI 编程工具没有因为这次事件失去价值。

但它们必须从“功能发布”进入“安全工程”阶段。

对于个人开发者，最现实的建议是：升级工具、隔离不可信仓库、重点 review 配置文件、谨慎开放 Docker socket 和本地凭据。

对于企业，最现实的建议是：不要只买“有沙箱”的 AI IDE，要买能解释清楚信任边界、文件来源、helper 执行和审计链路的 AI 开发平台。

沙箱当然重要。

但在 Agent 时代，真正的问题是：

沙箱外面，到底谁在相信 Agent 写下的东西？

资料来源

Pillar Security：The Week of Sandbox Escapes，2026-07-20
Pillar Security：The hook was already in the workspace，2026-07-20
BleepingComputer：Cursor, Codex, Gemini CLI, Antigravity hit by sandbox escapes
CSO Online：AI agents can escape sandboxes without ever breaking them，2026-07-21
Techzine：Researchers bypass sandbox security in Cursor, Codex, and Gemini CLI
The Next Web：Researchers escaped four top AI coding agents’ sandboxes without ever breaking them