Build · founder · 8 min read

The Repo Someone Sent You Can Run Code Before You Type Anything

GitSpawn hits seven AI coding agents. Three are still unpatched. The fix takes one command, and it is not the one you'd guess.

On September 1, Manifold Security published research on a flaw it calls GitSpawn. Eight findings across seven AI coding agents. Four of them were still unpatched when the post went live, and three of those are in tools people use every day.

The short version: if someone sends you a project folder as a zip file, and you open that folder with an AI coding agent, the folder can run a command on your computer. Not after you approve something. Not after you send a prompt. In some cases before you have even logged in.

This is worth ten minutes of your attention even if you are not technical, because the mitigation is trivial and the exposure is not.

What actually happens

Every CLI coding agent — Claude Code, Codex, Cursor’s CLI, Goose, Grok Build, Qwen Code, Hermes — does the same thing when you open a folder. It wants to know where it is. So it shells out to git and runs something ordinary, like git status or git diff --name-only HEAD, to learn the branch and which files changed.

Both of those commands make git refresh its index first. And git has a performance setting called core.fsmonitor that names a helper program git should run during that refresh. It is documented, intended behaviour, built for large repositories.

Git reads that setting from the repository’s own .git/config file. Which means the repository gets to name the program.

Put an attacker’s command in there, and the agent’s own startup routine executes it. As you. With your privileges. Outside whatever sandbox the agent applies to its own tool calls, because the permission model never sees a subprocess the agent spawned before the session began.

Manifold’s summary of what an attacker gets: your SSH keys, the cloud credentials in your environment, the tokens in your shell config, every repository on disk, and a foothold on the machine.

The one mitigating fact

git clone does not copy the source repository’s .git/config. Neither does fetch or pull.

So cloning a hostile repo from GitHub does not carry the payload. That rules out the delivery method most people worry about first.

What does carry it is anything that moves a directory instead of cloning it:

  • a shared .zip file
  • a shared drive or synced folder (Dropbox, Google Drive, OneDrive)
  • a USB stick
  • a pre-built dev container image

Manifold used a .zip for every proof of concept. And a zipped project folder is exactly how a contractor hands work to a client, how a founder shares a prototype with a technical friend, and how an agency delivers a build. This is not an exotic delivery path for this audience — it is the normal one.

Who is patched and who is not

Manifold’s table, as of its September 1 publication:

AgentStatus
CursorPatched (reported July 8)
OpenAI Codex CLIPatched
GoosePatched in 1.44.0 — CVE-2026-72718
Claude Code (core.fsmonitor path)Patched in 2.1.196 — CVE-2026-55607
Claude Code (ultrareview path)Unpatched, confirmed on 2.1.252
Grok BuildUnpatched, confirmed on 1.0.13
Qwen CodeUnpatched, confirmed on 0.22.3
Hermes AgentUnpatched, confirmed on 0.21.0 — CVE-2026-71963

Two things about that table deserve comment.

First, the second Claude Code finding is not a core.fsmonitor bug at all. It uses a different git config key that the ultrareview code path does not strip, and Manifold has deliberately left that key unnamed while it stays unfixed. It was reported on July 15 and closed as a duplicate of an internal ticket. Seven weeks later it was still reproducible.

Second, the Hermes CVE was assigned by VulnCheck, an independent CVE numbering authority — not by the vendor. Manifold made six contact attempts across five channels and the private advisory was never triaged. That is what an unresponsive vendor looks like from the outside, and it is a signal about the project, not just the bug.

What to do, in order

1. Check any folder before you open it with an agent. If a project arrived as files rather than through a clone, run this in the folder first:

git config --local --get core.fsmonitor

If it prints nothing, that specific sink is empty. If it prints a command, do not open the folder with an agent. Better still, open .git/config in a text editor and read the whole thing — core.fsmonitor is not the only setting that names a program.

2. Delete the .git directory when you don’t need the history. If a client or contractor sent you a build and you only want the code, the version history is dead weight. Removing .git removes the entire attack surface in one move.

3. Update your agents. Cursor, Codex CLI, Goose 1.44.0+, and Claude Code 2.1.196+ are covered for the main path. If you run claude ultrareview on repositories you did not create yourself, stop until Anthropic ships the fix.

4. If you use Grok Build, Qwen Code, or Hermes, treat every non-cloned folder as hostile. These are unpatched at time of writing. Grok Build’s case is the least reassuring of the three: an earlier report of the same class, filed July 1, was closed by xAI as informative, and Manifold’s follow-up two weeks later was closed as a duplicate of it.

Why this one is different from the usual AI security story

Most of the security coverage in this space is about the model doing something dumb — prompt injection, an agent talked into leaking a key, a hallucinated package name that turns out to be squattable.

GitSpawn has no model in the loop at all.

Manifold’s line is the one to remember: the vulnerability is not in the model, or in anything new. It is in the ordinary plumbing underneath — the subprocess an agent spawns at startup to work out where it is.

That reframes what “AI coding tool security” means. You are not only trusting the model’s judgment. You are trusting that a team shipping a fast-moving CLI remembered to sanitize every subprocess it invokes on your machine before you have consented to anything. Seven teams did not. Five of Manifold’s eight reports came back as duplicates of findings other researchers had filed independently, one on the same day — which means this was being discovered from multiple directions at once, and it took until September for anyone to write it up publicly.

The version of this that will keep happening

Look at the shape rather than the specific bug. A trusted host component read a config file that an untrusted party controlled.

That is the same shape as the npm worm that planted a SessionStart hook in .claude/settings.json, and the same shape as the sandbox escape where an agent wrote .claude/settings.local.json and a non-sandboxed hook engine executed it after the turn ended. Different files, identical pattern.

The practical habit, and it is a cheap one: treat every config file in a project you did not create as untrusted input. .git/config. .claude/settings.json and .claude/settings.local.json. .cursor/rules. .vscode/tasks.json. .git/hooks/.

Read them before you point an agent at the folder. It takes two minutes and it covers the whole class, not just this month’s instance of it.

Related guides

Recommended next step

Was this helpful?