GitSpawn: Your Agent Runs Git. The Repo Picks the Command.

Manifold Security published GitSpawn on 1 September 2026: AI coding agents gather repository context with ordinary git commands, those commands refresh the index, and Git will run a program named in the repository's own configuration. The model is not in that path. Neither is the agent's permission prompt.

That is a strong claim, so we reproduced the documented sink ourselves. The helper in this lab only appends a line to a local log. It does not touch secrets, open a network socket, or ship as a zip anyone could send a colleague. Manifold withheld a ready-made repository for the same reason.

High Arbitrary host execution as the developer, outside the agent sandbox, with no approval prompt. Severity here follows the Goose advisory (CVSS 4.0 base 7.0) rather than the higher Codex Desktop score, because a person still has to open a received folder.

What Git actually does#

core.fsmonitor is a performance setting. For a large working tree, Git asks a helper which files changed instead of walking the disk. The git-config documentation says the value may be a boolean that starts the built-in daemon, or the pathname of a hook command. Git reads that value from the repository's own .git/config. Any command that refreshes the index, including git status and git diff, invokes it.

That is intended behavior. It is also an execution sink. A folder that still contains the attacker's .git directory can name the helper. A git clone cannot, because clone builds a new local config and leaves the source file behind.

What the agents add#

Coding agents run those same git commands to work out the branch, the dirty files, or the diff they are about to review. Manifold's write-up, and the Goose advisory that followed it, are specific about the failure: the agent passed the repository config through untouched. Goose's review path added only -c core.quotePath=off. It did not strip core.fsmonitor.

The Goose maintainers documented the result in GHSA-r5pp-p5r8-466r as CVE-2026-72718. goose review gathers git diff HEAD before it contacts a model. A malicious local config executes on the host, unsandboxed, with the user's environment.

Manifold reported the same class in Claude Code, Cursor, Codex, Hermes, Qwen Code, and Grok Build, and said it found the pattern in agents it did not name. OpenAI published CVE-2026-19592 and CVE-2026-19593 for Codex the same day the research went public. Those records describe the same shape: metadata collection, a preserved .git/config, and a helper that runs outside the command sandbox.

What we ran#

We used the vulnerable Goose 1.41.0 Linux binary named in the advisory, then the patched 1.44.0 binary from the same GitHub releases. The repository lived under /tmp. The helper wrote only to /tmp/gitspawn-lab/EXECUTED.log and then exited so Git would fall back to a normal scan.

1. 2026-09-07
   git status and git diff HEAD in the received folder each invoked the helper twice, once per fsmonitor protocol version.
2. 2026-09-07
   git -c core.fsmonitor=false status left the marker at zero bytes.
3. 2026-09-07
   git clone of the same folder dropped core.fsmonitor. status in the clone left the marker empty.
4. 2026-09-07
   A zip of the folder preserved the local config. status after unzip invoked the helper again.
5. 2026-09-07
   goose review on 1.41.0 invoked the helper six times and printed that it had no REVIEW.md checks. No prompt. No model.
6. 2026-09-07
   goose review on 1.44.0 against the same dirty tree left the marker at zero bytes. The patched binary contains -c core.fsmonitor=false.

The recording is the same session, cropped to the terminal.

Two stills if you would rather not play the loop:

Who is affected#

The table is a scorecard, not a guarantee. Manifold said it found the pattern in more agents than it named. Codex Desktop's record also names attr.tree plus a clean or process filter, which is a reminder that core.fsmonitor is one documented sink, not the only one. Hermes's later patch isolates a noninteractive git environment and disables external diff and textconv drivers separately, which is the right shape: one -c flag is not a complete hardening story.

What to do#

If you receive a repository as files, inspect it before any agent opens the folder:

git config --local --show-origin --get-regexp '^(core\.fsmonitor|core\.hooksPath|credential\.|diff\..*\.(command|textconv))'

Any hit deserves a human look. An empty result is not a proof of safety, because other command-bearing keys exist and one of them is still unnamed in the Claude ultrareview finding.

If you run an agent, upgrade first: Goose 1.44.0 or later, Claude Code 2.1.196 or later for the published core.fsmonitor path, Codex CLI 0.131.0 or later, current Cursor, and a Hermes build that contains f6234d0 rather than the 0.21.0 tag. Then treat Qwen Code, Grok Build, and Claude ultrareview as still hostile to received folders until their vendors publish a fix you can name.

If you ship an agent, do not trust repository-local git config on background calls. The override we watched work is the one Manifold recommended and Goose shipped:

git -c core.fsmonitor=false status

A global git config --global core.fsmonitor false is still worth setting on machines you own. It is not a control against a folder that carries its own .git/config. We checked: the local value is the one Git used.

The broader lesson is the same one that keeps showing up in agent security. The dangerous code is often not the model. It is the ordinary subprocess the product runs to find out where it is.