Eight ways a handed-over folder runs code in your AI coding agent, and the precondition every headline dropped

Manifold Security published eight findings this week across seven command line AI coding agents. In each of them a repository supplies a git setting that names a program, the agent runs git in the background to work out what it is looking at, and the program runs.

No prompt is typed. No approval is clicked. In several cases it happens before the workspace trust dialogue appears at all.

The headline everywhere is that malicious repositories execute code in Claude Code, Codex, Cursor and Grok. The research says something narrower and more useful, and the narrower version is the one you can act on.

The precondition the coverage dropped

In Manifold's own words: "git never carries this. Cloning a hostile URL does nothing, and neither does fetch or pull."

The repository has to arrive as files, with its .git directory already inside. A zip. A shared drive. A synced folder. A USB stick. As they put it, colleagues pass projects around this way and consultants hand them to clients.

That is not a small caveat. It removes the entire drive-by case, which is what "malicious repositories execute code" implies to a reader who does not open the paper. It also tells you exactly which of your habits is the exposure, and for most teams it is the one nobody has a policy for.

Where the command runs, and where the prompt is

The setting

core.fsmonitor is a performance option for large repositories. Rather than checking every file on disk, git asks a helper program what changed, and runs that program during an index refresh. A repository can carry it in its own .git/config:

[core]
    fsmonitor = <command>

Nearly every agent examined gathers project context by running things like git status --porcelain=2 --branch or git diff --name-only HEAD. Those calls refresh the index. The index refresh reads the repository's config. The config names a command, and git runs it, on the host, with the user's privileges, outside whatever sandbox the agent maintains for the commands it decides to run itself.

The fix is one flag. Manifold's recommendation to vendors is to sanitise the config on background calls, for example git -c core.fsmonitor=false status.

What is patched and what is not

Eight findings, seven agents, four still open

Agent	Reported	Status
Claude Code, core.fsmonitor	26 June	Patched in 2.1.196. Closed as a duplicate of a same-day report
Cursor	8 July	Patched. Closed as a duplicate of an earlier report
Qwen Code	7 July	Unpatched at 0.22.3. Accepted by Alibaba SRC
Goose	13 July	Patched in 1.44.0. CVE-2026-72718
Grok Build	14 July	Unpatched at 1.0.13. Closed as informative, duplicate of a 1 July report
Claude Code, review path	15 July	Unpatched at 2.1.252. Closed as a duplicate of an internal ticket
Hermes Agent	20 July	Unpatched at 0.21.0. CVE-2026-71963. No triage after six contacts
OpenAI Codex	20 July	Patched. Closed as a duplicate of an earlier report

Two things in that table deserve more attention than the count.

The first is the second Claude Code finding. It is not core.fsmonitor. It is a different git setting of the same kind, on the review path, and Manifold has deliberately left it unnamed while it remains unpatched. That is a researcher choosing to be less quotable in order to be less useful to somebody else, and after a fortnight of single-source claims arriving with their caveats stripped, it is worth saying plainly.

The second is the duplicate column. Five of eight were closed as duplicates of reports that arrived independently, several within days. That is the more interesting result. It is not eight mistakes. It is one design decision, adopted across an industry inside a year, producing the same hole in seven products at once, and being found by several people simultaneously because it is what happens when an agent shells out to git.

What to actually do

The position

There is a version of this story where AI coding agents are reckless and this is the proof. That version does not survive contact with the research.

Reading a repository's git config is what git does. Running git status to understand a project is what a sensible tool does. The mistake is in the ordering, and the ordering was inherited: every one of these products decided independently that gathering context is cheap, safe and worth doing before the user has said anything, because for a human developer at a terminal it always was.

What changed is that the thing gathering context is now a program that starts on its own, in a directory the user has not looked at, at the moment the folder is opened. That is a different threat model wearing the same commands, and the trust prompt that everybody built stayed where it was.

The narrow lesson is a config check before you open somebody else's folder. The wider one is that when a tool starts doing a familiar thing autonomously, the controls around it are usually still positioned for the old cadence.