Seven Coding Agents Run a Repo's Code Before You Type Anything

TL;DR

Manifold Security published GitSpawn on September 1: eight findings across seven command-line AI coding agents where a repository's own .git/config gets to name a program that runs on your machine the moment the agent gathers context. There is no prompt, no model call, no tool approval, and nothing on screen. Four of the eight were still unpatched when the research went out, including a second path in Claude Code whose mechanism Manifold is still withholding.

The bug is in your agent. Git is behaving exactly as documented.

Git has a performance setting called core.fsmonitor. It names a helper program that git runs automatically whenever it refreshes its index, so a filesystem watcher can tell git what changed instead of git stat-ing a million files. On a monorepo it is a real speedup.

Git reads that setting straight out of the repository's own .git/config. Which means the repository gets to pick a program your git will execute. That is a doorbell that lets the visitor choose which song plays inside your house, except the song is a shell command and the house is your SSH keys.

Now add the thing every CLI coding agent does on startup: work out the branch, work out what changed. That is git status or git diff HEAD. Both refresh the index. Index refresh reads core.fsmonitor. The helper runs.

The process that executes is git's child, not the agent's tool call. It sits outside whatever sandbox the agent maintains, and it never reaches the permission system, because from the agent's point of view nothing happened. It asked git a question and git answered.

The advisory for goose, CVE-2026-72718, puts it in the flattest language available: the command runs "before goose contacts a model and without a submitted prompt, model call, tool approval, or trust prompt." The vulnerable calls are the git diff --name-only HEAD and git diff HEAD that goose uses to collect a diff for review.

What an attacker gets

Manifold's summary of the payoff is worth quoting whole, because it is the entire threat model in one sentence:

Arbitrary code execution as the developer, outside the sandbox, with no approval prompt and nothing on screen. Their SSH keys, the cloud credentials in their environment, the tokens in their shell config, every repository on disk, and a foothold on the machine.

OpenAI's own advisory for Codex, CVE-2026-19592, describes the identical shape: Codex "automatically collected Git repository metadata without disabling the repository-local core.fsmonitor setting," and the helper "runs outside Codex's command sandbox and without a user-approval prompt." NVD lists it at CVSS 7.3, high. The fix landed in codex#22652, and the affected range is Codex CLI 0.102.0 through 0.130.0, with 0.131.0 clean.

Eight findings, four of them still open

The reporting window ran from July 1 to July 26, so the four open ones had five to eight weeks. Cursor and Codex are fixed. goose shipped 1.44.0. Claude Code closed the core.fsmonitor path in 2.1.196 but was still executing repository-supplied commands through a second, different git config key in 2.1.252, which Manifold is not naming until it is fixed.

Still vulnerable on retest: Hermes Agent 0.21.0, Qwen Code 0.22.3, and Grok Build 1.0.13. Grok Build's first report, on July 1, was closed as informative. It got re-reported on July 14.

Treat this table as a snapshot of September 1, not of today. Check your own version before you believe a green box on a blog.

Three CVEs for eight findings

Eight findings have produced three public CVE records that we could confirm: CVE-2026-72718 for goose (CVSS 4.0 vector, base 7.0), CVE-2026-71963 for Hermes Agent, and CVE-2026-19592 from OpenAI for Codex. The rest are patch notes. If you track agent risk by CVE feed, you are currently tracking about a third of this.

Why a normal git clone saves you

Here is the constraint that keeps this from being catastrophic. git clone does not transmit the source repository's local .git/config. Clone a hostile repo from anywhere and the malicious core.fsmonitor line stays behind on the server. NVD spells this out in the Codex record: "exploitation requires a repository delivered or copied with that configuration intact."

So the delivery vector is anything that moves a directory as files rather than as a git operation:

• a zip or tarball of a working tree, with .git/ inside
• a shared drive or NFS mount
• a sync folder: Dropbox, Google Drive, Syncthing, iCloud
• a USB stick
• a restored backup, or a container image that baked in a checkout

That is a much smaller blast radius than "every repo on GitHub" and a much larger one than "nobody." Every "here is a repro, unzip the attached project" in a bug report is now a delivery mechanism, and pointing an agent at a customer's zipped project is an ordinary Tuesday for most support engineers.

What to actually do

• Update the agents you run. Claude Code 2.1.196 or later, goose 1.44.0 or later, Codex CLI 0.131.0 or later. If you run Qwen Code, Grok Build, or Hermes Agent, there is nothing to update to yet.
• Look before you point an agent at an unpacked repo. cat .git/config takes two seconds and a hostile fsmonitor line is not subtle. git config --local --list works too.
• Prefer re-cloning to unzipping. If the archive has a real upstream, clone it and copy the working files in. The attack does not survive that.
• Stop treating the agent's sandbox as the boundary. The sandbox governs tool calls. The context-gathering subprocess that runs before the first tool call is not one.

The part that should change how you think

Agent security has been framed almost entirely as prompt injection: hostile text reaches the model, the model does something regrettable. GitSpawn has no prompt in it at all. The model is not involved. You could run these agents with the network unplugged and still get owned.

The general shape is that every subprocess an agent spawns to "gather context" is an untrusted-input parser running with your full privileges. Git is simply the first one anyone bothered to audit, and it took about five minutes once someone looked. There is no reason to think it is the only one. Package manifests, build files, editor configs, and language servers all have their own "the project can name a program" features, and every agent touches several of them before it says hello.

Key Takeaways

• GitSpawn is eight findings across seven CLI coding agents: a repo's own .git/config can set core.fsmonitor to a command, and the agent's routine git status or git diff executes it.
• The code runs with your privileges, outside the agent sandbox, with no prompt, no model call, and no approval dialog.
• Patched at publication: Claude Code 2.1.196 (one of two paths), Codex CLI 0.131.0, Cursor, goose 1.44.0. Still open: Hermes Agent 0.21.0, Qwen Code 0.22.3, Grok Build 1.0.13, and a second Claude Code path in 2.1.252.
• An ordinary git clone is safe, because clone never carries the source repo's local config. Zips, shared drives, sync folders, USB sticks, and restored backups are not.
• Only three public CVE records exist for eight findings, so a CVE feed is not going to tell you when your agent is exposed.
• This is not prompt injection. Any subprocess an agent runs for context is an attack surface, and git was only the first one audited.

Sources: Manifold Security, GitSpawn disclosure, The Hacker News, CVE-2026-19592 (OpenAI Codex), CVE-2026-72718 (goose), openai/codex PR 22652, git-config documentation