Security

GitSpawn Explained: How a Hostile .git/config Runs Code Through AI Coding Agents

Eight flaws across seven coding agents let a repository run code before any approval prompt. Here is how GitSpawn works and how to protect your machine.

MO

Marcus Oyelaran

Security & DevOps Specialist

Published Oct 23, 2026 7 min read

GitSpawn is a family of flaws in which a repository's own .git/config file makes git run a program on your machine. AI coding agents call git in the background for context, so the program can run before any approval prompt or sandbox. Manifold Security reported eight findings across seven agents. The fix for you is simple: read the config first.

This explainer is for developers, platform engineers and security teams who let AI coding agents open code from outside their own organization. It covers how the attack works, which tools were named, and the defenses that cost almost nothing. Backtrace covers developer security with one rule: assume the repository is hostile until you have read it.

What Is GitSpawn and How Does It Run Code?

GitSpawn abuses git's own configuration. Git reads settings from a repository's .git/config file, and a few settings name a program that git runs during normal operations. One example is core.fsmonitor, a performance setting that git runs during index refreshes. A malicious repository can point it at any command.

The attack works because agents call git constantly. AI coding agents run git commands in the background to gather project context. According to Manifold Security's GitSpawn research, agents do not strip the repository's own config on those calls. The named command runs with the user's privileges.

That matters because it happens outside the safeguards people trust. The command runs outside the sandbox and without an approval prompt. In some agents it fires before the workspace-trust dialog even appears.

The result is arbitrary code execution as the developer. That can expose SSH keys, cloud credentials, tokens stored in shell configuration files, local repositories and a foothold for later access. In short, it is the kind of access a CI pipeline would never hand to an untrusted contributor.

Which Coding Agents Were Affected?

Manifold reported eight findings across seven agents: Claude Code with two findings, Goose, Grok Build, Hermes Agent, Qwen Code, OpenAI Codex and Cursor. The authors say they found the same flaw in other agents they did not name. Four findings were patched at publication on September 1, 2026, and four were not.

The patch status at publication looked like this.

Treat the table as a snapshot, not a current status. Patches land quickly after disclosure, so check each vendor's release notes. A later security roundup from Adversa AI's October 2026 coverage of coding agent vulnerabilities lists GitSpawn among a wider set of agent flaws, so the topic is still active.

The vendor responses are a story of their own. Several reports were closed as duplicates of earlier findings, and Manifold says five were duplicates of work other researchers had filed independently. For Hermes Agent, the authors report no triage after six contact attempts across five channels. Multiple researchers found the same hole, which suggests it was easy to find.

Does Cloning a Repository Trigger the Attack?

No. Cloning, fetching or pulling from a hostile URL does not trigger GitSpawn, because git does not copy the sender's .git/config during those operations. The danger comes from receiving a repository as files, with its .git directory included, then opening it in an agent.

That narrows the real-world risk, but it does not remove it. Developers receive project folders as zip files, shared drive links, sync folders and USB sticks all the time. Contractors send code. Candidates send take-home exercises. Teams hand off prototypes in a compressed archive.

The proofs of concept all used a zip file holding a repository with a malicious config. The triggers varied by agent. Running a review command, opening a folder, sending a first message or even a first keystroke was enough in different tools. The authors withheld a ready-made repository and the unnamed config key.

The delivery path tells you where to focus. Treat any repository that arrives as a file bundle the way you would treat an executable attachment. A repository you cloned from your own organization's server is a different risk from a zip someone emailed you.

How Do You Check a Repository Before Opening It?

Read the .git/config file in a plain text editor before pointing any agent at the folder. Look for any setting that names a program, such as core.fsmonitor, a custom hooks path or a custom SSH command. If anything looks unfamiliar, do not open the folder with an agent on your main machine.

Manifold's advice for users is to inspect .git/config before opening a received directory, since any setting that names a program can run one. Review it the way you would review a build script. That framing helps, because most teams already read build scripts from unknown sources with suspicion.

Here is a short routine for any repository that arrives as files.

The container step is the strongest control. A throwaway environment limits the damage even if you miss a malicious setting. It also keeps your SSH keys and cloud credentials out of reach. Keep secrets outside the project tree and out of containers you use for untrusted code.

What Should Teams and Agent Vendors Do?

Teams should set a policy: agents never open externally supplied repositories on a machine that holds production credentials. Vendors should sanitize git config on background context-gathering calls, for example by disabling core.fsmonitor in the git invocation. Both fixes are small, and both close the gap.

For teams, the policy should be concrete. Name the allowed environment, such as a disposable development container. Make it easy to follow, because a rule that costs ten minutes per use will get skipped. Our guide to least privilege access for cloud engineering teams explains how to limit what a compromised laptop can reach.

Secrets deserve the same attention. If an agent runs hostile code as you, anything on disk is exposed. Run a secrets scan on your own repositories and move long-lived keys into a manager. Our comparison of secrets scanning tools shows which tools catch what.

This is also a supply chain problem in a new form. We described the broader pattern in our explainer on software supply chain attacks for engineering teams. The attacker does not need to break into your network. They need you to open a folder.

Finally, remember that agents add their own risk on top. Our review of autonomous coding agents covers where they need supervision. Giving an agent unreviewed code and broad permissions is a bet on every tool in the chain.

Is GitSpawn the Only Way Agents Run Hostile Code?

No. The Adversa roundup lists several related problems, and they share a theme: agents trust files they should not. In one study, a malicious lifecycle hook added through a plugin update compromised all seven tested harnesses, with up to 92.5 percent success across ten objectives. Scanners missed nearly half of the samples.

Another finding, called Plugin4Shell, says several agents install pinned plugin commits without verifying the result. A branch named like the commit hash can then swap in malicious code. The advice is to disable automatic plugin updates until the agent verifies the commit that actually landed.

These are secondhand summaries of other researchers' work, so check the original reports before acting on any single number. The pattern is still clear. Configuration files, plugins and repository settings are now an attack surface, because agents read and act on them automatically.

That is why a simple rule works better than a list of patches. Treat anything an agent reads as code, and give the agent the same limits you would give an unreviewed script.

What Is the Bottom Line on GitSpawn?

GitSpawn is not a reason to stop using coding agents. It is a reason to stop opening strangers' folders on a laptop that holds your keys. At Backtrace, we rate the risk as low for repositories cloned from your own servers and high for anything that arrives as a zip.

Read the config, use a disposable container, and keep agents updated. Those three habits close the hole this research describes, and they will help against the next flaw of the same kind.