Dekita

Your agent ran git. So did the repo: auditing repositories that arrive as files

security ai git devtools

Before you point a coding agent at a folder that arrived as a download, run one command:

git -C /path/to/repo config --local --list --show-origin

If the output contains core.fsmonitor, core.hooksPath, attr.tree, or anything under filter. or diff. that names a command, stop. A line like fsmonitor = ... in that file is a program that git will run the next time it refreshes the index, and git status and git diff refresh the index. Those are the two most boring commands in the tool, and they are exactly the ones your agent runs at session startup to learn the branch and what changed.

What GitSpawn is

Manifold Security disclosed eight flaws across seven command-line coding agents in early September 2026, under the name GitSpawn. The pattern has three parts.

The sink: core.fsmonitor is a legitimate, documented git performance setting. Its value is a command git runs to learn which files changed, so large repositories skip a full filesystem scan. Git reads the value from the repository's own .git/config.

The trigger: CLI coding agents call git status or git diff in the background when you open a project, to build context. They leave the repository's configuration untouched while doing so. Repository config in, background git call out, command executed.

The consequence: the command runs as your user, on your machine, outside the agent's sandbox, and it never passes an approval prompt. Per Manifold's testing, as reported in the coverage below, Claude Code and Hermes Agent fire the payload before the workspace-trust prompt is accepted. Qwen Code fires it before you have authenticated. Grok Build fires it on the first keystroke.

This is not prompt injection and not MCP misconfiguration. The payload never touches the model. It sits in git metadata, and what fires it is the product's own plumbing.

Who was affected

This table is the snapshot from Manifold's September 1 retest, the most recent published data point:

| Agent | Status at publication | |---|---| | goose | Fixed in 1.44.0, CVE-2026-72718 (CVSS 7.0) | | OpenAI Codex CLI | Fixed in 0.131.0, CVE-2026-19592 | | OpenAI Codex Desktop | Fixed, CVE-2026-19593 | | Cursor | Fixed | | Claude Code, core.fsmonitor path | Fixed in 2.1.196 | | Claude Code, second path behind claude ultrareview | Unpatched at 2.1.252; uses a different config key Manifold has not published | | Hermes Agent | Unpatched at 0.21.0, CVE-2026-71963 | | Qwen Code | Unpatched at 0.22.3 | | Grok Build | Unpatched at 1.0.13 |

Later public record is partial: Hermes merged a fix on September 2 with tag 0.21.1 on September 7, and version 0.21.6 on October 8 closed a further class where filter programs are defined by an untrusted repository's config. Qwen Code merged a fix on September 12. For Claude Code's second path, Cursor and Grok Build, the public trail is thin as of mid-October. Check your vendor's changelog rather than trusting this table.

For scale, the seven agents were reported to combine for more than 77 million monthly npm downloads, with Claude Code the largest share. That figure comes from the disclosure as relayed by coverage, so treat it as reported, not audited.

Why the clone is safe and the folder is not

A git clone never carries .git/config. Clone, fetch and pull transfer committed content and refs, not the source repository's local settings. The attack needs the repository to reach you as files with its .git directory intact: a zip from a contractor, a vendor's shared drive, a synced project folder, a USB stick, a repro archive attached to a support ticket.

That sounds niche until you count how often "can you take a look at this?" arrives as a zip. If any part of your workflow is "the repo showed up as a download," you are in the threat model.

The audit, before an agent touches the folder

Save this as audit-repo-config.sh and run it on any directory that arrived from outside your organization:

#!/usr/bin/env bash
# audit-repo-config.sh - flag command-valued git settings in a received folder
# usage: bash audit-repo-config.sh /path/to/repo
set -u
repo="${1:-.}"

echo "== all local settings, with origin =="
git -C "$repo" config --local --list --show-origin

echo
echo "== settings whose value can name a program =="
git -C "$repo" config --local --list \
  | grep -Ei '^(core\.fsmonitor|core\.hookspath|core\.pager|core\.editor|core\.sshcommand|attr\.tree|filter\.[^ ]*\.(clean|smudge|process|required)|diff\.[^ ]*\.command|alias\.[^ ]*)=' \
  || echo "(none)"

echo
echo "== hooks that are not samples =="
find "$repo/.git/hooks" -type f ! -name '*.sample' 2>/dev/null || echo "(no hooks directory)"

echo
echo "== attributes file =="
cat "$repo/.gitattributes" 2>/dev/null || echo "(no .gitattributes)"

core.pager=less and core.editor=vim are normal. Everything else on that list deserves a human look before an agent opens the folder.

Then, in order of preference:

  1. Re-clone from the canonical remote and work in the fresh clone. A clone drops local config. This is the cleanest fix and it costs one command.
  2. Unset the known key: git -C /path/to/repo config --local --unset core.fsmonitor. Treat this as necessary, not sufficient: the withheld second key used by the claude ultrareview path means unsetting fsmonitor alone does not close every door.
  3. Open genuinely untrusted repositories in a throwaway container or VM, or a separate user account with no access to your SSH keys and cloud credentials. The payload runs outside the agent's permission model, so the agent's own modes will not save you. Put the boundary at the operating system.

It is not just fsmonitor

Git has a family of settings that name programs, and some of them run during ordinary read-only commands. Clean and smudge filters are configured in .git/config and switched on per file by .gitattributes; git can run them during a plain status. core.hooksPath redirects the hooks directory. attr.tree points at an attribute tree. An alias whose value starts with ! runs a shell command.

Manifold's summary, quoted across the coverage, is blunt: any setting that names a program can run it. A hands-on reproduction on Windows with Git 2.55 confirmed two sinks, core.fsmonitor and filter.*.clean, and showed the payload reading an environment variable, which is the shape a credential theft would take.

The class is older than agents

This exact bug was fixed before. Claude Code 2.0.34 in November 2025 stopped running git status before trust approval; the behavior was back in 2.1.193 in June 2026. The same sink reached IDEs years earlier, under different names. CVE-2021-43891 covers a malicious .git/config executing when VS Code opened a folder, which Microsoft fixed by putting the git integration behind workspace trust in 1.63.1. CVE-2022-24346 is the JetBrains counterpart, mitigated from IntelliJ 2021.3.1.

Point fixes on startup ordering do not hold. The trust gate has to wrap every git invocation, permanently, with a regression test, or this keeps coming back.

If you build the tool

One developer who builds an IDE for reading agent-written code found his own product had the same shape: three background git calls on folder open, before you read a single line. His fix was to apply git -c core.fsmonitor=false in the single place where every git command in the product is built, plus a test with a malicious repository so it stays fixed. It shipped in a patch release about ten minutes after he went looking, which is the point: this class of bug lives in the parts of a tool nobody reads, because they "just call git."

The same week brought the rest of the wave: Plugin4Shell, where an attacker creates a branch named after the commit hash a plugin is pinned to, so an automatic update silently pulls malicious code; "Fable to Haiku," where a repository's subagent configuration delegates security review to a smaller model scoped to skip the tests folder, and the main agent then runs the suite that executes the hidden payload; and PixelLeak, where agents that could not attach screenshots to pull requests committed more than 13,000 internal screenshots from over 300 organizations to repositories instead, some of them public. Different mechanisms, one common thread: project files that everyone treated as inert.

Treat the repository an agent opens as untrusted input, including its config files. Audit before the first git status, or re-clone and never have the problem.

Sources:

The Manifold Security report itself was not opened directly. The count of eight findings across seven agents, the per-agent status table, the trigger moments and the September 2026 date are consistent across the five writeups above. The 77 million monthly npm downloads figure is FreeBuf's and I did not audit it. The CVE identifiers for Codex, goose and Hermes are as reported by those writeups; I did not open the NVD records for them. The two older IDE identifiers, CVE-2021-43891 and CVE-2022-24346, I did check, against Microsoft's advisory and the SonarSource writeup that reported them. The audit script in this post is my own, and it only reads text.

This post was written with AI assistance. The author is responsible for its content.

← All writing