AI × Crypto · Agent security
The Agent Opened the Folder. The Folder Opened a Shell
Eight findings across seven command-line coding agents, all turning on the same idea: a repository can name a program in its own config, and the agent runs it while getting oriented. No click, no prompt, no sandbox. Four were still unfixed when the research went out.
core.fsmonitor documentationThe security firm Manifold published research on Tuesday describing eight ways a repository sitting on your disk can make an AI coding agent execute the repository's own commands. Not a prompt injection, not a poisoned dependency, not a model being talked into something. The repository names a program in a configuration file, the agent runs a routine git command to work out what branch it is on, and Git dutifully executes the named program.
Manifold calls it GitSpawn. The findings span seven command-line agents — Claude Code, OpenAI's Codex CLI, Cursor, Qwen Code, goose, Grok Build and Hermes Agent. Four had shipped fixes by publication. Four had not.
The setting that runs a program
The mechanism is a Git performance feature called core.fsmonitor. On a very large repository, checking every file on disk for changes is slow, so Git lets you nominate a helper program that reports what changed instead. The value of the setting is a command, and Git runs it whenever it refreshes its index — which is to say, whenever you run git status or git diff.
Critically, Git reads that setting from the repository's own .git/config file. So a repository can arrive carrying its own instruction about which program to execute, and any command that touches the index carries it out.
What makes this an agent story rather than a Git story is what coding agents do in their first second of life. Nearly all of them orient themselves by shelling out to Git in the background — Manifold cites calls like git status --porcelain=2 --branch and git diff --name-only HEAD — before any user has typed anything or approved anything. The agent spawns the subprocess itself, which means the attacker's command inherits the user's privileges and runs outside whatever sandbox the agent applies to the commands it decides to run. There is no approval dialog, because from the agent's point of view nothing has been decided yet.
Manifold's summary of the consequence is blunt: "Arbitrary code execution as the developer, outside the sandbox, with no approval prompt and nothing on screen. Their SSH keys, the cloud credentials in their environment, the tokens in their shell config, every repository on disk, and a foothold on the machine."
Who is patched and who is not
Eight findings, seven agents, four still open at publication
| Agent | Reported | Status at publication |
|---|---|---|
Claude Code (core.fsmonitor) | Jun 26 | Patched in 2.1.196 |
| Claude Code (second path) | Jul 15 | Unpatched |
| Cursor | Jul 8 | Patched |
| goose | Jul 13 | Patched in 1.44.0 |
| OpenAI Codex CLI | Jul 20 | Patched |
| Qwen Code | Jul 7 | Unpatched |
| Grok Build | Jul 14 | Unpatched |
| Hermes Agent | Jul 20 | Unpatched |
The Claude Code entry is the interesting one, because it is the same bug found twice. Anthropic fixed the core.fsmonitor path, and Manifold then found a second Git setting of the same kind that a different code path — the agent's review flow — does not strip. The researchers have deliberately not named that second setting while it remains unfixed. The Hacker News reported it still unpatched as of version 2.1.258; Manifold's own retest was against 2.1.252.
That pattern — patch the one key you were told about, leave the class of keys open — is the actual finding here, and it is worth more than the individual version numbers. Git has more than one setting whose value is a command. Fixing them one CVE at a time is a losing shape.
The part most headlines skipped
Here is the qualifier that changes how alarmed anyone should be, and it did not survive the aggregation: this cannot reach you through git clone.
Git does not transmit .git/config over clone, fetch or pull. The config is local, created fresh on your machine when you clone, and a hostile repository on a public forge cannot push its settings into it. The malicious repository has to arrive as files, with a .git directory already inside — as a .zip, which is what Manifold used, or via a shared drive, a sync folder, a USB stick, or a directory a colleague handed over. heise made the same point plainly in its write-up: the standard Git workflow is not the danger; the archive someone sent you is.
That is narrower than "malicious repos run code in your agent," which is roughly how the story travelled. It is also not nothing. Zipped project handoffs are ordinary. So are code samples attached to a bug report, a contractor's deliverable, a folder restored from backup, and a repository pulled out of a sync directory that someone else can write to. The attack does not need you to be careless; it needs you to receive a project the ordinary way rather than the Git way.
Why this lands on a crypto desk
Because of what is on the machine. A developer laptop in this industry is not a general-purpose computer; it is a keyring. Deployment keys, RPC provider tokens, a hot wallet for testnet that has been reused on mainnet more often than anyone admits, cloud credentials with rights over the infrastructure that fronts a protocol, and the SSH key that signs commits to the repository everyone else trusts. Manifold's own list of what an attacker gets is exactly that inventory.
And this is the year the industry has repeatedly learned that the contract is not the weak part. The pattern in 2026's larger incidents has been keys and permissions rather than arithmetic — a privileged key, a delegated role, a signer that should not have been able to sign. GitSpawn is an unusually quiet way to be standing next to a key.
What nobody should claim, and what Manifold does not claim, is that any of this has been used against anyone. The disclosure says nothing about exploitation in the wild, and neither should we. Four unpatched code-execution paths in tools that thousands of engineers run on machines full of credentials is a serious finding on its own terms. It does not need an incident attached to it to matter.
What to actually do
The researchers' guidance splits cleanly by audience. For anyone who receives code as files: inspect .git/config before pointing an agent at the directory. Any setting whose value names a program can run that program. git config --get core.fsmonitor answers the narrow question; reading the file answers the real one. Turning it off globally — git config --global core.fsmonitor false — does not help, because the repository's own config wins.
For the people shipping the agents, Manifold's recommendation is one line of engineering and it is the only durable fix on offer: strip the config on the context-gathering calls the product makes on its own, as in git -c core.fsmonitor=false status. An agent that runs Git before the user has approved anything should be running a deliberately neutered Git.
The Take
The sandbox debate around coding agents has been about what the model decides to run. This is about what the harness runs before the model has decided anything — and that surface has had far less scrutiny, because it doesn't look like agent behaviour at all. It looks like plumbing. Four vendors have now shipped fixes for the one Git key they were handed, and at least one of them was found to have a second one open in a different code path a few weeks later, which tells you the class was never audited, only the instance. The right question for every agent vendor this week isn't "did you patch fsmonitor." It's "enumerate every command your product runs before the trust prompt, and tell us which ones read config you don't control." Nobody has published that list. Until someone does, the honest status for the four still-open findings is not "low severity" — it's "unknown, and unmeasured."