9月1日，安全公司 Manifold Security 公开了名为 GitSpawn 的研究成果：Claude Code、Codex、Cursor、Grok 等主流 AI 编码代理存在一类共性缺陷，只要代理加载了攻击者构造的 git 仓库，后者就能借仓库自带的 git 配置在用户机器上执行任意代码，全程不需要用户点击或确认。
问题的根子在 git 的配置机制上。AI 编码代理启动时通常会自动执行一组 git 命令来读取仓库状态、初始化环境，而 git 允许仓库通过 .git/config 挂载自定义行为，比如 core.fsmonitor 这类原本用于提升性能的配置项可以指向一个外部程序。研究人员发现，多款代理在克隆或打开项目时没有隔离、清理这些配置，恶意仓库只要预埋好对应字段，代理一启动就会替攻击者把代码跑起来，用户看到的可能只是“正在读取仓库”的普通提示。
这类攻击面并不新鲜。git 配置注入是老问题，core.fsmonitor、core.pager 等配置项在以往讨论“别随便克隆陌生仓库”时就被反复点名，git 官方文档也长期警告不要随意处理来源不明的仓库。真正变化在于使用场景：过去克隆陌生仓库是开发者偶发的个人动作，如今 AI 编码代理把它变成了自动化工作流的标准步骤，“把仓库丢给代理跑”越来越常见，人工审查这一环恰恰被省掉了。
受影响的产品与规模：
- 被点名存在问题的代理包括 Claude Code、Codex、Cursor、Grok Build、Goose、Hermes、Qwen Code 等
- Claude Code 的 npm 包月下载量超过 7700 万
- 相关项目在 GitHub 上的星标合计接近 50 万，其中 Hermes 超 23.7 万、Claude Code 超 14.3 万、Goose 约 5.4 万、Qwen Code 约 2.7 万、Grok Build 约 2.6 万
披露与修补方面，研究共报告了八个问题，均已提交相关厂商，其中四个在研究发布时仍未修补，其余已随近期版本修复。用户侧能做的事比较直接：把代理升级到最新版本；不要让代理随手克隆来源不明的仓库；确需处理不可信代码时，先检查 .git/config 里的可疑配置项，或者把代理关进容器、虚拟机这类隔离环境里再跑。
从趋势看（这是分析而非研究结论），这不会是 AI 编码代理最后一起“旧漏洞、新场景”的安全事件。git、shell、包管理器里的老问题一直都在，代理只是把它们从“需要人手触发”变成了“自动触发”，安全边界因此整体后移。对开发者而言，把 AI 代理当成一个不该拥有完整信任权限的实习生来对待，是目前成本最低的防御姿势。
