GitSpawn: How a Repository's Git Config Runs Code in Your AI Coding Agent
Orr Yakobi
On 1 September 2026 Manifold Security published GitSpawn, eight findings of arbitrary code execution across seven AI coding agents. All seven failed the same test. A repository can carry a core.fsmonitor setting in its own .git/config that runs attacker code on a developer's machine the moment an AI coding agent opens the folder — with nothing typed, no approval prompt, and no trust prompt of any kind.
Key takeaways
- GitSpawn is a class of eight code-execution findings across seven AI coding agents, newly disclosed by Manifold Security on 1 September 2026. Four were still unpatched that day.
- The mechanism is
core.fsmonitor, a legitimate Git performance setting for large repositories that a repository can define in its own.git/config. Malicious git configs abuse it to execute code during an ordinary index refresh. - Setting
core.fsmonitorto false globally does not protect you. We tested it: repository-local config wins. Only the inline form,git -c core.fsmonitor=false status, works. - Cloning is not the risk. We tested that too — git never carries the setting across a clone. The risk arrives when a directory that already contains its own
.gitfolder is copied onto your machine. - Only index-refreshing calls trigger it.
git statusandgit diffran the code in our test;git log,git rev-parseandgit config --listdid not.
What GitSpawn is
GitSpawn is the name Manifold Security gave to a class of eight code-execution findings, disclosed on 1 September 2026, in which a repository's own git configuration makes an AI coding agent execute code chosen by an attacker.
The agent is not tricked by text it reads. This is not prompt injection. The program runs inside Git itself, as a subprocess an agent spawns at session startup, before any trust prompt and outside whatever sandbox the agent maintains. The agent's permission model never sees it, because from the agent's point of view nothing unusual happened: it asked Git a routine question and Git answered. The attacker code runs as your user account, with everything that account can reach.
The named sink is core.fsmonitor. Manifold Security stated in its disclosure that one of the eight findings used a second git setting, whose details it withheld while that finding remained unpatched.
How core.fsmonitor turns opening a folder into code execution
core.fsmonitor is ordinary plumbing, not an obscure corner of Git. It is a performance setting for large repositories: it names a helper program that Git runs automatically whenever it refreshes the index, so Git does not have to touch the working tree file by file on every operation. On a large monorepo that is a real speed-up, which is why the setting exists at all.
A repository can set it in its own .git/config, and that file travels with the repository directory.
Nearly every AI coding agent runs git to gather project context on startup — the branch, the dirty files, the recent diff. Most of those questions make Git refresh its index first. When it does, Git launches the named helper. The agent never decides to run anything; Git does, on the repository's instructions, as a subprocess.
That is the whole bug. Three reasonable designs met: Git supports a helper hook, repositories carry their own config, and AI coding agents run git automatically. Put them together and opening a folder is enough to execute code.
The affected agents and where each one stood
This is the status Manifold Security published on 1 September 2026, covering Claude Code, OpenAI Codex CLI, Cursor, Goose, Qwen Code, Grok Build and Hermes Agent.
| Agent | Vendor | Version tested | Status at publication | CVE |
|---|---|---|---|---|
Claude Code (core.fsmonitor path) | Anthropic | 2.1.196 | Patched | none assigned |
| Claude Code (ultrareview path) | Anthropic | 2.1.252 | Unpatched at publication | none assigned |
| Goose | aaif-goose | 1.44.0 | Patched | CVE-2026-72718 |
| Hermes Agent | NousResearch | 0.21.0 | Unpatched at publication | CVE-2026-71963 |
| Qwen Code | QwenLM | 0.22.3 | Unpatched at publication | none assigned |
| Grok Build | xai-org | 1.0.13 | Unpatched at publication | none assigned |
| OpenAI Codex | OpenAI | not stated | Patched | none assigned |
| Cursor | Anysphere | not stated | Patched | none assigned |
Four of the eight findings were still unpatched on the day of publication, and Manifold Security re-confirmed that on 1 September 2026.
The reporting dates, all in 2026: Claude Code core.fsmonitor on 26 June, Qwen Code on 7 July, Cursor on 8 July, Goose on 13 July, Grok Build on 14 July, Claude Code ultrareview on 15 July, Hermes Agent and OpenAI Codex on 20 July.
Treat that table as a snapshot of one day. When we checked on 10 September 2026, nine days later, the current released versions were Claude Code 2.1.267, Qwen Code 0.23.3 and OpenAI Codex 0.154.0 — all newer than the versions tested. That does not by itself mean the findings are fixed, and we have not re-tested them. Your installed version is the only thing that answers the question for you.
Which git commands actually trigger it
We ran this ourselves on 10 September 2026, on git 2.39.1 on macOS. The method was a local scratch repository whose core.fsmonitor was set to a harmless program that writes a marker file, with the marker deleted before each run.
| Git invocation | Ran the repository's program |
|---|---|
git status | Yes |
git diff | Yes |
git log --oneline -1 | No |
git rev-parse --show-toplevel | No |
git config --list | No |
git -c core.fsmonitor=false status | No |
git -c core.fsmonitor= status | No |
Only calls that refresh the index execute code. That distinction is practical, not academic: an agent that detects a repository with git rev-parse --show-toplevel is safe, and an agent that opens with git status or git diff is not. If you are evaluating a tool that shells out to git, this is the specific thing to ask about.
It is also why workspace-trust style protections do not help here. A workspace-trust dialog gates what the editor does after it loads a folder. GitSpawn fires inside a git subprocess during context gathering, which happens first. This is the same class of gap we described in walls and rails for agentic coding: the guardrail exists, and the risky step happens on the other side of it.
Why setting core.fsmonitor globally does not protect you
The obvious defence is to run git config --global core.fsmonitor false once and consider every repository handled. It does not work, and we have not seen this written down anywhere else.
We tested it directly on 10 September 2026. With that global setting in place, a plain git status inside the poisoned repository still ran the attacker code. Repository-local configuration takes precedence over global configuration, which is ordinary git behaviour and exactly what makes this defence useless. The repository is the attacker, and the repository's own config file outranks yours.
What does work is the inline override:
git -c core.fsmonitor=false statusA value passed with -c outranks the repository file. That is also the fix Manifold Security recommended to vendors: sanitise the git config on the background context-gathering calls your product makes.
The consequence for an engineering team matters more than the mechanism. A policy that tells engineers to set a global git option produces protection that is confident, documented, auditable, and does nothing. The fix has to live in the tool that calls git — which means it is your vendor's job, and your job is to ask whether they have done it.
How a poisoned repository reaches your machine
We tested this on 10 September 2026 as well. Git never carries the setting across a clone: the cloned copy had no core.fsmonitor at all and did not run the program.
So cloning from a forge is not the risk. The risk arrives when a directory that already contains its own .git folder is copied onto your machine — a zip file, a shared drive, a sync folder, a USB stick, an archive attached to a ticket.
That is a much narrower vector than "any untrusted repository", and it is worse for some teams than others. If you build software for clients, receiving a folder is routine. Code arrives as a handover from a previous vendor, as an export from someone's laptop, as a zip in a thread because the client cannot grant repository access yet. Every one of those paths preserves .git/config, and every one of them ends with somebody opening the folder in an agent to find out what is in it.
A self-check you can run in thirty seconds
Check one repository:
git config --get core.fsmonitorEmpty output means the setting is absent. Any output at all is worth reading before you open the folder in anything.
Sweep a directory of repositories at once:
find . -path '*/.git/config' -exec grep -l 'fsmonitor' {} +That prints the path of every .git/config under the current directory that mentions fsmonitor. Clear one you did not set:
git config --unset core.fsmonitorWe confirmed on 10 September 2026 that after the unset, the same git status no longer ran the program.
What to change if your team runs coding agents on client code
- Upgrade every agent and record the installed version. The table above is one day's snapshot, and the versions moved within nine days.
- Treat a received folder differently from a cloned repository. Where you can, re-clone from the forge instead of opening a copy someone sent you. That single habit removes the vector.
- Open unknown code in a container or a virtual machine first, before any agent touches it.
- Do not rely on a global git setting, and do not rely on workspace-trust. Neither sees the subprocess.
- Ask any vendor whose product runs git in the background whether it sanitises the config on those calls. That is the fix Manifold Security recommended, and it is specific enough to get a real answer.
The wider point is about what AI agents change, and it generalises past this one setting — see AI agent security for the broader pattern. A repository has always been able to carry a hostile .git/config; what is new is that something now reads the repository automatically, on your behalf, before you have looked at a single line of it. The agent did not create the hole. It removed the step where a human would have noticed. If you are inheriting a codebase from a previous vendor, this belongs on the same checklist as everything else in a code audit.
Conclusion
GitSpawn is old git behaviour meeting a new habit. core.fsmonitor has worked exactly this way for years, and repositories have always carried their own config; the change is that AI coding agents run git the instant they open a folder, before anyone reads anything. The check is one line, git config --get core.fsmonitor, and the defence most teams would reach for first — setting it globally — is the one that does not work.
Frequently asked questions
What is GitSpawn?
GitSpawn is the name Manifold Security gave to a class of eight code-execution findings, published on 1 September 2026, across seven AI coding agents. A repository sets core.fsmonitor in its own .git/config, and git runs that program whenever it refreshes the index — which is what an agent triggers when it runs git status at session startup.
Which AI coding agents were affected?
Claude Code, OpenAI Codex, Cursor, Goose, Qwen Code, Grok Build and Hermes Agent. All seven failed the same test, and four of the eight findings were still unpatched on the day of publication.
Does setting core.fsmonitor to false in my global git config protect me?
No. We tested this on 10 September 2026 on git 2.39.1: with git config --global core.fsmonitor false set, a plain git status inside a poisoned repository still ran the program, because repository-local config takes precedence over global config. The inline form, git -c core.fsmonitor=false status, does work.
Does cloning a repository put me at risk?
No. We tested it: git never carries core.fsmonitor across a clone, and the clone did not execute code. The risk arrives when a directory that already contains its own .git folder is copied onto your machine — a zip, a shared drive, a sync folder, a USB stick.
Which git commands trigger it?
Only the ones that refresh the index. In our test git status and git diff ran the program, while git log, git rev-parse --show-toplevel and git config --list did not.
Is GitSpawn a form of prompt injection?
No. Prompt injection works on the model, through text the agent reads. GitSpawn never reaches the model at all — git executes the attacker code as an ordinary subprocess while gathering context, so the agent's approval prompt and permission model never see it.
How do I check a repository right now?
Run git config --get core.fsmonitor inside it. Any output at all is worth investigating. Clear it with git config --unset core.fsmonitor.
Other Articles
We build the engineering. You build the business.
If you are trying to figure out whether SWARECO is the right fit for what you are building, the best way to find out is to talk. Tell us what you have. We will be direct about what we can do and how we would approach it.