Validated Research Published: Sep 13, 2026

GitSpawn Runs From a Repository Before the Coding Agent Can Ask for Trust

Manifold Security reported eight GitSpawn findings across seven AI coding agents. A transferred repository with its local Git configuration intact can make Git execute a configured command during status, diff, or background context collection before the agent's trust prompt; the research did not report malicious real-world compromise, and a normal clone does not preserve this local configuration.

Configuration PoisoningLocal Agent TakeoverConfiguration ReviewSystem-Level DefenseAI Coding Agent
1 applicable AIDEFEND defenses
Source: GitSpawn: How Malicious Git Configs Hijack AI Coding Agents 
Author: Manifold Security
Original article: Sep 1, 2026

Threat Analysis

  • The delivery condition matters. GitSpawn depends on a repository transfer that preserves the .git directory and its local configuration, such as an archive or shared workspace. A normal clone does not carry the local configuration described by the research.
  • Git becomes the execution boundary. The coding agent asks Git for status, diff, or background context, and Git reads the repository-local core.fsmonitor setting. The configured command can run as the current user.
  • The trust prompt is too late for this path. Manifold reports that the command can execute before the coding agent's visible trust decision and outside its sandbox, so a user approval screen after activation cannot undo the earlier execution.
  • The impact must stay bounded. The source establishes pre-trust code execution in the tested agent path. It does not establish a particular payload, persistence, organization compromise, or universal behavior across every Git client.

Applicable AIDEFEND Defenses (1)

AID-H-021.005
AI Coding-Agent Workspace Activation Trust Gate
Very High
Before activating a new or changed workspace, inspect .git/config and other command-bearing settings without executing them, show the complete activation manifest, and keep Git context collection restricted until an exact trust decision is bound to that manifest.

What Defenders Should Do Now

  • Before an AI coding agent activates a new, cloned, moved, or changed workspace, inspect .git/config, hooks, folder tasks, devcontainer or bootstrap files, MCP commands, and local rules without executing them.
  • Present a complete activation manifest that names every workspace-controlled behavior capable of starting a process or changing agent permissions. Bind the user's decision to that exact manifest and workspace identity.
  • Keep Git status, diff, fsmonitor, and background context collection in restricted mode until the activation broker issues activation-only authority. Revoke that authority when the workspace or manifest changes.
  • As a regression test, deliver repositories through archive and shared-folder paths that preserve .git, then verify that no configured command runs before trust and that the command is not executed outside the intended sandbox.

1 additional consideration

Deployment scope

The research reports behavior across seven coding agents, but the exact affected-version and remediation status differs by product. The finding should not be treated as proof that every Git integration has the same trigger path.
Recommendation: Test each deployed coding agent with an intact .git/config in an isolated workspace, and verify that every Git status, diff, fsmonitor, and background path remains behind the workspace trust gate.

Conclusion

GitSpawn is a workspace activation problem, not merely a malicious repository problem. A visible trust prompt is useful only if Git and background context collection are still restricted before that decision. AIDEFEND 's AI Coding-Agent Workspace Activation Trust Gate gives the owner a concrete control: inspect the workspace without execution, bind approval to the complete manifest, and test every protected activation path.