GitSpawn: Malicious .git/config Files Execute Code Inside AI Coding Agents Before You Act

Daniel Reyes Principal Engineer (AI/ML), YuSMP Group · AI/ML security, LLM agents, and production AI systems for US and EU teams

The short answer

How GitSpawn actually works

Git’s core.fsmonitor configuration key was introduced as a performance optimisation: instead of scanning the entire working tree on each git status, Git can delegate the check to an external filesystem watcher. The key’s value is a shell command that Git spawns directly, passing it the last-checked time and expecting a list of changed paths in return. Crucially, Git has no mechanism to validate or sandbox this command — it runs whatever string is in the config with the privileges of the calling process.

AI coding agents routinely call git status, git diff, and related commands in the background to understand the current state of a repository before generating suggestions or taking agentic actions. When such a tool opens a project folder containing a crafted .git/config, the very first background Git call triggers the fsmonitor hook, executing the attacker’s payload. The agent’s workspace-trust prompt — designed to prevent malicious workspace settings from executing code — fires after the initial Git context is gathered, not before. The payload has already run.

In the Manifold Security proof of concept, the malicious entry looked like any other performance tuning line to a casual code reviewer. The researcher confirmed the payload ran before the user acknowledged any trust dialog in every tested agent. The attack is silent: the agent does not surface an error or warning; it continues loading the workspace as if nothing happened.

How the malicious config reaches you

This is the most important detail for accurate threat assessment, and one that some secondary coverage has blurred: a normal git clone does not reproduce the vulnerability. When you clone a remote repository, Git fetches the object database and recreates the working tree, but it does not copy the remote’s .git/config to your local one. The .git/config on your machine is generated fresh by Git itself and contains only your local settings. The malicious entry never arrives.

GitSpawn requires the .git/ directory to be delivered intact, with the attacker-controlled .git/config already inside. The realistic delivery vectors are:

• ZIP archives and tarballs. When a project is shared as a compressed folder, the .git/ directory is included by default. A colleague emailing a “starter repo” ZIP, a vendor providing an integration template, or an internal wiki linking to a packaged scaffold are all viable delivery channels.
• Shared network drives and cloud storage. Copying a project folder from a shared drive preserves .git/ intact. Common in teams that use a shared NAS or cloud file sync instead of proper version control for internal tooling.
• USB or external media. Less common in modern development, but still present in air-gapped or regulated environments.

The practical implication for teams is to treat any project folder received as an archive with the same caution you would apply to an executable: verify the source, scan for unexpected .git/config entries, and consider opening untrusted folders in an isolated container environment before loading them in an AI-assisted IDE.

Which tools are affected and what is patched

Manifold Security tested seven AI coding agents and found all of them triggered the fsmonitor payload. The disclosure timeline, CVEs, and patch status as of September 3, 2026:

Manifold Security followed responsible disclosure, notifying each vendor before publication. Anthropic, Block, OpenAI, and Cursor responded and shipped patches before the public writeup. xAI, Alibaba, and the Hermes Agent maintainer did not provide a fix within the disclosure window. Manifold confirmed that a secondary execution path in Claude Code may remain open in versions up to 2.1.252 — Anthropic acknowledged this and is tracking it separately.

What it means for US & EU dev teams

The immediate message is straightforward: update your AI coding tools. But the broader implication is structural, and it matters for any team that has started running AI agents with write access to code or file systems.

AI coding assistants have been designed primarily from a productivity angle — how quickly can they gather context, how many operations can they automate, how seamlessly can they integrate into the existing developer workflow. GitSpawn exposes the security cost of that design priority. The agents that fired the fsmonitor payload did so because they were doing exactly what they are supposed to do: gather git context automatically and immediately, without bothering the developer. The trust boundary — workspace-trust — was architected to handle malicious workspace settings, not a weaponised Git hook that fires before the workspace is fully loaded.

For teams in regulated sectors, there is an additional angle. A developer machine running an AI coding assistant with access to source code, environment variables, and cloud credentials is a high-value target. An attacker who can execute code on that machine via a shared project ZIP can exfiltrate API keys, session tokens, and local credential stores silently. For organisations subject to SOC 2, ISO 27001, or the EU’s NIS2 Directive, this is not a hypothetical risk — it is a gap in the control inventory around developer endpoint security that most teams have not yet audited.

The third implication is for teams building AI agent systems, not just using them. If your product includes an agent that operates on user-provided files or repositories, the same attack surface applies to your users. An audit of how your agent handles Git operations, which hooks it respects, and what trust model governs third-party file access is a sensible precaution now, before the next variant of this class emerges. That kind of review is exactly what a penetration test focused on AI agent attack surfaces covers.

What to do right now

1. Update Claude Code to 2.1.196 or later. Run npm update -g @anthropic-ai/claude-code or the equivalent for your installation method. Monitor for a follow-up patch addressing the secondary path.
2. Update Goose to 1.44.0 or later. Check your package manager or the Goose GitHub release page for the latest build.
3. Update OpenAI Codex to 0.131.0 or later. Run npm update -g @openai/codex or update via the CLI.
4. Update Cursor. Install any August 2026 or later update from the Cursor website or in-app updater.
5. Stop using Grok Build, Qwen Code, or Hermes Agent with untrusted project folders until patches are available. If these tools are in use across your team, issue a policy notice today.
6. Audit how project folders are shared. If your team distributes starter repositories, scaffold templates, or client project archives as ZIP files, add a step to strip .git/ directories before packaging, or document that recipients must verify .git/config before opening in an AI-assisted IDE.
7. Add a Git hook check to your developer onboarding. A simple lint step that flags unexpected core.fsmonitor, core.hooksPath, or other extension points in .git/config on project open takes minutes to write and closes this class of attack for your team permanently.

Frequently asked questions

Sources

The Hacker News — Malicious Git Configs Can Make Claude Code, Cursor, and Codex Execute Arbitrary Commands
Manifold Security — AI Coding Agents Git Hijack: GitSpawn Research (Francisco Rosales)