GitSpawn: The .git/config Line That Runs Code When Your AI Agent Opens a Folder

You unzip a folder a client sent, point Claude Code or Cursor at it, and before you have typed a word, a command from inside that folder has run as you, outside the agent's sandbox, with no prompt. That is GitSpawn, a class of bugs Manifold Security published on 1 September 2026 after reporting eight findings across seven coding agents over the summer. Four of the eight were still open on the day the research went public.

If you only read one paragraph, update your agent, run git config --global core.fsmonitor false, and read the .git/config of any folder that arrives as files before you open it with an agent. The rest of this piece explains why those three things are the whole fix, which versions are safe, and what to do if you have already opened something you should not have.

What GitSpawn is, in one breath

Git has a setting called core.fsmonitor. Its value is a command git runs to find out which files changed, and git reads it from the repository's own .git/config. Any operation that refreshes the index runs it, including git status and git diff. Nothing about that is a bug; it is documented behaviour and it has been there for years.

Coding agents run git the moment they start. They want the branch name, the dirty files and the recent log so the model has context, and they do it in the background, on some agents before you accept the workspace trust prompt, on one before you have even signed in. Manifold's write-up puts it plainly:

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.

Put the two together and a repository's author can write one line into .git/config and have it executed on the machine of anyone who opens that folder with an affected agent. The command runs as the developer, not as the agent, so the sandbox and the approval flow never see it.

Why a clone is safe and a zip is not

This is the detail most of the news coverage buried, and it decides whether you are exposed at all. A git clone, fetch or pull does not transfer the source repository's local .git/config. Git writes a fresh one on your side. So a repository you cloned from GitHub cannot carry the payload, however hostile its owner.

The folder has to arrive with its .git directory already inside it. Manifold's own wording is that "the vector is anything that moves a directory instead of cloning it": a zip attached to an email, a shared drive, a Dropbox or iCloud sync folder, a USB stick, a project handed over from one freelancer to the next. If your working life involves receiving projects as files rather than as repository URLs, this is aimed at you.

Which agents were affected, and where they stand

The table is Manifold's list, with the versions from their disclosure and from OpenAI's advisory as reported on 2 September, and the current release of each project as published on 8 September 2026. Patch status moves; the date on each cell is the claim.

Where each project is now, checked on 8 September 2026 against its package registry or GitHub releases. Claude Code is at 2.1.265 and its public changelog does not mention the ultrareview path, so treat that path as open. Codex CLI is at 0.153.4, well past the fix. Goose is at 1.50.0. Qwen Code's CLI is at 0.23.1, which is newer than the version Manifold tested, but neither the vendor nor Manifold has said it is fixed, so it is unverified rather than safe. Hermes Agent has moved to date-based version numbers (the current release is v2026.9.7), which makes the 0.21.0 reference impossible to compare; treat it as unpatched until Nous Research says otherwise. Grok Build has published nothing on it that I could find.

Codex Desktop has its own numbers. OpenAI lists the macOS build fixed in 26.519.22136 and the Windows build in 26.519.21041, per the Hacker News report on 2 September.

Two of the disclosure notes are worth knowing if you use those tools. Manifold says the Hermes Agent report went untriaged despite six contact attempts, and that xAI closed the Grok Build report as "informative" before Manifold's own submission. That is not a statement about the tools' quality. It is a statement about how quickly a report reaches someone who can act on it, which is the thing you are relying on when you keep a tool that has an open finding.

When the payload fires

The Hacker News summary lists when each agent runs the git call. In Claude Code and Hermes Agent the payload fires before the workspace trust prompt is accepted. In Qwen Code it fires before you authenticate. In Grok Build it fires on the first keystroke. On every one of them, that is before any point at which the product asks you whether it should trust the folder.

That order is the actual bug. The trust prompt is the right control; it was just checked after the git call instead of before it.

This is not new. IDEs fixed it in 2021

Paddo's write-up, the best independent piece on this, makes the historical point that turns a scary headline into something you can reason about. VS Code hit exactly this with core.fsmonitor and patched it in 1.63.1 under CVE-2021-43891 by introducing workspace trust: no git operations until the workspace is trusted. JetBrains followed with CVE-2022-24345. Justin Steven's 2022 advisory catalogued the same abuse against shell prompts and editors, and git itself added safe.bareRepository in 2.38.

The agents regressed to the pre-2021 state because they are new products built on the same plumbing, and the people building them were solving a different problem, giving the model good context fast. Paddo's recommendation to vendors is the one to hold them to: gate every git operation behind trust verification, rather than stripping one dangerous key at each call site and hoping the list is complete. Manifold's suggested fix for the background calls is the narrower version, git -c core.fsmonitor=false status, which closes the reported path and leaves core.hooksPath and the filter drivers for another day.

Am I exposed?

Work through this in order.

1. Do folders reach you as files? Zips from clients, a shared drive with other people's projects, a sync folder, a laptop handover. If no, and everything you open is something you cloned yourself, the reported vector does not apply to you. Keep reading anyway; the fix costs nothing.
2. Which agent, which version? Run claude --version, codex --version, goose --version or check the About panel in Cursor, and compare with the table. Claude Code 2.1.196 or later, Codex CLI 0.131.0 or later and Goose 1.44.0 or later have the main path closed.
3. Do you use Claude Code's ultrareview on folders you did not build? That path was reported open at 2.1.252 and nothing published since says otherwise. Do not run it on an unvetted folder.
4. Do you use Hermes Agent, Qwen Code or Grok Build? Assume the finding is open and rely on the git-side mitigation below, not on the agent.

What to do today

Three commands and one habit.

Turn the setting off globally, so git ignores it from any repository config on your machine:

git config --global core.fsmonitor false

The cost is real but small. On very large repositories, git status gets slower without the file system monitor. On a typical solo project you will not notice. If you need it for one big repository, set it there explicitly and keep the global default off.

Before opening a folder that arrived as files, read what its config says:

cd the-folder
git config --local --list

You are looking for core.fsmonitor, core.hooksPath, attr.tree, and any filter.*.clean or filter.*.process entry. None of those belong in a project somebody handed you. If one is there, do not open the folder with anything until you understand it.

If you want the check without the trust decision, the safest move is to not open the received folder at all. Initialise a fresh repository and copy the working files in, leaving the received .git directory behind.

mkdir clean-copy && rsync -a --exclude .git the-folder/ clean-copy/
cd clean-copy && git init

The habit is the one you already have for untrusted code, extended to untrusted repository metadata: the .git directory is part of what you received, and it can run things.

I already opened one. Now what?

First, find out whether there was anything to run. Read the .git/config of the folder you opened, as above. If none of the keys is set, nothing happened through this path.

If one of them is set, assume the named command ran with your privileges the moment the agent started. Then, in this order: rotate whatever credentials that machine holds (cloud keys, API tokens, the SSH key you deploy with), check your shell startup files, crontab and ~/.ssh/authorized_keys for entries you did not write, and read the command itself to learn what it did. As of 2 September, neither CISA's Known Exploited Vulnerabilities catalogue nor any independent source reported this being used in the wild, which is comfort about the odds and no comfort at all about your particular folder.

Where this sits in agent security

GitSpawn is not prompt injection and it is not a model jailbreak. The model never sees the payload; it is the harness that runs git, and git that runs the command. That distinction matters for what you do about it. Prompt injection is mitigated by permissions and review; this is mitigated by patch levels and a git setting.

It also says something about the sandbox story. OpenAI's own advisory for CVE-2026-19592 states that the helper "runs outside Codex's command sandbox and without a user-approval prompt". The sandbox is real. It just does not wrap the process that starts before it.

If you review code you did not write with an agent, read how to scan AI-agent code you did not write next; what an agent actually does at startup is covered in what is an AI agent. The agents themselves are on the AI coding agents hub, with Claude Code and Cursor each carrying their own page.

FAQ

What is GitSpawn?

The name Manifold Security gave to a class of bugs in AI coding agents. The agent runs git in the background to learn where it is, git reads core.fsmonitor from the repository's own .git/config, and that setting is a command, so whoever prepared the repository gets to run code on your machine.

Does git clone trigger it?

No. A clone, fetch or pull does not copy the other repository's local .git/config. The folder has to arrive with its .git directory already inside it: a zip, a shared drive, a sync folder, a USB stick.

Which agents were affected?

Claude Code, OpenAI Codex, Cursor, Goose, Hermes Agent, Qwen Code and Grok Build, eight findings across seven agents. Claude Code's main path, Codex, Cursor and Goose were fixed by disclosure; Qwen Code, Grok Build, Hermes Agent and a second Claude Code path were open on 1 September 2026.

Is it remote code execution?

Not over the network. It is local code execution with your own privileges, triggered when you open a folder somebody else prepared, outside the agent's sandbox and without an approval prompt.

What is the quickest fix?

Update the agent, run git config --global core.fsmonitor false, and run git config --local --list inside any folder you received as files before you open it with an agent.

Was this a new bug in git?

No. VS Code fixed the same abuse with workspace trust in 1.63.1 (CVE-2021-43891) and JetBrains followed with CVE-2022-24345. The agents ran git before their own trust prompt, which undid that protection.

Is Claude Code fully fixed?

The core.fsmonitor path was fixed in 2.1.196. Manifold reported a second path through ultrareview open at 2.1.252 on 1 September 2026, and the public changelog up to 2.1.265 does not mention it. Treat that path as open.

I already opened a suspicious folder. What now?

Read its .git/config for core.fsmonitor, core.hooksPath, attr.tree and any clean or process filter. If one is set, assume it ran as you: rotate the credentials on that machine, check shell startup files, cron and SSH keys, and read what the command did.

The short version

• A folder that arrives with its .git directory can make an affected agent run a command as you, before any prompt. A clone cannot.
• Claude Code 2.1.196, Codex CLI 0.131.0, Goose 1.44.0 and current Cursor have the main path closed. Claude Code's ultrareview path, Hermes Agent, Qwen Code and Grok Build were open at disclosure and nothing published since says otherwise.
• git config --global core.fsmonitor false today, and git config --local --list before opening anything you received as files.

Sources: Manifold Security's disclosure (1 September 2026); Paddo's analysis; The Hacker News (2 September 2026); the Hacker News thread; release pages for Goose 1.44.0 and Codex CLI 0.131.0.