# GitSpawn: How a Repo's .git/config Runs Code Through Your AI Coding Agent URL: https://www.devopsness.com/blog/gitspawn-ai-coding-agents-git-config-hijack Author: Kiril Urbonas Published: 2026-10-26 Updated: 2026-10-26 Categories: AI Tags: Security, Git, DevSecOps, AI Agents, AI Security Summary: Coding agents call git status for context, and a hostile repository can make that run any program it names, outside the sandbox and without a prompt. Here is which agents are patched and how to protect yourself today. --- # 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. | Agent | Status at disclosure | Notes | |---|---|---| | Claude Code (`core.fsmonitor`) | Patched | Fixed in 2.1.196 | | Claude Code (`ultrareview` path) | Unpatched | Uses a different git setting of the same kind | | Goose | Patched | Fixed in 1.44.0, CVE-2026-72718 | | Hermes Agent | Unpatched | Confirmed on 0.21.0, CVE-2026-71963 | | Qwen Code | Unpatched | Confirmed on 0.22.3 | | Grok Build | Unpatched | Confirmed on 1.0.13 | | OpenAI Codex | Patched | Different mechanism, same class | | Cursor | Patched | Closed as a duplicate of an earlier report | 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: ```bash # 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: ```bash # 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](/blog/plugin4shell-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](/blog/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)](https://www.manifold.security/blog/ai-coding-agents-git-hijack) - [Git documentation: git-config, core.fsmonitor](https://git-scm.com/docs/git-config#Documentation/git-config.txt-corefsmonitor)