On 1 September 2026, Manifold Security published GitSpawn: eight findings in seven AI coding agents where one setting in a repository’s .git/config makes the agent run attacker code as soon as you open the folder. No prompt is submitted, no tool call is approved, and in some agents the code runs before the workspace-trust dialog even appears.
The bug class is old. The trigger is new: coding agents run git in the background to understand your project, and git does what the repository’s config tells it to do.
TL;DR
- Manifold found that Claude Code, Codex, Cursor, goose, Qwen Code, Grok Build and Hermes Agent ran a command named in a repository’s core.fsmonitor setting during startup.
- The command runs as the developer, outside the agent sandbox and without an approval prompt. It can reach SSH keys, cloud credentials, tokens in the shell environment and local repositories.
- The repository has to arrive as files with its .git directory intact: a zip, a shared drive, a sync folder or a USB stick. A normal git clone is not affected.
- As of Manifold’s 1 September retest, four of the eight findings were still unpatched. No exploitation in the wild has been confirmed.
What Manifold found
Researcher Francisco Rosales tested how AI coding agents gather context when they start in a directory. Most of them run commands like git status or git diff --name-only HEAD to learn the branch and the changed files. Those commands refresh git’s index, and an index refresh can call a helper program.
That helper is configured by core.fsmonitor, a performance setting whose value is a command. If a repository’s own .git/config sets it, git runs that command. Manifold calls settings like this command execution sinks and puts the rule simply: any setting that names a program can run it. The Hacker News also lists core.hooksPath and filter drivers as related vectors.
Who is patched
Status as reported by Manifold on 1 September 2026, with CVE details from the vendor advisories quoted by The Hacker News:
| Agent | Finding | Status on 1 Sep 2026 |
|---|---|---|
| Claude Code | core.fsmonitor on startup | Fixed in 2.1.196 |
| Claude Code | Second variant (ultrareview path) | Open, retested on 2.1.252 |
| OpenAI Codex | Variant mechanism, CVE-2026-19592 | Fixed |
| Cursor | Variant mechanism | Fixed |
| goose | core.fsmonitor, CVE-2026-72718 | Fixed in 1.44.0 |
| Hermes Agent | core.fsmonitor, CVE-2026-71963 | Open |
| Qwen Code | core.fsmonitor | Open |
| Grok Build | core.fsmonitor | Open |
Versions move fast in this category. Check the current release notes of the agents your teams actually use before you rely on this table.
Anatomy of the path
shared-folder # zip, sync folder or USB, .git kept → .git/config # core.fsmonitor = attacker command → agent-startup # background git status, no prompt → developer-shell # runs as the user, outside the sandbox → dev-credentials # SSH keys, cloud creds, env tokens, repos
Two details make this path worse than it looks. First, the delivery step is ordinary. Teams pass projects around as archives, keep them in synced folders and hand them to contractors. Second, the trigger is the act of opening the folder with an agent, which developers now do many times a day.
The agent never decided to run the attacker’s code. Git did, because the repository asked it to.
Why it is an identity problem
The CVEs will get fixed agent by agent. The part that decides the damage does not change: the command runs with the developer’s identity, so it reaches whatever that identity can reach. On a typical engineering laptop that means SSH keys, cloud CLI profiles, a GitHub token, package registry tokens, LLM API keys, .env files and the tokens stored in MCP server configs.
Those are non-human identities with standing access, sitting in files that any process running as the user can read. We saw the same pattern when a compromised Nx package went looking for developer secrets. The entry point changes. The credentials on the machine stay the prize.
What to check this week
- Update the agents your developers use. Confirm Claude Code 2.1.196 or later, goose 1.44.0 or later and current Codex and Cursor releases. For Qwen Code, Grok Build and Hermes Agent, check whether a fix has shipped since 1 September.
- Do not open received repositories directly with an agent. Re-clone from the original remote, or read .git/config first and look for any setting that names a program, such as core.fsmonitor, core.hooksPath or filter drivers.
- Do not count on a global setting. A repository’s own config takes precedence over git config --global. Only a command-line override such as git -c core.fsmonitor=false status wins, which is the fix Manifold recommends to vendors.
- Inventory what a developer shell can reach. List the SSH keys, cloud profiles, GitHub and registry tokens and MCP configs on engineering machines. Replace long-lived secrets with short-lived, SSO-backed credentials where you can.
- Isolate untrusted code. Run agents on third-party or received code in a container or VM that does not mount your credentials.
- Watch for odd child processes. A git process spawning a shell or network tool during agent startup is worth an alert.
GitSpawn is one more trigger that runs as a developer. The question that outlasts the patch is what that developer’s credentials can reach. Elmoz maps that reach before an attacker does.