Coding Agents Get Hijacked Before You Type a Prompt: GitSpawn Opens With One Git Config Line

Manifold Security published a report on September 2, 2026 documenting eight vulnerabilities across seven CLI coding agents, collectively named GitSpawn. An attacker who plants a single core.fsmonitor line in a repository's .git/config gets that command executed with the developer's privileges the moment the agent runs git status to gather project context. That happens before the user types a single character, before the workspace-trust prompt appears, and outside any sandbox. Claude Code, Cursor, OpenAI Codex, and Goose shipped patches, while Claude Code's ultrareview path, Hermes Agent, Qwen Code, and Grok Build were confirmed unpatched at publication. ASAP breaks down how the flaw works and what engineering teams should check today.

Agents run git commands before the user approves anything

CLI coding agents automatically run commands such as git status --porcelain=2 --branch and git diff --name-only HEAD the instant they start, to learn the state of a project. Knowing the branch, the modified files, and whether uncommitted changes exist is what lets an agent say something useful in its very first reply. These calls happen before the user asks for anything, and in most tools they happen before the dialog asking whether to trust this working directory.

The trouble is in how git services those commands. Git refreshes its index before reporting status, and during that refresh it consults the repository's own .git/config. Not the global config in the user's home directory, but the config file sitting inside the folder that was just opened. Whoever created the repository decides what that file contains.

The Manifold Security report frames the gap directly: those context-gathering calls ran without stripping the repository's own git configuration, and several git settings are command execution sinks. The trust boundary breaks one layer below the agent's tool calls and the model's judgment.

Why `core.fsmonitor` becomes a code execution path

core.fsmonitor is a git performance setting for large repositories that names a helper program, which git then executes during an index refresh instead of checking every file on disk. Used as designed, it points at a filesystem-watching daemon. Git reads the value from the repository's own .git/config and does not validate what it points to.

A hostile repository needs only two lines:

[core]
    fsmonitor = <command>

Opening that repository with an agent executes the command through a single standard git call. The report sums up the result as arbitrary code execution as the developer, outside the sandbox, with no approval prompt and nothing on screen, exposing SSH keys, cloud credentials, shell tokens, and every repository on the machine.

Worth stating plainly: this is not a model flaw. The model has judged nothing and called no tool at this point. The attack surface is the thin shell the product wraps around the model, a handful of context-gathering commands. Treating agent security purely as an alignment problem leaves this entire layer out of view.

The precondition is a zipped repository, not a clone

The attack requires the repository to arrive as files with its .git directory intact, and it does not work through git clone, because cloning does not copy the remote repository's config. The researchers demonstrated it with .zip files, explicitly mirroring how colleagues and consultants actually pass projects around. Shared drives, USB sticks, and sync folders are on that list.

That precondition looks like it narrows the blast radius, and for many engineering cultures it does not. Contract and outsourced deliverables handed over as archives, code carried on removable media into air-gapped networks, project copies emailed between teams, and legacy repositories distributed as files because security policy forbids external git hosting all qualify. These paths carry weaker review than a public repository on a hosting service.

The social shape of the path matters too. Receiving a repository as an archive usually happens inside a relationship with some existing trust, so the wariness triggered by an unfamiliar link never activates. If a partner's account has already been compromised, that trust becomes the attack material. Unzipping a handoff and asking an agent to review it is routine work.

Four of the seven agents were still unpatched at publication

Vendor response is the sharpest split in the Manifold Security report, with four of the seven affected agents still open on September 2, 2026 while four shipped fixes. The reported dates and confirmed versions follow.

Product	Vulnerable version	Reported	Status at publication	CVE
Claude Code (`core.fsmonitor`)	2.1.193	June 26, 2026	Patched (2.1.196)	None
Cursor	Not disclosed	July 8, 2026	Patched	None
OpenAI Codex	Not disclosed	July 20, 2026	Patched	None
Goose	1.41.0	July 13, 2026	Patched (1.44.0)	CVE-2026-72718 (severity 7.0)
Claude Code (ultrareview path)	2.1.210	July 15, 2026	Unpatched (confirmed on 2.1.252)	None
Qwen Code	0.19.6	July 7, 2026	Unpatched (confirmed on 0.22.3)	None
Grok Build	0.2.93	July 14, 2026	Unpatched (confirmed on 1.0.13)	None
Hermes Agent	0.18.2	July 20, 2026	Unpatched (confirmed on 0.21.0)	CVE-2026-71963

The striking column is not patch status but elapsed time. Claude Code's first report moved from June 26 to a fix in 2.1.196 almost immediately, while the same product's ultrareview path was reported on July 15 and remained open through the September 2 publication. Same company, same product, same class of defect, different response speed. The report does not name the git configuration key involved in that second, still-open path.

Hermes stands apart for a different reason. The researchers made six contact attempts across five channels and never received even a triage response. A CVE exists, the product keeps shipping, and no one is receiving reports. Combined GitHub stars across the affected projects run to roughly 500,000, and Claude Code alone recorded 77 million monthly npm downloads as of July 2026.

The "duplicate report" replies say more than the unpatched list

The most telling passage in the report is the shape of vendor replies rather than the list of open issues. Most vendors responded that the disclosure duplicated an earlier independent report, which the researchers read as a sign that this vulnerability was found from several directions at once.

Split that signal in two. Read charitably, it means vendors already knew. Read critically, it means the defect is easy enough to find that separate researchers converged on it independently. The second reading matters more. When unrelated teams land on the same point, that point is not an isolated mistake but the product of a design pattern the whole category shares, and running shell commands inside a user's code directory to gather context is a pattern every current CLI agent uses.

That makes core.fsmonitor the first entry on a list rather than the whole list. Git has several settings that name external programs, and git is not the only tool agents invoke for context. Package manager config files, build tool script hooks, and editor workspace settings all have the same character. Closing this instance leaves the next one of the same shape standing.

The layer that prompt-injection debates left uncovered

Agent security in 2026 has largely revolved around what a model reads and what fools it: fake bug reports planted in issue trackers, instructions hidden in pull request titles, commands embedded in web pages. The shared premise is that a model ingests poisoned input and makes a bad tool call, and the defenses follow from that premise. Tool-call approval, sandboxing, and least privilege all target model behavior.

GitSpawn sits outside that premise. No poisoned text was read and no wrong tool was called. What executed was a shell command the agent binary ran on its own. That is why approval prompts do not help: an approval prompt fires when a model wants to act, and here everything finished before the model was involved.

Sandboxes miss it for the same reason. The isolation these products advertise generally confines commands the model requests, while the context-gathering commands the product itself runs at startup execute outside it. That is precisely why the report specifies "outside the sandbox." The question is not where the defensive line was drawn but what happens before the line.

What to check today, and what remains open

Immediate mitigation of GitSpawn splits into two layers, one for teams using CLI coding agents and one for the vendors that build them. On the consuming side, follow the report's advice and inspect .git/config before opening any repository that arrived by archive, USB stick, or shared drive. Any setting that names a program can run it. Deleting the .git directory and reinitializing is equally effective.

On the building side, prevent repository config from reaching background calls at all. The report's suggested form is disabling the setting at invocation, as in git -c core.fsmonitor=false status. Teams that wrap and redistribute agents internally can apply the same treatment in the wrapper.

At the organizational level, inventory comes first. Determine whether Qwen Code, Grok Build, or Hermes Agent are installed anywhere internally, and whether Claude Code installations are on 2.1.196 or later. Because the ultrareview path stays open, version bumps alone do not close the exposure, so the safer move is changing the practice of opening untrusted repositories with an agent at all.

Open questions remain. The report documents no confirmed exploitation in the wild, and there is no timeline for the four products still unpatched. The configuration key behind Claude Code's second path is undisclosed, which limits what users can inspect themselves. Above all, this disclosure is not really about one git setting. It puts a harder question on the table for the first time: how much is an agent allowed to execute before the user approves anything? No product has answered it yet.

Source: Manifold Security, "GitSpawn: A Single Flaw Lets Untrusted Repos Run Code in Claude Code, Codex, Cursor, and Grok" (September 2, 2026, by Francisco Rosales). Compiled by ASAP.