Claude Code, Cursor, OpenAI Codex, and four other AI coding agents ran attacker-controlled code the instant a booby-trapped folder was opened. Before a prompt was typed, before the workspace-trust dialog appeared, and on some agents before the user had even authenticated.

What actually happened

On September 1, 2026, researcher Francisco Rosales at Manifold Security published GitSpawn: eight code-execution findings spanning seven AI coding agents, all sharing one root cause (Manifold Security). Every agent named (Claude Code, OpenAI Codex, Cursor, Block's Goose, Alibaba's Qwen Code, xAI's Grok Build, and Hermes Agent) runs git status or git diff in the background the moment a folder is opened, so it can orient itself before the user does anything. On several of them, that background call fires before the workspace-trust prompt appears, and on some, before the user has authenticated at all (The Hacker News).

That routine, unprompted git call is the entire vulnerability. Git supports a setting called core.fsmonitor, a genuine performance feature that lets Git hand off change-detection in large repositories to an external program. The setting lives in the repository's own .git/config, not anywhere global or user-controlled. Point core.fsmonitor at a script planted inside the repo, and the next git status (the one the agent runs on its own, unasked) executes it, on the host, outside whatever sandbox the agent normally runs its own actions in (Manifold Security, GBHackers).

Why a normal git clone doesn't save you

The one detail that makes GitSpawn easy to underestimate: cloning a repository the ordinary way doesn't carry this risk, because git clone builds a fresh local config and doesn't import the remote's settings. The attack needs the .git directory to arrive intact as files, which means the vector is anything that moves a folder instead of cloning it: a shared .zip, a network drive, a synced folder, a USB stick handed off at a conference or between contractors. None of that is exotic. It's how source code moves around outside of GitHub every day, especially between organizations that don't share a git remote.

Once that folder lands on disk and an AI coding agent is pointed at it, the compromise doesn't wait for a decision. There is nothing to click through, nothing to approve, and nothing that shows up on screen. The payload runs with the developer's own local privileges, the same account that holds SSH keys, cloud CLI credentials, API tokens in shell config, and read access to every other repository on that machine.

Patched, unpatched, and stuck in between

By Manifold's retest on September 1, three of the seven agents had shipped fixes: Goose, Cursor, and one of the two vulnerable paths in Claude Code. Four findings were still exploitable at publication: Hermes Agent, Qwen Code, Grok Build, and a second, separate configuration path in Claude Code (The Hacker News, Cyberpress). GitHub's advisory for the Goose finding assigned it CVE-2026-72718 with a CVSS base score of 7.0, crediting Rosales. VulnCheck, acting as an independent CVE Numbering Authority rather than the vendor, separately assigned CVE-2026-71963 to the Claude Code finding, though The Hacker News noted that as of September 2, MITRE's public CVE list didn't yet show a corresponding record (The Hacker News).

Claude Code's history with this exact behavior is also worth knowing, because it shows how easily a fixed trust-boundary bug can come back. Sonar had already reported a version of this problem, git status executing before Claude Code's trust dialog, back in April 2026; it was mitigated in version 2.0.34 and fixed properly in 2.0.71 by no longer running git status ahead of trust approval (Sonar). The same startup behavior reappeared in version 2.1.193 on June 25, was reported again the next day, and was closed as a duplicate of an earlier report rather than tracked as a regression. That is roughly how a second, still-open path was still live on Manifold's September 1 retest.

The suggested vendor fix is almost anticlimactic given the impact: call git -c core.fsmonitor=false status for background context-gathering instead of a bare git status. One flag, no architecture change, no user-visible behavior difference, and it closes the entire class of silent, pre-authentication execution this disclosure is built around.

What to do about it, regardless of which agent you run

  1. Disable the setting globally, today. git config --global core.fsmonitor false closes the primary vector for every repository on that machine, regardless of whether your specific agent has patched yet.
  2. Treat any repo that arrived as files, not a clone, as untrusted until checked. Before opening a .zip, network-drive copy, or USB-delivered folder in an AI coding agent or an IDE, inspect its .git/config for core.fsmonitor, core.hooksPath, or clean/smudge filters.
  3. Update your agents now. Goose, Cursor, and Claude Code's primary path have fixes; confirm your fleet is on a patched build rather than assuming auto-update caught it.
  4. Push the mitigation through configuration management, not developer memory. A one-line git default is exactly the kind of control that should live in your endpoint baseline or onboarding image, not in a wiki page nobody rereads.
  5. Watch for regressions, not just initial fixes. Claude Code's own history here shows a patched trust-boundary bug can resurface in a later release; if you rely on a vendor's fix, periodically re-verify it rather than treating "patched" as permanent.

Where MBCTG fits

This is a governance gap as much as a technical one: most organizations that rolled out AI coding agents did it faster than they extended their tool-approval process to cover what those agents do before a human ever clicks anything. That's exactly the review our AI Integration work is built around: assessing what an AI tool can actually reach and do, in your environment, before it's standard-issue for every developer. For teams that need that evaluation turned into a repeatable, auditable process rather than a one-time check, our GRC services help make tool approval a documented control instead of an assumption.

Not sure what your own developer fleet's git defaults look like, or whether your AI coding agents were part of any security review before rollout? Talk to an MBCTG expert. Auditing agent trust boundaries is a fast, concrete place to start.