GitSpawn: How Opening a Folder Can Run Code in Your AI Coding Agent

In September 2026, Manifold Security published research it calls GitSpawn: a single pattern that lets an untrusted repository run commands on a developer's machine through their AI coding agent. No prompt injection is involved, and no approval dialog appears. The agent simply runs git to find out where it is, and git does what the repository's own config tells it to. Source

If your engineers use Claude Code, Codex, Cursor, Goose or similar tools, this is worth ten minutes of your team's time. The lesson reaches beyond one bug. The risky part of an AI coding agent is often not the model. It is the ordinary plumbing the agent runs at startup, outside the controls you thought were protecting you.

What Manifold found

Manifold's team asked a simple question: what does a CLI coding agent actually do when it starts? They found that agents gather context about the project they have been opened in, and a good part of that is done with git. Those background calls did not strip the repository's own git configuration, and several git settings can execute commands. Source

Manifold reports eight findings across seven agents, and says four were still unpatched at publication on September 1. Its outcome for an attacker is arbitrary code execution as the developer, outside the sandbox, with no approval prompt and nothing on screen. That means access to SSH keys, cloud credentials in the environment, tokens in shell config and every repository on disk. Source

The mechanism in plain terms

The setting at the center is core.fsmonitor. It is a performance feature for large repositories: instead of checking every file on disk, git asks a helper program what changed. Git's own documentation describes this hook as a program that reports which files may have changed since a requested time. Source

Git reads core.fsmonitor from the repository's own .git/config. Manifold's point is that a repository can name a command there, and any git command that refreshes the index will run it. Commands as routine as git status and git diff do this. Which one the agent picked does not matter. Source

Manifold also stresses that core.fsmonitor is not the only setting of this kind. One of its findings turns on a different config key, which it has left unnamed while that finding remains unpatched. Source

Because the agent spawns git as its own subprocess, the command runs outside the agent's sandbox and never passes through its permission model. Source

How a repo reaches you

Delivery matters here, and Manifold is precise about it. Cloning a hostile URL does nothing, and neither does fetch or pull, because git never transports this setting. The repository has to arrive as files with its .git directory already inside. That means a shared zip, a shared drive, a sync folder or a USB stick. Manifold notes that colleagues pass projects around this way and consultants hand them to clients, and says it used a zip for every proof of concept. Source

For an agency or a company that works with outside contractors, that is a normal handoff. It is also how many teams share a demo project or reproduce a bug.

What it looked like in different agents

Manifold's write-up covers several cases. As of its September 1 publication: Source

• Goose: goose review built its diff with git diff and stripped none of the repository config, so the command ran before goose contacted the model. Reported July 13 against 1.41.0, fixed in 1.44.0 as CVE-2026-72718, scored 7.0 by the maintainers.

• Claude Code (core.fsmonitor): the startup git status ran while the workspace-trust prompt was still waiting to be accepted. Reported June 26, closed as a duplicate of a same-day report, fixed in 2.1.196.

• Claude Code (ultrareview): a different git setting of the same kind, firing before the review begins. Reported July 15 and confirmed still unpatched on 2.1.252 on September 1.

• Hermes Agent: context gathering on the first message. Manifold reports six contact attempts across five channels with no triage, and CVE-2026-71963 assigned by VulnCheck. Unpatched at publication.

• Qwen Code: the payload runs at startup, even before the user has authenticated. Reported July 7 and accepted by Alibaba's response center. Unpatched at publication.

• Grok Build: the payload runs on the first keystroke of a prompt. Unpatched at publication.

• Codex and Cursor: both were also affected, came back as duplicates of earlier reports and have since been patched.

These statuses are as of Manifold's post. Vendors move fast on this class of bug, so check each tool's current release notes before you rely on any "unpatched" label. Source

One more detail from the disclosure record: Manifold says five of its reports duplicated findings other researchers had already filed independently, one on the same day. Its reading is that the pattern is being found from several directions at once. Source

Why this is an AgentOps problem

Teams tend to ask whether the model can be tricked. GitSpawn shows a different risk. The agent harness, the code around the model, runs processes on the developer's machine with the developer's privileges. Manifold puts it directly: the vulnerability is not in the model or in anything new, it is in the ordinary plumbing underneath. Source

Manifold also points out that endpoint detection sees familiar developer tooling doing familiar things, and that the gateway sees authenticated traffic it already allows. Neither sees what the agent itself decided to do. Manifold Security That is a monitoring gap, and it is the same gap that shows up with any agent that picks up something it did not write.

A checklist for engineering teams

The first two items come from Manifold's own advice. The rest are our recommendations.

1. Inspect .git/config before opening a received folder with an agent. Manifold's guidance is that any setting naming a program can run it. Source

2. If you build or ship an agent, sanitize git config on background calls. Manifold's example is passing core.fsmonitor=false on git status. Source

3. Treat zipped repos as untrusted. Prefer a fresh git clone from a known remote over an archive that carries its own .git directory.

4. Open unknown projects in a throwaway environment. A container or disposable VM with no cloud credentials and no SSH agent limits what a startup command can reach.

5. Keep secrets out of the default shell environment. Short-lived, scoped credentials beat long-lived tokens in shell config.

6. Track agent versions. Keep an inventory of which coding agents and versions your team runs, and who watches their security advisories.

7. Log what agents spawn. Process-level logging on developer machines helps you answer what ran when something looks wrong.

8. Write a contractor handoff rule. Decide how code from outside parties gets opened, and who checks it first.

Where Codesprint fits

We help teams put agents into real engineering workflows, including the unglamorous layer around them: environments, permissions, credentials, logging and review. Our AgentOps services cover that work. If you want a second pair of eyes on how your developers run coding agents, contact us.