GitSpawn: How a Repo's .git/config Runs Code Through Your AI Coding Agent

A malicious repository can run commands on your machine the moment your AI coding agent checks git status. GitSpawn, named by Manifold Security, abuses git settings like core.fsmonitor that tell git to execute a program, outside the agent's sandbox and approval prompt. Update your agent, and check .git/config on any repo you received as files.

How a git status becomes code execution

Coding agents constantly run git in the background to understand your project: git status, git diff, git log. Those feel read-only. They aren't quite.

Commands like git status refresh git's index, and during that refresh git invokes any file-system monitor helper configured in the repository. core.fsmonitor exists for performance on huge repos, and its value is a program path. Git runs it. If the repository's own .git/config sets core.fsmonitor to a script the attacker shipped, every background git status your agent fires executes that script.

Two details make this worse in agents than in a normal terminal:

• It bypasses the agent's own controls. The agent treats its context-gathering git calls as safe plumbing, so they often skip both the sandbox and the "allow this command?" prompt that would catch curl | sh.
• It needs no action from you. You open the folder and ask a question. The agent does the rest.

There is one important limit. Cloning, fetching, or pulling a hostile URL does not trigger it, because .git/config is not transferred by git. The repository has to arrive as files with its .git directory included: a zip from a "take-home assignment," a shared drive, a sync folder, a USB stick, or a tarball attached to a bug report.

Which agents were affected

Manifold Security published eight findings on September 1, 2026. The status below is from that disclosure and follow-up coverage; check your vendor's changelog for anything newer.

The pattern matters more than any single row. Any tool that runs git on a directory it didn't create is exposed to whatever that directory's config tells git to execute. That includes IDE extensions, pre-commit frameworks, and your own scripts, not just AI agents.

Check a repository before your agent touches it

core.fsmonitor is the headline, but several git settings name programs. Before opening any repository that arrived as files, list the ones that can execute something:

# Run from the untrusted repo root, BEFORE opening it in an agent or IDE
$ git config --file .git/config --list | grep -iE \
    'fsmonitor|hookspath|pager|editor|sshcommand|askpass|external|textconv|filter\.|credential|gpg\.program|program'

# Also look for hooks and unexpected executables inside .git
$ ls -la .git/hooks/ | grep -v '\.sample$'
$ find .git -type f -perm -u+x ! -path '*/hooks/*.sample'

Anything that prints deserves a look. Legitimate repositories rarely set these in the local config; they live in your global ~/.gitconfig if anywhere.

The safest habit is simpler: don't use the shipped .git at all. If a repo has a remote, clone it fresh. If it doesn't, keep the files and start a fresh repository:

# Discard the untrusted git metadata and start clean
$ rm -rf .git && git init && git add -A && git commit -qm "import"

You lose the original history, which for a take-home or a bug repro rarely matters.

Defenses that hold up

For individuals:

• Update your agent. Check you're past the fixed versions in the table, and re-check after vendor advisories.
• Run agents on untrusted code inside a container or VM. A devcontainer or disposable VM turns "runs as you" into "runs as a throwaway user with nothing worth stealing." Don't mount your SSH keys or cloud credentials into it.
• Treat repos-as-files like email attachments. Zips are the delivery vehicle here.

For teams and vendors:

• Override repository config on background git calls. Manifold's suggested fix is running context commands with the dangerous setting forced off, for example git -c core.fsmonitor=false status. If you build internal agent tooling or scripts, do this for every git call against a directory you didn't create.
• Put context-gathering commands under the same policy as user commands. "Read-only" plumbing is exactly what attackers target once the obvious paths are prompted.
• Pin and review agent plugins too. It's the same trust boundary problem; we covered it in coding agent plugin pinning.

The broader lesson is the one from every agent security incident this year: agents act with your permissions, so anything that can steer them inherits those permissions. Our guide to AI agent security covers the least-privilege setup in more depth.

Questions people ask

What is GitSpawn?

GitSpawn is Manifold Security's name for a class of flaws in AI coding agents where a repository's .git/config makes git execute a program, through settings such as core.fsmonitor, when the agent runs background commands like git status. The program runs as the user, outside the agent's sandbox and without an approval prompt. It was disclosed on September 1, 2026.

Is cloning a malicious repository with an AI agent dangerous?

Not for this specific flaw. Git does not transfer .git/config when you clone, fetch, or pull, so a fresh clone can't carry a hostile core.fsmonitor. The risk comes from repositories shared as files with their .git directory included, such as zip archives, shared drives, and sync folders.

How do I protect myself from GitSpawn?

Update your coding agent to a patched version, and before opening any repository you received as files, inspect .git/config for settings that name programs, such as core.fsmonitor, core.pager, or core.sshCommand. Better still, delete the shipped .git directory or re-clone from the remote, and run agents on untrusted code in a container or VM.

The decision, concretely

• Received a repo as a zip? Delete .git or re-clone before opening it in any agent.
• Using Hermes, Qwen Code, or Grok Build? Check for a fix, and until then don't point them at untrusted folders.
• Building internal agent tooling? Force dangerous git settings off with -c on every background call.
• Reviewing take-home assignments or bug repros? Do it in a disposable container.

The call we'd make

Patch your agent, then change one habit: never let an agent run in a folder whose .git you didn't create. The fix vendors are shipping closes core.fsmonitor, but git has many settings that name programs, and the next variant will use another one. Re-cloning or re-initializing untrusted repos closes the whole class for the cost of a few seconds.

Sources

• Manifold Security: AI coding agents and git config hijacking (GitSpawn)
• Git documentation: git-config, core.fsmonitor