Your AI coding agent trusts the repo before you do

Every AI coding agent launch this year has come with a new sandbox, a new permission model, a new "trust this folder?" dialog. The pitch is that the agent asks before it does anything risky.

GitSpawn is a reminder that the risky part often happens before the first question.

What was found

On Sept 1, 2026, Manifold Security published research on a class of flaw affecting seven coding agents: Claude Code, OpenAI Codex, Cursor, Goose, Hermes Agent, Qwen Code and Grok Build. Their finding: nearly every CLI agent quietly runs git commands such as git status or git diff at startup to gather project context.

Git has a setting, core.fsmonitor, that names a helper program to run whenever the index refreshes. If a repository's .git/config sets it, plain git status executes that program as you, with your privileges. Per Manifold, the agents did not sanitize that config, so the code ran outside any sandbox and, in some cases, before the trust prompt or authentication.

Nothing exotic here. It is a known git feature meeting an agent that assumes git commands are read-only.

The timing detail is the sharpest part. On Claude Code and Hermes Agent the payload fires before the workspace-trust prompt is accepted. On Qwen Code it fires before you authenticate. On Grok Build, on your first keystroke. The trust dialog lands after the code has already run.

That reframes the sandbox conversation. The command is spawned by git, not by the agent's tool layer, so the approval dialog, the sandbox and the policy gate are never in the path. From the agent's point of view it asked a question and got an answer. The execution happened underneath.

The catch: it doesn't work through git clone

This is the part most headlines skip. Manifold states that the repository has to arrive as files with its .git directory already inside. Cloning does not carry over a remote's config.

Their list of vectors, in their words: "a shared .zip, a shared drive, a sync folder, a USB stick."

So the realistic threat is not "someone pushed a bad repo to GitHub." It is a contractor sending a zipped project, a candidate's take-home submission, a "can you look at this?" archive from a vendor, or a synced folder. Those are exactly the cases where people skip the usual care because nobody thinks of them as cloning untrusted code.

Where the vendors stand

Manifold's table, as of Sept 1 (reported to vendors between late June and late July):

• Patched: Claude Code (fsmonitor path, v2.1.196), Cursor, OpenAI Codex (v0.131.0, CVE-2026-19592 and CVE-2026-19593), Goose (v1.44.0, CVE-2026-72718).
• Unpatched at publication: Claude Code's separate ultrareview path (v2.1.252), Hermes Agent (CVE-2026-71963), Qwen Code, Grok Build.

Manifold says Hermes got "no triage after six contacts across five channels." Five findings were duplicates of independent reports, which suggests other people found this too.

Note that Claude Code shows up twice: one path fixed, a second one not. Manifold withheld the name of the second git key while it stayed unfixed. That is the pattern to expect. Fixing one call site does not fix the class, because every new command that touches git is another place to forget the flag.

One more wrinkle: only two of the eight findings carry a CVE at all. A vulnerability process driven by CVE feeds will not see most of GitSpawn.

Anthropic has seen this shape before. Its June 2026 advisory for CVE-2026-55607 already identifies git fsmonitor execution during worktree operations. A mitigation shipped once and did not fully stick.

Why it matters for your team

Review burden and trust boundaries. Workspace-trust dialogs assume the tool does nothing until you click. If context gathering runs first, the dialog is decoration.

Blast radius. Code runs as the logged-in developer. Manifold lists SSH keys, cloud credentials, API tokens, shell config and other repos reachable from that account. On a laptop with production credentials, that is the whole company.

Governance. Most agent policies I see cover what the model may do. Few cover what the tool does at startup. Your allowlist for agent actions does not help if the exploit is in the harness, not the model.

The fix costs one flag

For vendors, Manifold suggests disabling the sink on background calls, for example git -c core.fsmonitor=false status. For you, before opening a directory that arrived as files:

git -C ./suspect-dir config --list --show-origin | grep -iE 'fsmonitor|pager|editor|sshcommand|hookspath|alias'

I wrote that grep as a starting point, not a complete list. Manifold's advice is broader: "Any setting that names a program can run it." Treat an unexpected value in any of them as a stop.

Do not treat git config --global core.fsmonitor false as the fix. Git resolves config local-over-global, so a repository's own value can beat it. Only the per-command form wins outright. Some write-ups still recommend the global setting, so test it on your own setup before relying on it.

A safer default is to delete the .git directory from archives you didn't create, or re-clone from a known remote.

Checklist

• Do not open zips, synced folders, or USB-delivered repos in an agent without inspecting .git/config first.
• Prefer a fresh git clone from a known remote over raw file copies.
• Check the version of every agent your team runs against the vendor's fix. Claude Code fsmonitor fix: 2.1.196 or later. Goose: 1.44.0 or later.
• For agents still listed as unpatched (Hermes, Qwen Code, Grok Build), do not use them on untrusted directories until a fix ships. Verify current status yourself.
• Run agents on untrusted code in a container or VM without your real credentials.
• Add "what runs at startup, before any prompt?" to your agent evaluation criteria.
• Ask vendors whether the fix covers the class (all git invocations) or just the reported path.