GitSpawn: Your AI Coding Agent Runs Attacker Code on Repo Open

Manifold Security disclosed GitSpawn on September 1: eight security findings across seven CLI coding agents where a repository's own .git/config names a command the agent executes on the developer's machine. Four remain unpatched. The command runs before any user prompt, outside the agent sandbox, with the developer's operating-system privileges.

The mechanism is one Git setting#

Every CLI coding agent examined by Manifold does the same thing at startup: it runs git status or git diff to gather project context, before the user types anything. Git's core.fsmonitor setting names a helper program to invoke during the index refresh that underlies those commands. Git reads this setting from the repository's own .git/config.

A repository delivered as a zip, a shared-drive folder, or a USB copy can ship with .git/config intact. The chain is: agent startup, background git status, index refresh, attacker command named in core.fsmonitor, execution on the host with developer privileges. The agent's permission model never sees it, because the subprocess is spawned by the agent's own bookkeeping code, not by a model-generated tool call.

Cloning a hostile URL does not trigger this. The repository must arrive as files with its .git directory already present. That is exactly how colleagues share projects, how clients hand off code, and how contractors receive work.

Eight findings, four still unpatched#

Manifold's September 1 disclosure covers Claude Code (two separate paths), Goose, Grok Build, Qwen Code, Hermes Agent, OpenAI Codex, and Cursor. Patch status at publication:

• Claude Code core.fsmonitor path: fixed in 2.1.196.
• Claude Code ultrareview path: still unpatched at 2.1.252. The malicious command runs on startup, before the workspace-trust prompt is shown.
• Goose: fixed in 1.44.0, CVE-2026-72718, scored 7.0.
• OpenAI Codex and Cursor: patched.
• Qwen Code: unpatched at 0.22.3. Reported to Alibaba's security response center, accepted, not yet fixed. The trigger fires before authentication.
• Grok Build: unpatched at 1.0.13. An earlier report filed July 1 was closed as informative.
• Hermes Agent: unpatched at 0.21.0, CVE-2026-71963 assigned by VulnCheck after six contact attempts across five channels produced no triage from the vendor.

Five of Manifold's eight reports came back as duplicates of findings other researchers had already filed independently, one on the same day. That pattern is diagnostic. This is not one vendor's missed edge case; it is a shared architectural defect across every agent that uses Git for context gathering without sanitizing repository config.

The sandbox does not cover this#

A sandbox around model-generated tool calls is not a sandbox around every subprocess the agent spawns for its own bookkeeping. The dangerous process here is Git, which the agent invokes to understand the project, not to execute a user instruction. If the agent does not pass git -c core.fsmonitor=false on those background calls, the setting in .git/config executes freely.

This matters for how teams reason about agent risk. Approving an agent's proposed actions is not enough if arbitrary code can run during startup context gathering, before the approval interface appears. The threat surface extends to every "read-only" probe the agent performs: git helpers, formatters, language servers, hooks, and MCP servers are all relevant.

The access an attacker gets is maximally useful: SSH keys, cloud credentials stored in the environment, tokens in shell config, and every repository on the machine. Developer machines are a high-value target precisely because they carry all of this.

The dotfile is the payload#

Code review has historically focused on diffs: what changed in .py, .ts, .go files. GitSpawn reframes the question. The payload is in the dotfiles. A repository can arrive clean in every source file and still execute arbitrary commands the moment a coding agent attaches.

This has direct implications for supply-chain trust decisions. Receiving a repository as files is now a code-execution event, not a passive file-transfer event. Auditing the diff is insufficient if the .git/config was not part of the review.

Hyrax's security agent domain scans repository configuration as part of autonomous audit, which means .git/config and related dotfiles enter the finding surface before any coding agent attaches to the repository. The pattern Manifold documented, malicious executor settings in repository-local config, is exactly the class of pre-execution payload that static diff review misses and that automated repo scanning can surface.

What to check now#

Version numbers matter here. "Latest" is not a safe proxy; Claude Code 2.1.196 fixed the core.fsmonitor path but left the ultrareview path unpatched at 2.1.252. Check the exact version against the affected list.

For repositories arriving as directories rather than cloned from a trusted remote, inspect .git/config before attaching an agent. Any setting that names an executable is suspect, not just core.fsmonitor. The broader category includes core.pager and custom aliases, all of which are command-execution sinks.

Agent authors have a concrete mitigation available: pass git -c core.fsmonitor=false explicitly on every background call, and audit the full startup execution path against untrusted repository fixtures before any trust or authorization decision is made.

Hyrax is live at hyrax.dev.