# GitSpawn: Your Agent Runs Git. The Repo Picks the Command. > GitSpawn is a class of bugs where an AI coding agent runs git commands in a repository that arrived as files, and Git executes a program named in that repo's own .git/config. Manifold found the pattern in seven agents. We reproduced it on Goose 1.41.0: goose review ran a marker helper six times with no prompt and no model. Source: https://hackerlogs.com/blog/gitspawn-ai-agents-git-hijack Published: 2026-09-07 ## Key takeaways - The execution sink is documented Git behavior: core.fsmonitor names a helper that runs during an index refresh on git status and git diff. - Delivery is a folder that still contains .git/config. A normal git clone drops that file. A zip, sync share, or USB copy does not. - On Goose 1.41.0, goose review invoked our local marker helper six times and never asked a question or called a model. - Goose 1.44.0 blocked the same repository by passing -c core.fsmonitor=false. That command-line override is the control that actually holds. - A global git config of core.fsmonitor=false does not win over a hostile local config. Inspect .git/config before an agent opens a received folder. Manifold Security published GitSpawn on 1 September 2026: AI coding agents gather repository context with ordinary git commands, those commands refresh the index, and Git will run a program named in the repository's own configuration. The model is not in that path. Neither is the agent's permission prompt. That is a strong claim, so we reproduced the documented sink ourselves. The helper in this lab only appends a line to a local log. It does not touch secrets, open a network socket, or ship as a zip anyone could send a colleague. Manifold withheld a ready-made repository for the same reason. Arbitrary host execution as the developer, outside the agent sandbox, with no approval prompt. Severity here follows the Goose advisory (CVSS 4.0 base 7.0) rather than the higher Codex Desktop score, because a person still has to open a received folder. Four-panel diagram of GitSpawn: a repository arriving as files keeps .git/config, Git's core.fsmonitor setting names a helper, an agent triggers git status or git diff, and the helper runs on the host. Goose 1.41.0 ran the helper six times; Goose 1.44.0 ran it zero times. ## What Git actually does `core.fsmonitor` is a performance setting. For a large working tree, Git asks a helper which files changed instead of walking the disk. The [git-config documentation](https://git-scm.com/docs/git-config) says the value may be a boolean that starts the built-in daemon, or the pathname of a hook command. Git reads that value from the repository's own `.git/config`. Any command that refreshes the index, including `git status` and `git diff`, invokes it. That is intended behavior. It is also an execution sink. A folder that still contains the attacker's `.git` directory can name the helper. A `git clone` cannot, because clone builds a new local config and leaves the source file behind. > Clone is safe for this specific file. A zip of the same project is not. Colleagues pass working trees around as archives, sync folders, and USB sticks. Those copies keep `.git/config`. ## What the agents add Coding agents run those same git commands to work out the branch, the dirty files, or the diff they are about to review. Manifold's write-up, and the Goose advisory that followed it, are specific about the failure: the agent passed the repository config through untouched. Goose's review path added only `-c core.quotePath=off`. It did not strip `core.fsmonitor`. The Goose maintainers documented the result in [GHSA-r5pp-p5r8-466r](https://github.com/aaif-goose/goose/security/advisories/GHSA-r5pp-p5r8-466r) as CVE-2026-72718. `goose review` gathers `git diff HEAD` before it contacts a model. A malicious local config executes on the host, unsandboxed, with the user's environment. Manifold reported the same class in Claude Code, Cursor, Codex, Hermes, Qwen Code, and Grok Build, and said it found the pattern in agents it did not name. OpenAI published CVE-2026-19592 and CVE-2026-19593 for Codex the same day the research went public. Those records describe the same shape: metadata collection, a preserved `.git/config`, and a helper that runs outside the command sandbox. ## What we ran We used the vulnerable Goose 1.41.0 Linux binary named in the advisory, then the patched 1.44.0 binary from the same GitHub releases. The repository lived under `/tmp`. The helper wrote only to `/tmp/gitspawn-lab/EXECUTED.log` and then exited so Git would fall back to a normal scan. The recording is the same session, cropped to the terminal. Terminal recording of the GitSpawn lab: Goose 1.41.0 review writes six EXECUTED.log lines with no prompt, then Goose 1.44.0 review leaves the marker at zero bytes. Two stills if you would rather not play the loop: Terminal still showing Goose 1.41.0 goose review and six EXECUTED.log lines. The caption reads helper ran 6 times, no prompt, no model. Terminal still showing the same repository under Goose 1.44.0. wc -c EXECUTED.log reports 0 bytes. > This lab is a marker, not a payload archive. Do not turn it into a zip you send anyone, and do not point an agent at a working tree you did not inspect. ## Who is affected The table is a scorecard, not a guarantee. Manifold said it found the pattern in more agents than it named. Codex Desktop's record also names `attr.tree` plus a clean or process filter, which is a reminder that `core.fsmonitor` is one documented sink, not the only one. Hermes's later patch isolates a noninteractive git environment and disables external diff and textconv drivers separately, which is the right shape: one `-c` flag is not a complete hardening story. ## What to do If you receive a repository as files, inspect it before any agent opens the folder: ``` git config --local --show-origin --get-regexp '^(core\.fsmonitor|core\.hooksPath|credential\.|diff\..*\.(command|textconv))' ``` Any hit deserves a human look. An empty result is not a proof of safety, because other command-bearing keys exist and one of them is still unnamed in the Claude ultrareview finding. If you run an agent, upgrade first: Goose 1.44.0 or later, Claude Code 2.1.196 or later for the published `core.fsmonitor` path, Codex CLI 0.131.0 or later, current Cursor, and a Hermes build that contains `f6234d0` rather than the 0.21.0 tag. Then treat Qwen Code, Grok Build, and Claude `ultrareview` as still hostile to received folders until their vendors publish a fix you can name. If you ship an agent, do not trust repository-local git config on background calls. The override we watched work is the one Manifold recommended and Goose shipped: ``` git -c core.fsmonitor=false status ``` A global `git config --global core.fsmonitor false` is still worth setting on machines you own. It is not a control against a folder that carries its own `.git/config`. We checked: the local value is the one Git used. The broader lesson is the same one that keeps showing up in agent security. The dangerous code is often not the model. It is the ordinary subprocess the product runs to find out where it is. ## Sources - [GitSpawn: A Single Flaw Lets Untrusted Repos Run Code in Claude Code, Codex, Cursor, and Grok](https://www.manifold.security/blog/ai-coding-agents-git-hijack) (2026-09-01) - [Arbitrary command execution in goose CLI via goose review via git core.fsmonitor](https://github.com/aaif-goose/goose/security/advisories/GHSA-r5pp-p5r8-466r) (2026-07-24) - [CVE-2026-72718](https://osv.dev/vulnerability/CVE-2026-72718) (2026-08-10) - [Git - git-config documentation, core.fsmonitor](https://git-scm.com/docs/git-config) - [CVE-2026-19592](https://app.opencve.io/cve/CVE-2026-19592) (2026-09-01) - [CVE-2026-71963](https://nvd.nist.gov/vuln/detail/cve-2026-71963) (2026-09-03) - [Malicious .git Configs Can Make Claude, Codex, Cursor, and Other AI Agents Run Attacker Code](https://thehackernews.com/2026/09/malicious-git-configs-can-make-claude.html) (2026-09-03)