What happened
On September 1, 2026, Manifold Security disclosed GitSpawn: a class of eight code-execution findings spanning seven AI coding agents — Claude Code, OpenAI Codex, Cursor, Goose, Qwen Code, Grok Build, and Hermes Agent. Claude Code alone has more than 77 million monthly npm downloads, which gives some sense of how many developer machines run at least one of the affected agents.
The disclosure's headline claim is the part worth sitting with: a booby-trapped repository can execute code on a developer's machine the moment it's opened with an AI coding agent installed. No prompt typed. No approval clicked. In some cases, before the user has even authenticated with the agent. Seven agents were tested against the technique; seven failed.
Patching wasn't uniform or fast. At Manifold's retest on the day the research went public, four of the eight findings were still exploitable — Hermes Agent, Qwen Code, Grok Build, and a second vulnerable configuration path in Claude Code. This isn't one vendor's bug with one vendor's fix; it's the same design assumption, made independently by several teams, breaking the same way.
How it worked
Nearly every AI coding agent gathers project context automatically the moment a session starts — running ordinary background commands like git status or git diff so the model knows what repository it's in and what's changed. That's a reasonable feature. The problem is what those calls run against: the repository's own git configuration, unsandboxed, exactly as if a human developer had typed the command themselves.
Git supports configuration settings that are, by design, command-execution sinks — mechanisms meant to let a developer wire git into their own local tooling. Those settings are meant to be trusted because a developer chose them for their own machine. A cloned repository can ship its own git config carrying the same kind of setting, and the agent's routine "figure out where I am" call runs whatever it names — on the host, with the developer's own privileges, before any tool-approval prompt the agent might otherwise show ever fires.
From there the impact is whatever an attacker wants it to be, at the privilege level of whoever opened the repo: SSH keys, cloud credentials sitting in the environment, tokens in shell configuration, the contents of every other repository on disk, and a working foothold on the machine to pivot from. None of it requires the victim to run anything, type anything, or approve anything — opening the repository was the exploit.
Why this matters beyond seven agents
GitSpawn isn't a bug in one product; it's a class that several unrelated teams independently reproduced by adding the same convenience feature. Every coding agent that auto-gathers git context inherited the same unstated assumption: that a repository's own configuration is safe to consult. That assumption was reasonable when a human ran git commands deliberately, glanced at the output, and decided what to type next. It stops being reasonable the moment an agent runs the same commands automatically, at machine speed, before a human has looked at anything.
It's the software-supply-chain problem in a new place. The pattern — content you didn't write getting to execute code inside tooling you trust, because nothing drew a hard line between "data the agent reads" and "commands the agent's own plumbing might run" — is the same one that has made compromised build dependencies and malicious CI actions a standing risk for a decade. GitSpawn just moves the untrusted input one step earlier: not a package you deliberately installed, but a repository you only opened to look at.
Because the vulnerable behavior lives in agent-side plumbing built independently across products, there's no single platform fix. An organization's actual exposure here is a function of which coding agents its engineers run and whether each one has shipped — and been installed — a real fix, not whether any one vendor patched first.
A developer-endpoint vector, not infrastructure Apophis engages against — but the same trust failure on the platform side is exactly what Apophis's GitHub/CI-CD mode tests for
GitSpawn doesn't hit anything Apophis pentests directly. The exploit runs on a developer's own laptop, triggered by the coding agent's local git plumbing — there's no target IP, URL, or cloud account to point an engagement at. The vulnerable surface is the agent binary installed on someone's machine, and closing it is a patch-and-upgrade problem for whichever agent an organization's engineers run, not a finding a pentest surfaces.
What Apophis's GitHub and CI/CD penetration testing mode does cover is the adjacent half of the same trust failure: whether an organization's repositories, Actions workflows, and pipeline extend unearned trust to untrusted content the way GitSpawn's affected agents did — a malicious pull request title reaching a privileged workflow, a self-hosted runner executing code from a public fork, a compromised Action harvesting secrets across thousands of repositories. GitSpawn is that same failure shape reaching one step further down the chain than a CI/CD engagement reaches: onto the endpoint of every engineer who clones the repo with a coding agent installed.
An organization asking whether it's exposed here needs two separate answers: an Apophis engagement for the platform and pipeline side, and a current, patched build of whatever coding agent its engineers actually run locally. The second one isn't something a pentest finds for you.