AI code assistants can be hijacked by a malicious .git/config entry that exploits Git’s core.fsmonitor feature, allowing an untrusted repository to run commands on a developer’s machine the instant the assistant scans the files.

The flaw surfaced in several popular agents—Claude Code, Cursor, OpenAI Codex, Goose, Qwen Code, Grok Build and Hermes. In the patched agents the exploit no longer works; the others remain vulnerable. No extra clicks or prompts are needed, and the malicious code runs with the user’s own privileges, outside any sandbox the AI agent may provide.

How the attack reaches a developer

  • A contractor zips a project and emails it.
  • A teammate shares a folder on a network drive.
  • A USB stick is handed over with a codebase.

In each case the repository arrives as a directory that already contains a .git folder. When an AI assistant opens the folder it typically runs git status in the background to build a view of the code. Git speeds up that operation with the core.fsmonitor setting, which tells Git to call an external program to watch the file system for changes. If the repository’s .git/config file defines a malicious command for core.fsmonitor, Git executes it automatically, without consulting the user.

Because the command is launched by Git itself, it inherits the user’s rights and bypasses any sandbox the AI tool may have set up. The exploit does not fire during a normal git clone, git fetch or git pull; it only activates when the repository is unpacked with its .git metadata already present.

Why the issue matters

Developers increasingly rely on AI assistants to suggest completions, refactor code, or generate entire modules. Those tools need a quick snapshot of the project’s file tree, so they invoke Git commands silently. If a malicious repository can execute code at that moment, an attacker gains a foothold on the developer’s workstation without any visible warning. The potential payload ranges from credential theft to installing persistent backdoors, all while the user believes they are merely “checking” the code with an AI helper.

Detecting a poisoned repo

Before handing a repository to an assistant, run:

git config --get core.fsmonitor

A non-empty output means a program is set to run automatically. For a broader sweep, list any suspicious Git settings:

git config --local --list | grep -Ei 'fsmonitor|hooksPath|sshCommand|pager|editor|filter\.'

If you spot entries you didn’t add, clear them with:

git config --local --unset core.fsmonitor

Note that setting git config --global core.fsmonitor false does not protect you. Local repository settings always override global ones, so a malicious repo can simply ignore a global rule.

Current patch landscape

  • Claude Code – patched (fsmonitor)
  • Cursor – patched
  • OpenAI Codex – patched
  • Goose – patched
  • Qwen Code – unpatched
  • Grok Build – unpatched
  • Hermes – unpatched

Developers using the unpatched agents should treat any incoming repository as potentially dangerous until they either switch tools or enforce stricter local Git policies.

Counter-point from the Git community

Git’s core.fsmonitor is a legitimate performance feature, not a bug. The maintainers argue that the responsibility lies with callers to validate repository contents before invoking Git commands. Disabling the feature globally is a straightforward mitigation, but as noted, local overrides can subvert that protection. The broader discussion now centers on whether AI assistants should sandbox all external Git invocations or refuse to process repositories that contain custom fsmonitor hooks.

What to watch next

  • Updates from the unpatched AI agents—especially any statements about sandboxing Git calls.
  • Potential changes in Git’s default handling of core.fsmonitor for untrusted directories.
  • Third-party tools that can sanitize a repository’s .git/config before it reaches an assistant.

Takeaway

A single line in a hidden config file can turn an AI-powered convenience into a remote-code-execution vector. Until the vulnerable agents are fixed, the safest practice is to audit every repository that arrives outside of a standard clone workflow and strip any core.fsmonitor or similar hooks before letting an AI assistant touch the code.