GitSpawn Flaws Let Malicious Repository Settings Run Commands Before AI Agent Approval

Malicious repository-local Git settings can make some AI coding agents run host commands before trust or approval. Here is what is fixed, what remains reported open, and how to handle copied repositories safely.

Reader ratingRate this article

Loading reader rating…

Privacy-conscious voting uses a signed random browser identifier and a short-lived network hash; the rating tables contain no raw IP-address column.

Reader ratings require JavaScript; the article remains fully readable without it.

Editorial illustration of a preserved Git configuration escaping an AI-agent sandbox toward a workstation warning.
Editorial illustration: GitSpawn abuses preserved repository-local Git configuration; this is not an exploit screenshot.

Security reporting cutoff: September 2, 2026, 10:35 a.m. EDT (14:35 UTC).

Material security alert

Researchers disclosed eight Git-configuration command-execution findings across seven AI coding agents. Four paths—reported in Hermes Agent, Qwen Code, Grok Build, and Claude Code’s ultrareview flow—were still unpatched when Manifold Security published and retested its work on September 1.[1] That status is a researcher report, not a public confirmation from each vendor.

The common failure happens before the AI model is the important part of the workflow: an agent asks Git for repository context, and Git honors dangerous settings preserved inside the repository’s local .git/config. The resulting helper or hook can run on the host with the developer’s privileges, outside the agent’s normal command sandbox or approval flow.[1][4][5]

An ordinary Git clone is not enough to carry the required local configuration. The published records describe risk when an attacker-prepared repository arrives with its .git/config intact—for example as a ZIP or copied folder, through a shared or synced drive, or on removable media—and the user opens it with an affected agent.[2][4][5][6]

Why developers and MSP technicians should care

A successful trigger runs with the logged-in user’s access. Depending on that account, hostile code may be able to read, alter, or delete files and reach credentials or other resources available to the user.[4][5][6][7]

That makes the delivery method more important than whether a project “looks like code.” A vendor archive, customer ZIP, copied worktree, shared-drive folder, sync-folder handoff, or USB-delivered project may preserve metadata that a normal clone would discard. For Treasure Coast businesses and technicians, the practical question is therefore: Did this repository come from a verified remote through a fresh clone, or did someone hand us a complete folder?

Immediate decision

Do not open an untrusted copied repository with an AI coding agent while its local Git configuration is still present. Quarantine the folder, inspect .git/config as plain text without invoking repository automation, and obtain a fresh clone from a verified remote when possible. This reduces the specific preserved-configuration path described in the advisories; it is not a guarantee that the repository is otherwise safe.[2][4][5]

What is confirmed fixed

OpenAI Codex CLI

OpenAI’s CNA record says Codex CLI versions 0.102.0 through 0.130.0 are affected by the core.fsmonitor path and version 0.131.0 is fixed.[5]

OpenAI Codex Desktop

OpenAI lists fixed Codex Desktop builds of 26.519.22136 for macOS, 26.519.21041 for Windows, and 26.519.2081.0 for the Microsoft Store package for the three published Codex issues.[4][5][6]

goose

The goose advisory and CVE record say versions before 1.44.0 are affected and version 1.44.0 fixes the goose review path.[3][7]

Reported open paths

Manifold reported September 1 retests still triggered in Hermes Agent 0.21.0, Qwen Code 0.22.3, Grok Build 1.0.13, and Claude Code ultrareview 2.1.252.[1] Public vendor advisories defining fixed versions for these four paths were not identified in the reviewed packet.

Hermes Agent: local relevance without overclaiming

A read-only check on The IT Guys’ local host reported Hermes Agent 0.20.5 at this article’s cutoff. Manifold reported testing the behavior on 0.18.2 and again on 0.21.0, but it did not publish a formal affected-version range.[1] Therefore, local exposure remains unconfirmed; being numerically between two tested releases is not proof that a build is vulnerable.

Manifold says VulnCheck assigned CVE-2026-71963 to the Hermes finding.[1] The public CVE API still returned HTTP 404 during our cutoff check, so we are treating that identifier as a tracking reference rather than a published affected-range record.

Safe response checklist

  1. Pause risky handoffs. Do not open repository ZIPs, copied worktrees, shared-drive folders, sync-folder projects, or removable-media projects with an AI coding agent until the local Git configuration has been reviewed.
  2. Prefer a verified fresh clone. Confirm the remote independently and clone it into a new directory. The advisories say a normal clone does not preserve the source repository’s local .git/config.[4][5][6]
  3. Inspect without invoking automation. Treat unexpected core.fsmonitor, core.hooksPath, attr.tree, and clean/process filter entries as reasons to stop and escalate. Open the configuration as text; do not test a suspicious command on a business endpoint.
  4. Patch confirmed products. Move Codex CLI to 0.131.0 or later, use the platform-specific fixed Codex Desktop build or later, and move goose to 1.44.0 or later.[3][4][5][6][7]
  5. For reportedly open paths, reduce exposure. Until a vendor fix or independent validation is available, avoid untrusted preserved repositories in Hermes Agent, Qwen Code, Grok Build, and Claude Code’s ultrareview path.[1]
  6. If unexpected execution is suspected, preserve evidence. Disconnect the affected workflow from secrets and customer data, preserve the original folder and logs, review account access from a clean system, and investigate before deleting or “cleaning” the repository.

What remains unknown

  • No reviewed source reported exploitation in the wild as of the cutoff.[2] Absence of a report is not proof that exploitation has never occurred.
  • The formal affected ranges and vendor remediation status for the reported Hermes Agent, Qwen Code, and Grok Build paths remain unresolved in the sources reviewed here.
  • The current status of Claude Code versions newer than the reported ultrareview retest on 2.1.252 was not established.
  • The local Hermes Agent 0.20.5 installation has not been reproduced against the reported path, and this article does not perform exploit testing.

Bottom line

GitSpawn is a supply-chain handoff problem hiding inside an automation convenience: the agent requests routine Git context, but the repository’s preserved local configuration can redirect that work into host-level execution. Patch Codex and goose to their documented fixed versions, quarantine copied repositories, prefer verified fresh clones, and treat the four researcher-reported open paths as a precautionary exposure until vendors or independent testing establish exact fixed ranges.

Sources

  1. Manifold Security — “GitSpawn: A Single Flaw Lets Untrusted Repos Run Code in Claude Code, Codex, Cursor, and Grok” (September 1, 2026)
  2. The Hacker News — “Malicious Git Configs Can Make Claude Code, Codex, and Other AI Agents Execute Commands” (September 2, 2026)
  3. goose security advisory GHSA-r5pp-p5r8-466r
  4. CVE-2026-19590 — OpenAI Codex Desktop core.hooksPath
  5. CVE-2026-19592 — OpenAI Codex core.fsmonitor
  6. CVE-2026-19593 — OpenAI Codex Desktop attribute/filter path
  7. CVE-2026-72718 — goose core.fsmonitor

Browse Articles

Latest Articles