A poisoned .git/config runs code when Claude Code, Codex or Cursor opens a repository
Manifold Security disclosed on 2 September 2026 eight flaws across seven CLI coding agents: a repository delivered as an archive can trigger a local command on open, outside the sandbox and without approval, via Git’s core.fsmonitor setting. Disable core.fsmonitor by default and inspect .git/config before opening a received folder with an agent.
2 September 2026. Manifold Security publishes GitSpawn, eight vulnerabilities spread across seven command-line coding agents. The mechanism fits in one line: a repository’s own .git/config names a command that the agent runs on the developer’s machine. Why it matters: that command fires outside the sandbox, without an approval prompt, and merely opening a repository received as files is enough to trigger it.
A Git performance setting turned into code execution
The flaw is not in the model, nor in any exotic protocol. It abuses core.fsmonitor, a Git performance setting whose value is a command that Git runs to identify changed files. Git reads that value from the repository’s own .git/config. Any operation that refreshes the index — a git status, a git diff — executes it.
Coding agents run exactly those operations in the background, at session startup, to work out which branch they are on and which files have changed. They do so without touching the repository’s configuration — so they never neutralize the hostile command. Manifold’s phrasing is blunt: “The vulnerability is not in the model, or in anything new. It is in the ordinary plumbing underneath, the subprocess an agent spawns at session startup to work out where it is.”
The trigger point varies by agent, which makes the scenario harder to reason about. On Claude Code and Hermes Agent, the payload fires before the workspace-trust prompt is accepted; on Qwen Code, before the user has authenticated; on Grok Build, on the first keystroke.
One condition narrows the blast radius — and it is precisely what defines the realistic attack. Exploitation requires the repository to arrive as files with its .git directory intact. A normal git clone does not preserve it. A shared archive, a shared drive, a sync folder or a USB stick does. The realistic vector, then, is not cloning a public repo; it is the repository received from a third party — a recruiter’s ZIP, a colleague’s share, a vendor’s deliverable.
What is patched, and what is not
The ledger is mixed. goose (fixed in 1.44.0), Claude Code on the core.fsmonitor path (fixed in 2.1.196) and Cursor have shipped fixes. OpenAI published three CVEs the same day covering the identical class in Codex, credited to three unrelated research groups — including CVE-2026-19592, which describes a helper running “outside Codex’s command sandbox and without a user-approval prompt, allowing attacker-controlled code to run with the user’s privileges.”
Still unpatched at Manifold’s 1 September retest: Hermes Agent (confirmed on 0.18.2 and 0.21.0), Qwen Code (0.19.6 and 0.22.3), Grok Build (0.2.93 and 1.0.13), plus a second Claude Code path reached through claude ultrareview, confirmed live on version 2.1.252.
The identifiers tell part of the story. GitHub assigned CVE-2026-72718 (a CVSS 4.0 score of 7.0) to goose — the only score published across the set. VulnCheck assigned CVE-2026-71963 for Hermes Agent, but the identifier was not yet in the MITRE list as of 2 September. Most reports were closed as duplicates of other independent findings.
The real attack surface: the whole local config is suspect
core.fsmonitor is only the best-documented entry into a wider problem. A repository’s .git/config controls three other levers that also trigger local command execution: core.hooksPath, which redirects hooks to an arbitrary directory; attr.tree, which loads a hijacked attribute tree; and the clean/smudge filters, run on the way in and out of files. Any tool that trusts a received repository’s configuration inherits these levers — so Manifold’s advice to inspect those three keys is not a nicety, it is the minimum checklist.
What is really at stake is the meaning of the word “trust.” The agents’ workspace-trust prompt — the “do you trust this folder?” dialog — is supposed to be the security boundary. Yet on Claude Code and Hermes Agent, the payload fires before that dialog is accepted. On vulnerable versions the boundary is decorative: it gives the user the feeling of a control they do not yet have.
The precedent is old, which makes it worse. Sonar notes that the same trust-dialog bypass existed in Visual Studio Code before version 1.63.1 (CVE-2021-43891) and in JetBrains IDEs before 2021.3.1 (CVE-2022-24346). Five years later, the bug class is replaying inside coding agents — with one extra asset: the agent runs commands on its own, without the user typing anything at all.
A known bug, fixed once, then regressed
The striking part is that this is not an isolated discovery. Sonar reported the same sink back in April, noting that Anthropic had already moved the startup sequence once to close it. Version 2.0.34 of Claude Code, shipped 5 November 2025, stopped running git status before the trust dialog was approved — then the behavior reappeared in 2.1.193, shipped 25 June 2026. Anthropic had separately published a June advisory (CVE-2026-55607) on git fsmonitor execution during worktree operations.
That is the deeper lesson: fixing once is not enough. The bug class rests on a legitimate Git feature reused by dozens of tooling layers, and every new agent that leans on background Git commands potentially reintroduces the sink.
The timing is not incidental either. The class resurfaces just as fake recruiters are already distributing poisoned coding tests — the Nimbus Manticore campaign, documented days earlier, drops cross-platform RATs through sham job interviews. A coding agent that silently runs a received repository’s configuration turns that vector into click-free code execution, where the recruiter was hoping to at least persuade the victim to open a PDF.
# Before opening a received repository with an agent, three checks:
git config --get core.fsmonitor # the poisoned command, if present
git config --get core.hooksPath # possible hook redirection
git config --get attr.tree # a hijacked attribute tree
# Global hardening: disable core.fsmonitor by default
git config --global core.fsmonitor false
git config --global --list | grep fsmonitorVerdict
If you develop with a CLI coding agent, run git config --global core.fsmonitor false now and update your agent — goose ≥ 1.44.0, Codex ≥ 0.131.0, Cursor current, Claude Code past 2.1.196. Codex installations pinned below 0.131.0 remain exposed even though the current release is 0.152.1.
If you receive repositories from third parties — recruiter archives, vendor shares, client deliverables — treat them as untrusted code: inspect .git/config (looking for core.fsmonitor, core.hooksPath, attr.tree) before opening them in an agent, not after.
If you embed agents in your CI/CD, require the tool to neutralize configuration on background calls (the git -c core.fsmonitor=false status pattern) and audit the versions you ship. No exploitation is documented today and none of these CVEs is in CISA’s KEV catalog — but the window between proof of concept and campaign is exactly when you apply the fix, not when you wait for one.