A critical security vulnerability affects seven major AI coding agents, including xAI's Grok Build, allowing attackers to execute malicious code on developers' machines through specially crafted Git configuration files. Security researchers at Manifold disclosed that these agents automatically run Git commands in the background without user approval, creating an opening for attackers to inject code that executes with full user privileges before any safety prompts appear.

Which AI Coding Agents Are Vulnerable?

The vulnerability affects a surprisingly broad range of popular development tools. Manifold confirmed the flaw in eight versions across seven different agents, with four still unpatched as of early September 2026. The affected tools include Claude Code, Cursor, Codex, Hermes Agent, Qwen Code, Grok Build, and goose. Some vendors have already released fixes, while others are still working on patches.

For Grok Build specifically, versions 0.2.93 and 1.0.13 were confirmed vulnerable, with the flaw still pending a fix at the time of Manifold's testing on September 1, 2026. The vulnerability is particularly concerning because it executes on the first keystroke after opening a repository, giving attackers an extremely narrow window to exploit before users realize something is wrong.

How Does This Attack Actually Work?

The attack exploits a legitimate Git feature called core.fsmonitor, a performance setting that tells Git which files have changed. When developers open a repository containing a malicious.git/config file, the AI agent automatically runs Git commands in the background to determine which branch is active and which files have been modified. The attacker's code executes during this routine check, outside the agent's sandbox and without any user approval prompt.

What makes this particularly dangerous is that the code runs before any of the normal safety mechanisms kick in. On Claude Code and Hermes Agent, the payload executes before the workspace-trust prompt appears. On Qwen Code, it runs before the user has even authenticated. And on Grok Build, it triggers on the very first keystroke.

"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," stated Manifold in their GitSpawn research report.

Manifold Security Research Team

The attack requires the repository to arrive as files with its.git directory intact, which happens when code is shared via archive, shared drive, sync folder, or USB stick. A normal git clone operation does not preserve the.git directory in a way that triggers this vulnerability, which is why the attack vector is somewhat limited but still significant for developers who receive code through other channels.

What Are the Real-World Implications?

If exploited, this vulnerability allows attackers to read, modify, or delete files on a developer's machine and access other resources available to that user's account. The code executes with the same privileges as the developer, meaning an attacker could potentially steal credentials, inject malicious code into projects, or compromise the entire development environment.

Notably, no active exploitation of these vulnerabilities has been reported in the wild as of early September 2026. The U.S. Cybersecurity and Infrastructure Security Agency's Known Exploited Vulnerabilities catalog contained no entries for any of these CVEs, suggesting that while the vulnerability is serious, attackers have not yet weaponized it at scale.

How to Protect Yourself From Git Config Attacks

• Inspect Before Opening: Check the.git/config file before opening any received directory with an AI agent, looking specifically for core.fsmonitor, core.hooksPath, and attr.tree settings alongside clean or process filters.
• Audit Your Repository: Run git config --get core.fsmonitor inside any repository that arrived as files rather than through a standard clone operation.
• Check Global Settings: Run git config --global --list | grep fsmonitor to audit your global Git configuration for any suspicious settings.
• Disable by Default: Set git config --global core.fsmonitor false to disable this setting globally and prevent future attacks.
• Update Your Tools: Ensure you are running the latest patched versions of your AI coding agents, particularly Claude Code 2.1.196 or later, Codex 0.131.0 or later, and goose 1.44.0 or later.

What Are Vendors Doing to Fix This?

The response from vendors has been mixed. OpenAI published three CVEs on September 2, 2026, covering the same vulnerability class in Codex, with fixes available in version 0.131.0 and later. Anthropic fixed the core.fsmonitor issue in Claude Code version 2.1.196, though researchers discovered a second vulnerable path through the claude ultrareview feature that remained unfixed as of September 1 in version 2.1.252.

Cursor and goose have both released patches. However, Hermes Agent, Qwen Code, and Grok Build still had pending fixes as of early September 2026. The recommended mitigation for vendors is straightforward: strip the Git configuration on background calls by running commands like git -c core.fsmonitor=false status, which prevents the malicious setting from being read.

Interestingly, xAI addressed a separate issue with Grok Build uploading entire Git repositories to xAI storage through a post on X rather than through a formal security advisory, highlighting inconsistent disclosure practices across the AI agent ecosystem.

Why Is This Happening Across So Many Tools?

The vulnerability stems from a common pattern in how modern AI coding agents are designed. They all need to understand the current state of a repository to provide helpful suggestions and context. This requires running Git commands automatically in the background. However, most developers did not anticipate that an attacker could weaponize Git's own configuration system to inject code execution into this routine process.

Security researchers at Sonar noted that Anthropic had already moved Claude's startup sequence once to close a similar vulnerability, but the same trust-dialog bypass pattern has appeared before in Visual Studio Code and JetBrains IDEs, suggesting this is a recurring architectural challenge in developer tools.