A Malicious Git Config Can Hijack Your AI Coding Agent

Your AI coding agent runs git commands you never see. Open a folder and it quietly calls `git status` or `git diff` to understand the project before you type a word. On September 1, Manifold Security disclosed a class of vulnerabilities it calls GitSpawn that turns that habit against you: a repository's own `.git/config` file can set git's `core.fsmonitor` option to an arbitrary command, and git will execute that command whenever it refreshes its index. The result, in Manifold's words: "Arbitrary code execution as the developer, outside the sandbox, with no approval prompt and nothing on screen."

Manifold documented eight findings across seven agents: Claude Code, OpenAI's Codex, Cursor, goose, Qwen Code, Grok Build and Hermes Agent. The Hacker News corroborated the research on September 2. As of September 3, four of the eight findings show no evidence of a fix. No exploitation in the wild has been documented so far, though absence of reports is not proof of absence.

Anyone who followed August's npm worm, which hid in agent hook systems, will recognize the shape of this. In both cases, agents auto-execute configuration that developers never review, and they do it before their own trust prompts fire.

Git runs whatever `core.fsmonitor` names

`core.fsmonitor` is a legitimate git performance feature. Per the official git documentation, the setting can hold "the pathname of the 'fsmonitor' hook command", a helper git invokes to learn which files changed, so that commands like `git status` run faster on huge repositories. Git executes whatever that setting names, and the setting can live in the repository's own local config.

Git itself is behaving exactly as documented here, and Manifold is explicit that this "exploits a legitimate feature, not a bug." The agent-side mistake, as OpenAI's CVE-2026-19592 record puts it for Codex, is collecting git metadata "without disabling the repository-local core.fsmonitor setting", so the helper runs outside the sandbox, without an approval prompt, with the user's privileges.

According to Manifold, Claude Code ran its first `git status` before the workspace-trust prompt appeared. Qwen Code executed the payload on start-up before the user had even authenticated. Grok Build fired on the first keystroke, before any message was sent. goose's case, per its GitHub advisory, involved "no submitted prompt, no model call, no tool approval, no trust prompt." Trust dialogs exist in most of these tools; the context-gathering git calls simply ran first.

A fresh clone can't carry the payload

A fresh `git clone` is safe. Cloning does not carry over the source repository's local config, a point both Manifold and the Codex CVE record make explicitly. In Manifold's words: "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, so the vector is anything that moves a directory instead of cloning it: a shared `.zip`, a shared drive, a sync folder, a USB stick."

In practice, the dangerous object is the zipped "take a look at this project" folder, the repo on a team shared drive, the synced directory, the take-home assignment. If it arrived with a `.git` folder inside and you did not clone it yourself, its config is untrusted executable input.

Four of the eight findings are still open

Status as of September 3, 2026. This table ages quickly; check your vendor's latest release.

The disclosure log behind that table shows how differently vendors handled the same report. OpenAI had already fixed it before Manifold's report arrived (its fix merged in May; Manifold's July report came back as a duplicate). Anthropic fixed the main path in three days but the second finding, reported July 15, remained open at publication. And Hermes Agent, per Manifold, never triaged the private advisory after "six contact attempts across five channels"; the CVE Manifold cites for it (CVE-2026-71963) was assigned by VulnCheck, a third-party numbering authority, and does not yet appear in MITRE's registry.

Git's fsmonitor has also surfaced in an Anthropic advisory before. The company's June advisory for a different flaw (CVE-2026-55607, a sandbox escape via git worktree path confusion, fixed in 2.1.163) already had git's fsmonitor execution in its mechanism chain. GitSpawn is not that bug, but the ingredient list overlaps.

Repo-local config beats your global settings

Some coverage suggests disabling the feature globally with `git config --global core.fsmonitor false`. That advice fails, because git's repository-local config overrides global config: the attacker's setting in the copied repo wins. TechCurrent verified this locally against git 2.51.0, and it matches git's documented scope precedence. The fix that actually holds is the one Manifold gives vendors: strip the setting per invocation, as in `git -c core.fsmonitor=false status`, because a command-line `-c` overrides every config file.

What to check before opening a copied repo

- Clone, don't copy. If a project reaches you as a ZIP, shared-drive folder, sync folder or USB copy with `.git` inside, treat it as untrusted. - Before opening a copied repo with any agent, inspect from a plain shell: `git config --get core.fsmonitor`, and read `.git/config` generally. Per Manifold, "Any setting that names a program can run it"; The Hacker News also points at `core.hooksPath` and filter settings. - Deleting the `.git` directory from a copied project before opening it removes the repo-local config entirely (TechCurrent guidance, following from the mechanism as publicly described). - Update now: Codex CLI 0.131.0 or later, goose 1.44.0 or later, Claude Code 2.1.196 or later, current Cursor. - Until fixes ship: avoid opening untrusted or copied repos with Hermes Agent, Qwen Code or Grok Build, and avoid running `/ultrareview` inside repos you did not clone yourself (status as of September 3).

None of the four vendors with open findings had publicly responded to the September 1 disclosure as of September 3. We will update our coverage when they do, and when the remaining fixes land.

“Cloning a hostile URL does nothing. The repository has to arrive as files with its .git directory already inside.”

Reporting by TechCurrent Staff · TechCurrent