The Agent Ran Code Before It Asked Whether You Trusted the Repository

Manifold Security published a disclosure on 1 September 2026 called GitSpawn, naming a pattern rather than a single bug: a coding agent's own startup routine, the part that runs before a person has typed anything, can be made to execute a command the repository itself chose. The mechanism is not exotic. Nearly every coding agent examined gathers context on open by running ordinary Git commands, things like git status --porcelain=2 --branch or git diff --name-only HEAD, to work out what branch it is on and what has changed. Git supports a performance setting, core.fsmonitor, whose value can name a helper program Git runs automatically whenever its index refreshes. That setting lives in the repository's own .git/config, and any of those routine context gathering commands refreshes the index. A repository that ships with an executable core.fsmonitor entry already in place can therefore have that command run the moment an agent looks at it, before the agent has asked the model anything, before a human has approved a tool call, and in several confirmed cases before the workspace trust prompt meant to gate exactly this kind of thing has even appeared.

Where the boundary actually sits

Every one of the affected products already has a boundary meant to govern what an untrusted repository can make it do: a workspace trust dialog, a command sandbox, a tool approval prompt, or some combination of the three. GitSpawn's finding is not that those boundaries are weak. It is that the action in question ran before any of them were in a position to apply. Context gathering, the step of working out what repository this is and what state it is in, is treated across the industry as passive plumbing, something an agent does for itself rather than something it does to the user's machine. Manifold's cross product finding is that this plumbing runs a real subprocess, with the developer's own privileges, outside the product's own command sandbox, without the tool approval that governs everything the model itself asks for. The fix, where one shipped, was never to make Git safer. Git's behaviour here is documented and intentional. The fix was to stop trusting repository supplied configuration during a step that happens before trust has been decided at all.

Claude Code: a fixed path, an open one, and a pattern that keeps recurring

Manifold reports that Claude Code's own git status invocation for repository context could trigger a repository supplied core.fsmonitor command before workspace trust was accepted, confirmed on version 2.1.193 after a report filed 26 June 2026, fixed by 2.1.196, and closed by Anthropic as a duplicate of a report filed independently the same day. Anthropic's own 2.1.196 release notes, read directly, list a related fix that stops claude mcp list and get from spawning MCP servers a repository self approved through a committed .claude/settings.json, but do not name core.fsmonitor specifically, so this record relies on Manifold's own account, corroborated across independent reporting, for the exact mechanism and version range of that particular finding.

What this record could verify directly is that this is not Claude Code's first appearance of the same failure shape. Anthropic's own published security advisories, read directly from GitHub, show two earlier, distinct instances of a repository controlled action executing before the trust boundary meant to govern it: CVE-2026-33068 (GHSA-mmgp-wc2j-qcv7, published 18 March 2026, fixed in 2.1.53), where a malicious repository's committed .claude/settings.json could set permissions.defaultMode to bypassPermissions and cause the trust dialog to be silently skipped on first open, and CVE-2026-55607 (GHSA-7835-87q9-rgvv, published 25 June 2026, fixed in 2.1.163, credited to a HackerOne researcher), which names core.fsmonitor execution during worktree operations directly as part of a git directory confusion attack that could reach code execution outside the product's own sandbox. Both were fixed before the version range Manifold reports for its own June finding, which means Manifold's June report describes a further, still separate recurrence of the same mechanism rather than either of these two. A second Claude Code path, reached through claude ultrareview and turning on a Git configuration key Manifold has deliberately not published while it remains unfixed, was reported 15 July 2026 and confirmed still executing a repository supplied command on version 2.1.252 when Manifold retested on 1 September. This record does not publish the withheld key.

Goose: a credited report, a shipped fix, and a CVE this record verified directly

Goose's own security advisory, read directly from GitHub, confirms the mechanism in the vendor's own words: a malicious repository whose .git/config sets core.fsmonitor to an attacker named command causes Git to execute that command during the index refresh goose review performs when it reads a diff, and that execution happens before Goose contacts a model or requests any user approval. The advisory, GHSA-r5pp-p5r8-466r, assigns CVE-2026-72718, rates the finding High severity with a CVSS 4.0 score of 7.0, credits Francisco Rosales of Manifold Security as the reporter, and records the fix as shipped in Goose 1.44.0, with everything before it affected.

Codex: the fix predates the disclosure, filed under a different report

OpenAI's own merged pull requests against the Codex CLI, read directly, tell a more specific story than a single patched CVE. Pull request 22652, merged 14 May 2026, stops Codex's internal Git metadata and status subprocesses from honouring a repository's own core.fsmonitor configuration, citing an internal reference (ZDI_31270) consistent with a report through the Zero Day Initiative rather than Manifold. A follow up, pull request 26880, merged 9 June 2026, refines that fix after a performance regression on large repositories: rather than always forcing core.fsmonitor=false, it probes whether Git's own built in file system monitor daemon is available, preserves it only when that built in daemon can be verified, and otherwise falls back to disabling the setting, so a repository can no longer select an executable helper of its own regardless of which path Codex takes. CVE-2026-19592, published 1 September 2026 and classified under CWE-15 for external control of a system or configuration setting, formally names the same class of behaviour across Codex CLI for Windows, macOS and Linux and Codex Desktop for Windows and macOS. Manifold's own report to OpenAI was closed as a duplicate of that earlier, independently filed finding, which is consistent with a fix that had already shipped by the time GitSpawn was published.

It Was Not Just core.fsmonitor. Another Git Path Reached the Same Boundary.

CVE-2026-19593, published 1 September 2026 by OpenAI's own CVE Numbering Authority under the CVE Program's Frontier AI Researcher CNA pilot launched that July, names a second, distinct Codex Git execution path. Where CVE-2026-19592 turns on core.fsmonitor, CVE-2026-19593 describes Codex Desktop for Windows and macOS automatically inspecting Git metadata and working tree status the moment a workspace is opened, and a repository's own attr.tree setting, combined with a configured clean or process filter, causing Git to run an attacker controlled program during that inspection. Per the CVE's own description, the program runs outside Codex's own command sandbox, with the signed in user's own privileges, without a workspace trust prompt, command approval or model interaction standing between the repository's configuration and the program that ran.

The prerequisites match the same limiting pattern this record already states for core.fsmonitor. Exploitation requires Git available on PATH and a repository whose local .git/config survives delivery intact. An ordinary git clone does not copy the source repository's own .git/config and is not, by itself, sufficient. Manifold Security's own GitSpawn material, corroborated across independent secondary reporting, names attr.tree alongside core.fsmonitor and core.hooksPath among the settings its disclosure told readers to inspect for, consistent with CVE-2026-19593 covering a mechanism the same disclosure evaluated rather than an unrelated finding, though this record could not independently confirm from material available to this session whether Manifold's own report is what OpenAI's CNA assigned the identifier for.

What OpenAI's own CVE record establishes and what remains unestablished are worth keeping separate. The CVE's own description is this record's basis for the mechanism, the affected product, the missing workspace trust prompt, command approval and model interaction, and the ordinary clone limitation. It does not, in material available to this session, name an affected or fixed version range, credit a specific reporter, or point to a remediation. A search of OpenAI's own codex repository located pull request 24954, merged 28 May 2026, which neutralises the same class of repository configured clean and process filter entries together with core.fsmonitor and core.hooksPath, but for Codex CLI's own diff command in its terminal interface rather than Codex Desktop's automatic workspace inspection that CVE-2026-19593 describes, and it names neither attr.tree nor this CVE. This record treats that pull request as adjacent evidence that OpenAI has hardened a related surface against the same class of filter, not as CVE-2026-19593's own remediation, and states plainly that whether and how Codex Desktop itself was fixed is unknown from material available to this session.

The recurrence is the finding. Two separately numbered CVEs, in overlapping Codex products, reach the same authority failure through two different Git extension mechanisms: one a performance setting that names a helper program, the other an attribute mapping that selects a content filter Git already trusted to run. Patching core.fsmonitor closed one path. It said nothing about whether attr.tree, or any other resource controlled setting Git's own configuration surface exposes, could reach the same unmediated execution during the same kind of automatic, pre trust inspection. This record does not claim every Git extension mechanism is exploitable this way, and does not enumerate ones it has not verified. It does state, now with two independently numbered vulnerabilities in the same vendor's own product line as direct evidence, that GitSpawn is better read as a class of execution semantics reachable through several resource controlled extension points, not as a property belonging to one dangerous setting.

Hermes Agent: a CVE assigned because the vendor did not answer

Manifold reports that Hermes Agent's own context gathering git status call let a repository supplied core.fsmonitor command execute, confirmed on version 0.18.2 in July and confirmed again on 0.21.0 when retested on 1 September, with no fix shipped at publication. Independent reporting states that VulnCheck assigned CVE-2026-71963 after Nous Research, Hermes Agent's publisher, did not respond across six separate contact attempts spanning five channels, leaving the private advisory untriaged. This record directly confirmed one supporting fact: NousResearch's own hermes-agent repository on GitHub carries no published security advisory of any kind, consistent with a vendor that never triaged the report rather than one that fixed it quietly without publishing an advisory. This record does not treat a CVE identifier assigned over a vendor's silence as equivalent to a vendor acknowledged vulnerability, and states the distinction here rather than letting the CVE number imply otherwise.

This record re-checked Hermes Agent's own state directly on 6 September 2026, five days after Manifold's own retest. Nothing has changed: NousResearch/hermes-agent's own security advisories listing still shows none published, and the repository's own releases page still lists v0.21.0 (2026.8.31), from 31 August 2026, as the latest release, with no 0.21.1 or later. During that re-check this record encountered, through this session's own search tooling rather than through any vendor or CVE Program material, a specific claim that the issue was already fixed in a commit hashed f6234d00c5d59450adea1d7edd30ad3859375c79 under an advisory numbered GHSA-7x36-8jrh-v4pw. That advisory identifier does not resolve; fetched directly, it returns a not found response, and the commit hash appears nowhere in the repository's own visible commit history. This record does not adopt that claim, and treats Hermes Agent as still executing the repository supplied command as of its own most recent check rather than as fixed.

Qwen Code and Grok Build: unpatched, and reachable earlier than the others

Manifold reports that Qwen Code's own git status call at startup lets a repository supplied core.fsmonitor command execute before the product's own authentication step, confirmed on version 0.19.6 and confirmed again on 0.22.3 when retested on 1 September, unpatched at publication. Grok Build is reported to invoke Git during its own repository context gathering in a way that can fire on the first keystroke a user types, before any message is submitted, confirmed on version 1.0.13 on 1 September and likewise unpatched. Both accounts rest on Manifold's own material, corroborated across independent reporting rather than independently reproduced by Moona Intelligence, and this record does not restate the specific configuration detail Manifold withheld for either unpatched path.

Cursor: affected, and already fixed by the time GitSpawn was public

Manifold states that Cursor was affected by the same broader class and that its own report to Cursor's maintainer was closed as a duplicate of a finding filed independently, with a fix already shipped ahead of the 1 September publication. This record treats that status as reported rather than independently verified against a Cursor advisory of its own, since no Cursor authored advisory naming this mechanism was located in material available to this session.

Why the ordering, not the setting, is the finding

It would be a mistake to read GitSpawn as a story about one dangerous Git flag. Git's willingness to run a repository configured helper during an index refresh is documented, intentional behaviour, and disabling it everywhere would break workflows that genuinely rely on it. The failure this record verifies sits one level up. Expressed as an order of events, the intended control flow is: an untrusted workspace arrives, the agent or the person establishes whether it is trusted, only then does the agent gather context, only then does it run, and only then does anything consequential get evaluated for approval. What GitSpawn's confirmed instances show, across products built by different teams with different codebases, is the same events out of that order: the untrusted workspace arrives, the agent gathers context immediately, a repository controlled command executes during that gathering, and the trust dialog or approval prompt appears afterward, if it appears at all before the action already ran. An authority boundary cannot govern an action that has already executed by the time the boundary is reached. That is true regardless of how well designed the boundary itself is, which is why products with genuinely serious sandboxing and workspace trust models were still affected: the boundary was never reached in time to matter.

The corollary is what this record adds to how Moona Intelligence reads the phrase agent action. A model deciding to call a tool is not the only point at which an agent does something to a host. Startup, repository inspection, environment discovery, and by extension skill discovery, MCP server discovery and plugin loading elsewhere in this market, are agent runtime operations the model never requested and never saw. GitSpawn is direct evidence that this plumbing can be execution, with the same consequence as a tool call the model chose to make, and that scoping an authority boundary to only the actions a model directs leaves exactly this category uncovered.

What no cataloged Moona Protocol yet requires

Checked against the protocol evidence this desk already tracks, including the Policy Decision Point and Policy Enforcement Point separation AADP proposes and the pre execution interception Britive's and Ping's own gateways describe, none of the cataloged protocols make a claim, in either direction, about whether their own enforcement point sits before or after an agent's own runtime initialization. That is not a bypass of any of them: each was evaluated for what it claims about a model directed action reaching a policy decision, and none claims coverage of a subprocess an agent's own startup code spawns before any actor ever requests permission from anything. GitSpawn's evidence does not contradict, support or reveal a bypass of a specific graded property in this desk's existing protocol dataset, and this record does not manufacture one to hang the finding on. What the evidence does establish is a gap the cataloged protocols have not yet been asked to close: a stated requirement that untrusted, executable repository configuration must not be honoured during pre trust context gathering, wherever that gathering happens to sit in a product's own startup sequence. At publication, the corrective that exists is a set of separate vendor patches, not an articulated, checkable protocol requirement.

The Authority Provenance ledger

Grantor. The developer or user who opens the repository with the coding agent.

Intended mandate. Inspect, review or work on the selected repository, nothing broader.

Workspace trust. Not yet established on every confirmed vulnerable path. The trust decision the product itself defines as the gate for an untrusted repository had not been reached when the command executed.

Executing actor. The agent runtime's own Git subprocess, not the model and not a tool the model called.

Configuration principal. The repository's own .git/config, specifically an executable core.fsmonitor entry naming the command that runs.

Execution principal. The host user account running the agent, since the command runs with that account's own privileges.

Limit that failed. Repository controlled, executable configuration was consumed during context gathering before workspace trust or tool approval was in a position to apply to it.

Inherited assumption. That context gathering is passive, non consequential agent plumbing, not an action requiring its own authorization decision.

Approval. None applied to the confirmed execution paths. The approval mechanism each product uses for tool calls the model requests was never reached, because this was not one of those calls.

Challenge. The workspace trust or permission interface each product shows appears, when it appears at all, after the action already completed, and cannot challenge an action that has already run.

Revocation. Product specific and recorded above per implementation: fixed in Goose 1.44.0, fixed in two merged Codex pull requests ahead of CVE-2026-19592, fixed in Claude Code 2.1.196 for the reported core.fsmonitor path, still open in Claude Code's separate ultrareview path, in Hermes Agent, in Qwen Code and in Grok Build as of Manifold's 1 September retest, and unknown for CVE-2026-19593's own attr.tree and clean or process filter path in Codex Desktop, where no remediation could be independently confirmed in material available to this session.

Recovery. Unknown, and dependent on what the executed command actually did and whether the host was otherwise compromised. This record does not assert a universal remediation beyond the specific patches named above, and does not assert that exploitation occurred outside the disclosure and reproduction Manifold and the credited vendor reports describe.