GitSpawn: A Booby-Trapped Repo Can Run Code the Moment Claude Code, Cursor or Codex Opens It

Disclosed on September 1, 2026 by Manifold Security, GitSpawn lets a booby-trapped repository run attacker code the instant it's opened with an AI coding agent — no prompt typed, no approval clicked, sometimes before you've even authenticated. Seven agents were affected, including Claude Code, Cursor and Codex. Four fixes have shipped. Four issues have not.

Key takeaways

• GitSpawn abuses git's core.fsmonitor setting, a performance option that lets a repository specify a helper command git runs automatically whenever its index refreshes — which happens on routine background commands like git status or git diff.
• Every AI coding agent Manifold examined runs those commands silently on startup to gather project context for the model, before the user types anything — which means the malicious command fires without any interaction at all.
• It doesn't spread through normal git operations. git clone, fetch, and pull don't transfer a repo's local .git/config, so the payload has to arrive as raw files — a ZIP, a shared drive, a USB stick, a handoff from a contractor — with the hidden .git directory intact.
• Eight issues, seven agents, four still unpatched at publication: Goose, Codex, Cursor and Claude Code's core.fsmonitor path are fixed. Hermes Agent, Qwen Code, Grok Build, and a separate flaw in Claude Code's ultrareview command are not.
• This isn't a novel bug class. VS Code shipped a fix for the same root pattern — code execution on opening a workspace — back in 2021. AI coding agents reintroduced it independently, at scale, by adding background git calls without sanitizing what a repo's own configuration can trigger.

How the exploit actually works

Almost every CLI-based coding agent gathers context the moment it starts up in a project directory — what branch you're on, what's changed, what's staged — by quietly running standard git commands in the background. That's a reasonable thing for an AI coding agent to do. The problem is what git itself is allowed to do in response.

core.fsmonitor is a legitimate git performance setting: instead of scanning the whole working tree for changes, git can delegate that to a helper program named in the setting, and trust its answer. That helper program is defined in the repository's own .git/config — which means whoever controls the repo controls what runs. Any command that refreshes git's index, including the background status and diff calls every agent runs automatically, executes it. No prompt has to be typed. No tool call has to be approved. In some configurations, this fires before the user has even authenticated with the agent.

The one mercy is distribution: standard git clone, fetch, and pull operations never transfer another repository's local .git/config, so GitSpawn can't propagate through ordinary git workflows. An attacker has to get the raw files — .git directory included — onto the target's machine some other way: a ZIP archive, a shared project folder, a synced cloud drive, a USB stick, or simply a colleague or contractor handing over "the project files" directly rather than a repo URL. All of those are routine, unremarkable ways developers actually receive code.

Which agents are affected — and which are still open

If your team uses any tool on the unpatched side of this table, treat repositories received outside a direct git clone as untrusted until you've manually checked .git/config for a core.fsmonitor entry — or an equivalent hook — before opening them in the agent.

Why your existing security program probably doesn't cover this

• It's not a vulnerability in your application code. Static analysis, dependency scanning, and code review all look at what a project's source does — not at what a developer's AI tooling does before a single line of that source is read.
• It's not covered by a standard AI agent review either. Most organisations scoping "AI agent security" mean the production agent talking to customers or internal systems — not the coding assistant running on an engineer's laptop with full filesystem and shell access.
• It lives at the exact seam most annual pentests skip. Source code review typically starts after checkout. AI agent testing typically starts after deployment. The moment in between — an untrusted repository landing on a developer's machine and being opened by a tool with execution rights — falls between both scopes.
• Developer machines are high-value, low-visibility targets. They hold SSH keys, cloud credentials, package registry tokens, and access to every repo the developer can reach — exactly the blast radius a supply-chain-style compromise is built to reach.

How ComplyArmor tests this attack surface

This falls at the intersection of two attack surfaces we already test: Source Code and AI Agents & LLM Applications, covered under our Smart PTaaS model of continuous testing rather than an annual snapshot. Findings map to LLM03:2025 Supply Chain Vulnerabilities in the OWASP Top 10 for LLM Applications — the same taxonomy referenced throughout this site.

• Agent startup behaviour audit. What commands does the coding agent run automatically on repo open, before any user interaction — and can those commands be redirected by the repository's own configuration?
• Trust boundary verification. Does the agent treat "a folder I was handed" the same as "a repo I explicitly cloned and reviewed" — the exact distinction GitSpawn relies on being absent?
• Tooling inventory across the engineering org. Which AI coding agents are actually in use, at what versions, and whether any sit on the unpatched side of a disclosure like this one — visibility most security teams don't currently have.
• Verified exploitation, not a version-number check. We reproduce the actual code execution path against a controlled target, the same standard we hold every engagement to, rather than flagging an outdated version and calling it done.

What to do this week

1. Inventory which AI coding agents your engineers actually run. Adoption of these tools moves faster than most security reviews, so assume the list is longer than IT expects.
2. Patch immediately on Goose, Codex, Cursor, and Claude Code's core.fsmonitor path.
3. Flag Hermes Agent, Qwen Code, and Grok Build as currently exposed and treat any repo not received via direct git clone as untrusted until inspected.
4. Set a policy for how developers receive code that isn't a clone — ZIPs, shared drives, and handoffs from external contractors are the realistic delivery path here, not phishing links.
5. Treat this as a class of risk, not a single patch. The same root pattern was fixed in VS Code in 2021 and reappeared in seven unrelated tools in 2026 — the next reintroduction is a matter of when, not if.

Frequently asked questions

Four of these eight issues are still open. The safest assumption for any engineering org is that "opening a project" and "running untrusted code" are the same action now — and that's worth testing, not just patching around.