What Actually Happened
In early September 2026, researchers disclosed a class of vulnerabilities they named GitSpawn: eight distinct flaws across seven AI coding agents, every one of them reachable by publishing a repository and waiting for someone to open it.
The affected products are not fringe tools. They are Claude Code, OpenAI Codex, Cursor, Grok Build, Goose, Hermes Agent and Qwen Code — the daily driver for a large share of professional developers in 2026.
There is no exploit chain here, no memory corruption, no malicious dependency to install. The entire attack is one line of configuration sitting inside a repository, and a background command the agent runs before it says a single word to you.
core.fsmonitor Is Not a Setting. It Is a Command.
Git has a performance feature called core.fsmonitor. It exists because walking an entire working tree to find out what changed is slow on large repositories, so Git lets you delegate that question to an external file-system monitor.
The important detail is what the configuration value contains. It is not a boolean and not a path to data. It is a command, and Git executes it on any operation that refreshes the index.
That includes the two commands every developer runs a hundred times a day:
git statusgit diff
And critically, Git reads that value from the repository's own .git/config — a file that travels with a repository you did not write.
Now Add an AI Agent
Consider what every AI coding agent does the moment you open a project. Before it answers anything, it orients itself: current branch, staged files, recent diff, working-tree state. It gathers that context by running git commands in the background, silently, by design. The user sees a spinner, not a shell.
Put the two facts together and the attack writes itself:
- An attacker publishes a repository carrying one hostile line in
.git/config. - A developer clones it — to review a pull request, evaluate a library, reproduce a bug report.
- They open it in their agent.
- The agent runs
git statusto build context. - Git reads the repository's configuration, finds the fsmonitor command, and executes it.
The repository told git to run something. The agent asked git to run. Nobody in that chain did anything unusual.
Who Is Affected, and Where the Patches Stand
The disclosure describes eight flaws across seven agents, and the patch picture as of September 1, 2026 was mixed.
- Claude Code — the
core.fsmonitorpath was confirmed in version 2.1.193 and fixed in 2.1.196. A second path was still reported as executing repository-supplied commands. - OpenAI Codex — affected, since patched.
- Cursor — affected, since patched.
- Hermes Agent, Qwen Code, Grok Build — still executing repository-supplied commands as of September 1.
- Goose — named in the affected set.
The timing of execution is the part that turns a serious bug into an architectural one. On Claude Code and Hermes Agent, the payload fires before the workspace-trust prompt is accepted. On Qwen Code, before the user has authenticated at all. On Grok Build, on the first keystroke.
A Consent Dialog That Appears After Execution Is a Receipt, Not a Control
Every vendor in this space has built an approval layer: workspace-trust dialogs, per-command permission prompts, tool-call logging, allow and deny lists. Those controls are real and they work as designed — for actions the model decides to take. GitSpawn runs underneath that layer entirely. Execution happens during context collection, in plumbing the approval system was never pointed at, and in several products it happens before the prompt is shown or the user is even authenticated. The security model assumed the dangerous actions were the ones the agent proposes. The dangerous action here was one the agent performs to figure out where it is.
This Is Not Prompt Injection, and the Distinction Decides the Fix
It is worth being precise, because the entire mitigation strategy depends on which kind of bug this is.
Prompt injection manipulates the model. Hostile text enters the context window and the model is persuaded to take an action it should not. Defences are probabilistic by nature: instruction hierarchies, classifiers, narrowed tool scopes, human confirmation on sensitive calls.
GitSpawn asks nothing of the model. The AI is not tricked, not consulted, not involved in the decision at all. The agent is a process that runs git as a subprocess, and git had been configured — by the repository, not by the user — to run something else. Strip the AI out of the description and you are left with a textbook untrusted-input-to-command-execution bug that happens to live inside AI tooling.
The Real Exposure Is the Patch Pipeline
A vulnerability with a same-week fix is a minor incident when you can push the fix. It is an open door when you cannot see the installs.
AI coding agents occupy an unusual position in most organisations. They live on developer laptops. They update on their own release cadence, often silently. They are frequently installed by the engineer rather than by IT, sometimes through npm or a package manager rather than a managed software catalogue. They rarely appear in an asset inventory, and almost never in a vulnerability management report.
Ask a security team which agent version is running on which engineer's machine. Most cannot answer — not because the process is weak, but because these tools were never enrolled in it.
The Developer Laptop Is the Highest-Value Endpoint You Do Not Treat Like One
Think about what sits on the machine where this executes: cloud credentials, SSH keys, signing keys, registry tokens, kubeconfig files, browser sessions to the CI system and the cloud console, and write access to the repositories that build production. A single command executed there is not an endpoint compromise, it is a foothold in the software supply chain. We spent a decade hardening servers and CI runners while the machine that pushes to both kept a developer's full standing privileges and, increasingly, an agent that executes things on their behalf. GitSpawn is a small bug pointed at a very large target.
What To Do If You Run Engineering
1. Override fsmonitor Where It Actually Counts
The fix you will see recommended most often, git config --global core.fsmonitor false, does not protect you. Git applies configuration in order, system, then global, then the repository's own .git/config, and the last value wins. A poisoned repository sets fsmonitor locally, so it overrides your global setting. We tested it on Git 2.54: with the global value set to false, the repository's command still ran.
What does take precedence over the repository is configuration passed on the command line or through the environment. Setting these variables in the environment the agent runs in neutralizes the setting for every git call it makes, and the command did not run in our test:
GIT_CONFIG_COUNT=1 GIT_CONFIG_KEY_0=core.fsmonitor GIT_CONFIG_VALUE_0=false
Push it through your MDM or shell baseline rather than asking people individually, and pair it with a habit: before opening a repository you did not clone yourself, run git config --local --list and look for fsmonitor, hooksPath and sshCommand. Better still, re-clone from a known remote, since a fresh clone never copies the sender's .git/config.
2. Inventory the Agents and Their Versions
Enumerate which AI coding tools are installed across engineering, at which versions, and bring them into normal patch management with an owner and a minimum-version policy. Several products in the affected set were still shipping the behaviour at the start of the month. You cannot ship a fix to software you have not inventoried.
3. Treat Cloning as Execution
Opening an untrusted repository in an agent is now functionally equivalent to running it. That reframing should change routine habits: triage before you clone, be deliberate about repositories from issue reports, forks, job applicants and vendor demos, and keep unknown code in a disposable environment.
4. Isolate the Agent Workspace
Containers, devcontainers, dedicated VMs or a separate low-privilege user turn a developer-machine compromise into a discarded sandbox. This is the control that survives the next bug in this class, which will not be about fsmonitor and will not be announced in advance.
5. Monitor the Developer Endpoint Like an Endpoint
EDR coverage, process telemetry and egress logging belong on machines running agents, not only on servers and CI runners. If a git subprocess spawns an unexpected child process on an engineer's laptop, someone should see it. Today, on most estates, nobody would.
6. Rotate What the Laptop Holds
If an engineer opened an untrusted repository on an unpatched agent, treat the cloud tokens, SSH keys and registry credentials on that machine as potentially exposed. Short-lived credentials and hardware-backed keys make that conversation dramatically shorter.
The pattern worth carrying forward is not the fsmonitor trick. An agent is not just a model. It is a process with a shell, a filesystem, a network stack, credentials, and a long tail of helper commands nobody audits because they look like plumbing: git, package managers, language servers, formatters, build tools, test runners. Every one of those reads configuration from the project directory, and the project directory is attacker-controlled the moment you clone something you did not write. The model is the part everyone is watching. The subprocess is the part that gets you.
Frequently Asked Questions
My Take
The industry has spent two years hardening what AI agents say. Refusals, guardrails, output filtering, red-teaming the weights, evaluations for dangerous capability. That work is necessary and it is not where this bug lives.
GitSpawn is a 2005-vintage vulnerability wearing a 2026 badge. Untrusted input reaches a command interpreter. We have known how to fix that for a very long time. What is new is the delivery: the untrusted input arrives in a config file nobody reads, the command interpreter is a tool everybody trusts, and the trigger is an agent doing something so mundane that no product designer thought to put a gate in front of it.
That is the shape I expect to see repeatedly. The interesting attack surface in agentic systems is not the model, it is the harness — the subprocesses, the config parsing, the file access, the network calls the agent makes to orient itself before it does anything a human approves. Every one of those is code executing on attacker-influenced input, and almost none of it is covered by the permission model the vendor shipped.
The uncomfortable part is the deployment reality. These tools sit on the machines with the broadest access in the company, install themselves outside IT, update on their own schedule, and are absent from most asset inventories. When the fix arrived in a point release, a large share of the installed base had no mechanism to receive it. That gap is not the vendors' to close.
Fix the config setting this week. Then ask the harder question: how many other commands does your agent run before you approve anything, and what do they read from the folder you just cloned?
If a hostile repository were opened on one of your developer machines today, what in your telemetry would tell you?
Related Articles:
