代码 Agent 启动时会自动收集仓库状态。它们运行 git status、git diff 等普通命令，目的是知道当前分支、改动文件和工作区结构。Manifold Security 发现，这条看似无害的准备路径在多个产品里绕开了沙箱与审批。
问题不在模型，也不在 Git 命令本身，而在 Agent 没有清理仓库自己的 Git 配置。某些配置项本来就允许 Git 调用辅助程序；当 Agent 后台刷新索引时，仓库指定的程序会以开发者权限在主机执行。
#攻击发生在用户操作之前
研究覆盖 Claude Code、Codex、Cursor、Goose、Grok Build、Hermes 与 Qwen Code 等七种 Agent，共记录八项发现。有的产品在用户发送第一条 Prompt 前运行 Git，有的甚至在显示或接受工作区信任提示之前执行。
这意味着产品宣称的工具审批并没有机会介入：命令是 Agent 客户端为收集上下文启动的内部子进程，不是模型发起的工具调用。攻击者一旦成功，获得的是当前开发者权限，可能接触 Shell 环境中的凭据、SSH Key 和其他本地仓库。
#风险来自“带着 .git 一起交付”的目录
正常 git clone 不会从远端复制仓库本地的 .git/config，因此仅仅克隆一个恶意 URL 不会触发这类问题。危险场景是整个项目目录连同 .git 一起被传递，例如 ZIP 包、共享盘、同步目录、U 盘或同事直接打包的工作区。
用户解压后在目录中启动代码 Agent，后台 Git 检查就可能成为触发点。这种交付方式在顾问、外包和内部协作中并不少见，也解释了为什么“先别运行项目代码”并不足以防御：Agent 为理解项目而做的准备动作已经会运行底层程序。
#同类缺陷出现在不同产品
截至文章发布，Claude Code 的一条路径、Codex、Cursor 和 Goose 已修复；Hermes、Qwen Code、Grok Build 与 Claude Code 的另一条审查路径仍被确认存在问题。Goose 和 Hermes 的发现分别获得 CVE 编号。
研究者没有公开可直接武器化的仓库，也隐去了一个仍未修复路径使用的具体配置键，但保留了足以说明漏洞类别的触发条件、受影响版本与披露时间线。这使问题指向系统设计，而不是某个单独厂商的补丁失误。
#信任边界必须覆盖“模型之外”
用户侧最直接的防护，是对以文件包形式收到的仓库先检查 .git/config，确认没有指向外部程序的异常设置，再用 Agent 打开。更稳妥的做法是从可信远端重新克隆，而不是直接运行别人打包的完整工作区。
产品侧则要为所有后台 Git 调用显式禁用可能执行程序的仓库配置，并把上下文采集放到工作区信任和沙箱边界之后。仅限制模型能调用什么命令并不够，因为 Agent 产品还有文件监听、索引刷新、插件发现和仓库分析等大量隐式行为。
GitSpawn 揭示的是一个更广泛的安全原则：Agent 的权限面等于模型工具加上宿主应用全部自动化行为。 后者如果不进入威胁模型，再严格的 Prompt 与工具审批也可能守住了错误的门。