This blog spends most of its time arguing that Claude Code’s terminal-native, permission-gated architecture is the right foundation for agentic coding. That argument doesn’t hold up if it turns into cheerleading the moment Claude Code itself ships a bug. So: Anthropic has an open, unpatched remote-code-execution vector in Claude Code, disclosed two weeks ago, and it’s still there as of the latest release. Here’s what it is and why it matters.
The mechanism: GitSpawn#
Manifold Security researcher Francisco Rosales published GitSpawn on September 1, 2026, with a blunt opening: “Open a folder with Claude Code and it runs git status before you type anything. Before the workspace-trust prompt. On some agents, before you have even authenticated. If that folder came from somewhere else, the repository decides what that command runs.”
The root cause is that coding agents run git subprocesses to gather repository context the moment you open a folder — checking status, diffing, building a mental model of the project — and several of them do it before showing the “do you trust this folder?” prompt, and without sanitizing the repository’s own .git/config file. Git configuration supports settings that function as command-execution sinks: point one at an attacker-controlled binary, and the very first git status call the agent makes runs it, with the developer’s full privileges, outside any sandbox.
The specific sink Manifold names is core.fsmonitor — a performance setting that designates a helper program git invokes to report file changes, triggered by ordinary commands like git status or git diff. Clone a poisoned repo, open it in a vulnerable agent, and the payload runs before you’ve clicked anything.
Two distinct findings, one still open#
Manifold’s writeup covers eight findings across six agents, and Claude Code shows up twice:
| Agent | Sink | Status | CVE |
|---|---|---|---|
Claude Code — core.fsmonitor | context-gathering git status | Patched (v2.1.196) | — |
Claude Code — /ultrareview | a second, unnamed git-config key | Unpatched, confirmed at v2.1.252 | — |
| Cursor | same class | Patched | — |
| OpenAI Codex | same class | Patched | — |
| Goose (Block) | same class | Patched (v1.44.0) | CVE-2026-72718 (7.0) |
| Qwen Code | same class | Unpatched, confirmed v0.22.3 | — |
| Grok Build | same class | Unpatched, confirmed v1.0.13 | — |
| Hermes Agent (Nous Research) | same class | Unpatched, confirmed v0.21.0 | CVE-2026-71963 (VulnCheck-assigned) |
The first Claude Code finding — the general context-gathering git status call — was genuinely fixed, in v2.1.196, and Manifold credits Anthropic for closing it promptly.
The second is the one worth dwelling on. Running claude ultrareview — Claude Code’s dedicated cloud code-review session — triggers its own git subprocess before the review begins, and per Manifold: “This one is not core.fsmonitor. It is a different git setting of the same kind, one the review path does not strip.” The trigger, in the researchers’ words: “A user runs claude ultrareview to get a review of the repository they are in, and the payload executes before the review starts.”
Manifold deliberately withheld the specific config key name: “for the one finding that turns on a different config key we have left that key unnamed while it remains unpatched.” That’s a reasonable disclosure call — naming an active, unpatched sink would hand attackers a recipe — but it also means Anthropic has had the specifics since before publication and the fix still hasn’t shipped.
What Anthropic’s response tells you#
Per Manifold’s vendor-response table, Anthropic closed the core.fsmonitor report as “duplicate of a same-day report” (fine — it got fixed either way) but closed the /ultrareview finding as “duplicate of internal ticket.” That’s a meaningfully different signal than OpenAI’s and Cursor’s responses, both of which were also “duplicate of an earlier report” but arrived at an actual patch. An internal ticket existing is not the same as a fix shipping.
I checked this independently against Claude Code’s own changelog rather than taking Manifold’s word for the current state. The raw CHANGELOG.md shows no entry mentioning fsmonitor, git-config sanitization on the /ultrareview path, or anything matching this fix description anywhere between v2.1.252 (Aug 28, Manifold’s last confirmed-unpatched check) and the current v2.1.270 (Sept 12) — eighteen point releases and counting, none of which address it. The closest thing in that window is an unrelated /ultrareview --post UX change in v2.1.269. Anthropic ships security fixes in this changelog routinely and often without much fanfare (see the zsh sandbox bypass fix from three weeks ago, or the backslash symlink containment bypass a week before that) — so this isn’t a case of Anthropic being generally quiet about security work. This specific gap just hasn’t closed yet.
Severity, in plain terms#
Manifold’s own framing: this enables “arbitrary code execution as the developer, outside the sandbox, with no approval prompt.” For /ultrareview specifically, that means running a command explicitly marketed as a safe, read-oriented review step — “let the agent look at my code and tell me what’s wrong with it” — is itself the trigger. There’s no equivalent of “don’t run destructive commands” guardrail here, because the payload fires before Claude Code’s own permission model is even in the loop. It’s not a jailbreak or a prompt-injection trick; it’s a subprocess execution path that predates the product’s safety layer entirely.
For context on scale: Manifold cites Claude Code at 77+ million monthly npm downloads. Not every one of those installs runs ultrareview against untrusted repositories, but “clone a repo, ask the agent to review it” is about as mainstream a workflow as this product has.
Mitigations, right now#
Manifold’s own recommendation: inspect .git/config before opening an unfamiliar directory with any agent — cat .git/config in the cloned repo, before pointing anything at it. Their suggested vendor-side fix is straightforward — sanitize the sink at the call site, the same pattern as git -c core.fsmonitor=false status — which is presumably close to whatever Anthropic’s internal ticket already describes.
Practically, for /ultrareview specifically: until this ships, don’t run it as the first action against a freshly cloned, untrusted repository. Run a manual git config --list --file .git/config check first, or restrict /ultrareview usage to repositories you already trust and have opened (and thus already git-configured-inspected) through the normal trust flow.
The pattern this fits#
This is the fifth distinct agentic-coding security class this blog has tracked in under a year, after MCP OAuth token hijacking, STDIO transport injection, TrustFall/SymJack’s trust-dialog and symlink-approval gaps, and April’s CLAUDE.md supply-chain CVE. The through-line hasn’t changed: agents are valuable because they act autonomously on project context the moment you point them at a folder, and every one of those context-gathering steps — git status, config reads, file listing — is a step that runs before the product’s own consent and sandboxing machinery engages. Vendors keep closing individual instances; the class keeps producing new ones.
Anthropic’s architecture is still the right foundation — sandboxed subprocess execution, sandbox.credentials, worktree isolation, and an increasingly serious internal security response cadence are real, verifiable advantages over IDE-anchored tools that don’t publish this level of changelog detail at all. But “the right foundation” doesn’t mean “immune,” and a disclosed, reproducible RCE sitting on an internal ticket for two-plus weeks while eighteen other releases ship is worth calling out plainly, not softening into a footnote.
Sources: Manifold Security — GitSpawn disclosure · Claude Code CHANGELOG.md · VulnCheck — CVE-2026-71963