GitSpawn: a zipped repo runs code in your coding agent

Somebody emails you a zip of a client's codebase. You unzip it, point Claude Code or Codex at the folder, and before you type a single word, the repo has already run a command on your laptop. That's GitSpawn, a vulnerability class Manifold Security disclosed on September 1 across eight findings in seven coding agents. There is no model exploit here and no clever prompt injection. It's Git doing exactly what Git has always done, in a place nobody put a permission check.

What actually happened

Every CLI coding agent gathers context at startup by shelling out to Git — git status, git diff, whatever tells it where it is. Those commands refresh Git's index. And index refresh honors core.fsmonitor, a legitimate performance setting whose value is a command Git executes, read from the repository's own .git/config.

So the attacker doesn't need your agent to be tricked. They need your agent to look at the repo.

The exploitation prerequisite is the interesting constraint: the repository has to arrive as files with the .git directory intact — a zip, a shared drive, a USB stick, a client handoff. A normal git clone is safe, because clone writes its own config. Timing varies by agent, and it is worse than you'd hope: payloads fire before the workspace-trust prompt on Claude Code, before authentication on Qwen Code, and on the first keystroke in Grok Build.

Manifold's status table as published:

• Claude Code — core.fsmonitor path patched in 2.1.196; a second path via ultrareview reported at 2.1.252, unpatched
• goose — fixed in 1.44.0, tracked as CVE-2026-72718
• OpenAI Codex and Cursor — patched
• Hermes Agent (CVE-2026-71963), Qwen Code, Grok Build — unpatched at disclosure

Vendor response was uneven. The Hacker News reports Alibaba accepted the Qwen Code report on July 7 without shipping a fix, and Nous Research left the Hermes advisory untriaged across six contact attempts. No confirmed in-the-wild exploitation yet.

Why this matters for your business

If your team runs coding agents, you have quietly changed your threat model and nobody wrote it down. The old rule was "don't run untrusted code." The new rule has to be "opening a folder is running code," because the agent executes subprocesses on your behalf before it shows you anything.

Think about how repos actually reach a small studio. A client sends a zip because they don't want to add you to their GitHub org. A contractor drops a folder in Drive. You restore a project from a backup archive. Every one of those paths carries .git/config along for the ride, and every one of them skips the clone that would have sanitized it.

The fix Manifold recommends is one flag on the calls the agent makes in the background:

git -c core.fsmonitor=false status

That is a vendor-side change. What you control is the intake path. Treat any repo that arrives as files, not as a clone, as untrusted: cat .git/config before you open the folder, or delete .git and re-init if you only needed the code. Better, do the first pass in a container or a VM. And update your agents — the patched versions above exist, but only if somebody actually pulls them.

Sources: Manifold Security, The Hacker News.