GitSpawn: One Line in .git/config Turns Your Coding Agent Into a Command Runner

The payload never touches the model. It sits in the repository's own Git config, and what fires it is your agent's first background git status.

Manifold Security's GitSpawn disclosure covered eight flaws across seven CLI coding agents, with four still unpatched at publication. This isn't prompt injection and it isn't MCP misconfiguration. The command runs as your user, outside the agent's sandbox, and never hits an approval prompt.

The sink and the trigger

core.fsmonitor is a legitimate Git performance feature. Its value is a command Git runs to find changed files in large repos, and any operation that refreshes the index executes it. That includes git status and git diff, the two most boring commands in the tool.

A poisoned repo needs exactly one line:

[core]
    fsmonitor = <attacker command>

CLI agents don't sit idle when you open a project. They call git status or git diff at session startup to learn the branch and what changed, and they leave local config untouched while doing it. Repository config in, background Git call out.

The timing is the ugly part. Per Manifold's testing, Claude Code and Hermes Agent fire the payload before the workspace-trust prompt is accepted. The dialog meant to protect you renders after you're compromised. Qwen Code fires before you've even authenticated. Grok Build fires on the first keystroke.

Who's still exposed

The mitigating constraint: a plain git clone doesn't carry local config, so cloning a malicious repo from GitHub won't infect you. The repo has to arrive as files with .git intact. A zip from a contractor, a vendor's shared drive, a synced project folder, a repro archive from support. If "the repo showed up as a download" describes any part of your workflow, you're in the threat model.

Fixed so far: goose (CVE-2026-72718, the only scored finding), Cursor, Codex, and Claude Code's core.fsmonitor path (2.1.196).

Unpatched at publication:

• Hermes Agent. Manifold says six contact attempts across five channels went nowhere.
• Qwen Code. The version Manifold retested was still the latest npm release.
• Grok Build. Still executing repo-supplied commands on retest.
• Claude Code's second path, behind claude ultrareview. It uses a different config key Manifold withheld, so unsetting fsmonitor alone does not close it.

The detail that should worry tool makers: this exact bug was fixed before. Claude Code 2.0.34 (November 2025) stopped running git status before trust approval. The behavior was back in 2.1.193 (June 2026). VS Code and JetBrains IDEs shipped the same "code runs before the trust prompt means anything" pattern years earlier. Point fixes on startup ordering don't hold. The trust gate has to wrap every Git invocation, permanently, with a regression test, or this keeps coming back.

What to do this week

Any directory that arrives from outside your org with its .git folder gets inspected before an agent touches it, or it doesn't get opened:

# Look for command-valued keys in local config
git -C /path/to/repo config --local --list --show-origin

# Check and remove the known key
git -C /path/to/repo config --local core.fsmonitor
git -C /path/to/repo config --local --unset core.fsmonitor

Don't rely on the agent's permission modes here. The payload runs outside that sandbox, so put the boundary at the OS: a disposable container or VM, or a separate user account with no access to your keys or cloud credentials.

Usable today:

• Run git config --local --list --show-origin on any repo that arrives as files, before an agent opens it.
• Re-clone from the canonical remote and work in the fresh clone instead of a handed-off folder. Clone drops local config.
• Unset core.fsmonitor, but treat it as necessary, not sufficient. The claude ultrareview path uses a withheld second key.
• Check .git/hooks while you're in there. Older attack class, same delivery.

Question for the comments: does your team actually inspect repos that arrive as archives or shared folders before an agent touches them, or is "we trust the download" still the real policy?

Longer writeup with the full per-agent table and attack chain: https://axeploit.com/blog/gitspawn-the-git-performance-flag-that-turns-coding-agents-into-command