A Repository Can Tell Your Coding Agent What to Execute

What the attack is

Git has a performance setting called core.fsmonitor. It names a command that Git runs to work out which files changed. The command lives in the repository's own .git/config.

So a repository can specify a command, and an AI coding agent that runs git status in that directory will execute it. Manifold Security's description: "A repository's own Git configuration names a command that the agent runs on the developer's machine" - with no sandbox and no approval prompt.

Two other directives work the same way: core.hooksPath and attr.tree.

The one condition that limits it

The malicious repository has to arrive with its .git directory intact. A normal git clone does not carry the attacker's config, so this is not a drive-by.

It arrives instead through shared archives, network drives, sync folders and USB sticks - a zipped repo from a client, a folder on a shared drive, a project someone dropped in Dropbox. Which is exactly how contract and agency work moves.

Who is affected, and who has actually fixed it

The Claude Code detail worth reading twice

Claude Code patched the core.fsmonitor path in 2.1.196. A second path, through "claude ultrareview", was confirmed still live in 2.1.258.

So "Claude Code is patched" is half true, and updating to the latest version does not close it. That is the single most useful fact in this disclosure and it is buried in most coverage.

The CVEs

• CVE-2026-19592 - OpenAI Codex. OpenAI separately disclosed three CVEs in this vulnerability class.
• CVE-2026-72718 - goose, CVSS 4.0 base score 7.0.
• CVE-2026-71963 - Hermes Agent, assigned by VulnCheck.

Four weeks on, the vendor responses tell you something

Manifold published on 1 September. Since then:

• Hermes Agent - six contact attempts, advisory still untriaged
• Qwen Code - report accepted 7 July, no release
• Grok Build - closed as informative, addressed on social media only

Qwen Code accepted the report in July and has shipped nothing in over two months. Grok Build closed it as informative. If you are choosing a coding agent, how a vendor handles a disclosure is a better signal than a benchmark score.

What to do today

Before you open any repository you did not clone yourself:

# Check what a received repo is asking your agent to run
git config --get core.fsmonitor
git config --get core.hooksPath
git config --get attr.tree

# Turn it off globally - safest default for most people
git config --global core.fsmonitor false

# Vendors should be running status like this
git -c core.fsmonitor=false status

Manifold's advice is to inspect .git/config for those three directives before pointing an agent at a directory someone sent you.

Perspective

There is no documented real-world exploitation, and none of these CVEs appear in CISA's Known Exploited Vulnerabilities catalog. This is a disclosed class, not an active campaign.

What makes it worth your attention is the shape rather than the severity. The agent did nothing wrong - it ran git status, which is what it is for. The trust boundary everyone assumed was around the code turned out to be around the configuration too. That is the same lesson as the OpenAI DNS escape this month: the containment failure was in a mechanism nobody thought of as an attack surface.

FAQ

Am I vulnerable if I only clone from GitHub?

Largely no. A normal clone does not bring the attacker's .git/config. The risk is repositories received as archives, on shared drives, in sync folders or on USB.

Is Claude Code fixed?

Partly. The core.fsmonitor path was patched in 2.1.196; a second path was confirmed live in 2.1.258. Updating alone does not close it.

Which agents are still unpatched?

As of the disclosure timeline: Hermes Agent, Qwen Code and Grok Build.

What is the one-line fix?

git config --global core.fsmonitor false - and check core.hooksPath and attr.tree on anything you receive.