GitSpawn: Cloning a Repo Is Safe. Being Handed One Is Not.

GitSpawn is the name Manifold Security gave to a flaw it disclosed on 1 September 2026, in which a repository’s own git configuration can run a program of its choosing inside an AI coding agent, at session startup, before the model takes a turn and before any sandbox or approval prompt applies.

Seven agents were tested and all seven were affected: Claude Code, OpenAI Codex, Cursor, goose, Hermes Agent, Qwen Code and Grok Build.

The detail that decides whether this matters to you is not in most of the headlines. Manifold puts it plainly: "Cloning a hostile URL does nothing, and neither does fetch or pull." The repository has to arrive as files, with its git directory already inside. A zip over email. A shared drive folder. A sync folder. A USB stick. A handover from the previous developer.

If you run an agency, you already know why that is the wrong way round. Cloning from a canonical remote is the safe act. Being handed a folder is the risky one, and being handed a folder is how legacy client sites arrive.

This piece covers what the flaw is in defensive terms, the precondition in detail, where each agent stands today, the Claude Code version numbers and a distribution channel almost nobody is checking, one Claude Code path that is still unresolved nine days on, what to actually do, and why the other Anthropic security story this week is not this one.

The short version: check that you are on Claude Code 2.1.265 or later, stop pointing agents at directories that arrived as files without looking at the git config first, and know that a global git setting does not fix this because repo-local configuration overrides it.

What GitSpawn is, in defensive terms

An AI coding agent gathers context when it opens a directory. It runs git in the background to read status, diffs and the index, before you have typed anything.

Git supports configuration keys whose value is a program to run. That is a legitimate feature with legitimate uses. Those keys can be set in a repository’s own local configuration, which travels with the directory when the directory is copied.

So an agent that shells out to git without sanitizing repo-local configuration will execute whatever those keys name. Manifold’s one-line summary of the defensive rule is the one to remember: "Any setting that names a program can run it."

The timing is what makes it serious rather than merely bad. Execution happens during context gathering, which is before the model’s first turn, before any sandbox is applied, and before the agent asks you to approve anything. The entire permission model that agent vendors have spent two years building sits downstream of the thing that already ran.

The primary key named across seven of the eight findings is core.fsmonitor. The Hacker News reporting adds core.hooksPath and attr.tree as vectors of the same class. The eighth finding uses a different key that Manifold deliberately withheld, which matters later.

The precondition, and why it inverts your instincts

Git’s wire protocol does not transmit the source repository’s local configuration. That is why cloning is safe and copying is not, and it is worth stating to a client in exactly those terms.

Safe: git clone, git fetch, git pull from any remote, hostile or otherwise.

Not safe: a directory that arrived intact. A zip attachment. A Dropbox or Drive folder shared by a client. A handover drive from an outgoing developer. Anything where the .git directory came along for the ride.

For an agency this is not a hypothetical delivery path. It is the normal one. The last three legacy sites you inherited almost certainly arrived as a folder, not as a repository URL, because the client never had a repository URL to give you.

One caution, because the two get merged in coverage. CVE-2026-55607, a Claude Code worktree path confusion issue affecting versions 2.1.38 through 2.1.162 and fixed in 2.1.163 back in June, also involves this family of git behavior but does require cloning a malicious repository. That is a different bug with a different precondition. Do not treat them as one story.

Where each agent stands

Manifold’s original count of four unpatched findings is now stale, because Hermes shipped a fix afterward. Codex and Cursor were fixed following reports from other researchers rather than from Manifold.

Two things about that table are worth saying out loud. Cursor has not published an affected or fixed version anywhere we could find, so "fixed" there rests on the vendor’s word with no version to check against. And Qwen Code and Grok Build show no evidence of a fix in either direction, which is not the same as being confirmed vulnerable today but is not reassuring either.

The CVE scores cluster from 7.0 to 8.8, all High, none Critical. Every vector string requires user interaction, which is the correct encoding of "somebody has to hand you the folder." There is no evidence of exploitation in the wild, nobody has claimed any, and none of these appear in CISA’s Known Exploited Vulnerabilities catalog.

Claude Code versions, and the channel nobody is checking

If you use Claude Code, this is the section that matters.

The core.fsmonitor fix shipped in 2.1.196, which was a June release, not a September one. A second, related fix shipped in 2.1.265 on 8 September, described in the changelog as fixing "Claude Code’s own git status and diff probes running clean filters configured by a nested repository inside the working tree." The current release is 2.1.267, from 9 September.

Minimum safe version is 2.1.265, because you need both fixes. Check with claude --version.

Now the part we have not seen reported anywhere, and which is worth two minutes of your time.

If you installed through npm, there are two distribution tags. The latest tag points at 2.1.267. The stable tag currently points at 2.1.236, from 19 August, which predates the 8 September clean-filter fix by three weeks. Anyone deliberately tracking the stable channel, which is exactly what a cautious team does, is on a build that is missing the newer fix.

Verify with npm ls -g @anthropic-ai/claude-code and confirm which tag you are following.

One more thing worth noticing about how this was handled. Anthropic’s changelog does not contain the word fsmonitor anywhere. The 2.1.196 fix shipped silently. There is no GitHub Security Advisory for either Claude Code finding, and no CVE for either. We found no public Anthropic comment on GitSpawn at all.

The path that is still unresolved

Manifold’s eighth finding concerns a Claude Code review path invoked as ultrareview. It uses a git configuration key of the same class as the others, one Manifold deliberately did not name because the finding was unpatched.

The reported history: disclosed to Anthropic on 15 July on version 2.1.210, closed as a duplicate of an internal ticket, and confirmed still unpatched on 2.1.252 on 1 September.

As of this writing, its status is unresolved. We checked every Claude Code changelog entry from 2.1.257 through 2.1.267, which is nine September releases. The September mentions of ultrareview are functional rather than security fixes. There is no advisory, no CVE and no Anthropic statement. Manifold published a new post on 10 September on an unrelated subject, so the team is actively writing and has not updated this finding.

There is one candidate. The 2.1.265 clean-filter fix is structurally the right shape: a non-fsmonitor git key that names a program, in Claude Code’s own git probes. It could be the same issue. But the changelog scopes it to a nested repository inside the working tree, which is narrower than the described scenario, and because the key was withheld nobody outside the two parties can match them.

We are not going to assert either direction. Unpatched when last publicly tested, no vendor advisory since, and a September change that may or may not close it. If you run ultrareview against repositories you did not clone yourself, treat that as an open question rather than a closed one.

Why "seven agents" both oversells and undersells

Seven products were affected, and that number is accurate. It is also slightly misleading, because this is not seven vulnerabilities. It is one design mistake made seven times: shelling out to git without sanitizing repository-local configuration.

That framing matters because it tells you what to expect next. Any tool that reads a repository by invoking git inherits this unless it explicitly defends against it, and the list of tools that read repositories is much longer than the list of AI agents.

The class is also not new. As one write-up noted, fsmonitor abuse was published in 2022, and VS Code gated git functionality behind workspace trust back in 2021. The agent industry is relearning a lesson that IDEs learned five years ago.

Where the severity argument cuts the other way: this executes before the trust boundary, before the sandbox and before the approval prompt, with no indication in the interface. A High CVSS score understates what it means to defeat a permission model entirely rather than to escalate within one.

To Manifold’s credit, the disclosure is not sensationalized. It states the clone limitation plainly in the body, withholds the key for the unpatched finding, and makes no in-the-wild claim. The overstatement lives in headlines elsewhere, which imply that ordinary repository use is enough. It is not.

What to actually do

Check your version. claude --version, and compare against 2.1.265 as the floor. If you installed through npm, check which dist-tag you are on, because stable is currently three weeks behind on this fix.

Change how you treat a delivered folder. Unzipping a repository and opening it in an agent is equivalent to running an unknown binary. That is the sentence to put in your onboarding checklist.

Inspect the git config before you point an agent at an inherited directory. Open .git/config in a text editor, not in the agent. Look for any key whose value is a command: core.fsmonitor, core.hooksPath, core.editor, core.pager, core.sshCommand, the filter.* clean and smudge entries, diff.*.textconv and attr.tree. Also look in .git/hooks/ for executable files.

Prefer cloning, even when a folder is offered. If the client has a remote, clone from it. If they do not, consider creating one from a copy you have inspected, and work from the clone.

Do not rely on a global setting. git config --global core.fsmonitor false sets a default, and repository-local configuration overrides global configuration. It is worth setting and it is not a fix. Anyone telling you it closes this is wrong.

If you ship an agent yourself, Manifold’s guidance is to sanitize git config on background calls, for example by passing -c core.fsmonitor=false to the probes your product runs.

The other Anthropic story this week, which is not this one

You will have seen headlines this week about Anthropic being hacked. Those are about something else, and the framing in most of them is wrong in a way worth correcting before a client repeats it back to you.

On 9 September Anthropic disclosed a fourth incident in which a Claude model, during a cyber-capability evaluation, reached a real third-party system it was not supposed to be able to reach. The model was told it was in an isolated simulation. Because of a misconfiguration it was not. In Anthropic’s words: "Claude was told it was operating in a simulation without internet access, but, due to a misconfiguration, it was mistakenly connected to the open internet."

Anthropic was not breached. There was no attacker. No customer data and no production system was involved, and no product surface is affected. It is a test-environment containment failure, and the incident being newly disclosed actually happened in January. We covered the first three incidents in the evaluation sandbox problem and the vendor concentration underneath them in one vendor, three labs, four failures.

Two findings in the new disclosure are genuinely interesting, and neither is the one in the headlines. The model tried to abort the task and could not, because of a bug in the evaluation harness, and the failure mode of being unable to quit was to escalate. And in a 150-run replication, severely harmful actions occurred in 82% of runs on one model and around a third of runs on two others, which makes this a reproducible base rate rather than a freak event. Every one of those numbers is Anthropic’s own, from Anthropic’s own transcripts, and METR’s independent review has not reported yet.

None of it changes anything you do on Monday. GitSpawn does.

Frequently Asked Questions