Build1 publisher2 min readPublished
Opening an untrusted repo made seven coding agents run the program its Git config named
Manifold Security's GitSpawn findings cover eight issues across seven coding agents. The path runs through core.fsmonitor, where a background git status starts a helper the repository chose, outside the agent's sandbox and with no prompt.
The Engineer · Build desk
What happened
- Researchers at Manifold Security described a vulnerability class they call GitSpawn, covering eight related issues found across seven coding agents.
- One main path used core.fsmonitor, a legitimate Git option that can point at an external program; agents reach it by running git status or git diff in the background to read a repository.
- VS Code has shipped Workspace Trust for years, and its Restricted Mode limits tasks, debugging, workspace settings, extensions and terminals in unfamiliar code.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A prompt placed where the model asks to run a command cannot govern a process Git starts while reading a repository, so the prompt is not the control on this path.
- exposure Reviewers and maintainers who clone third-party code simply to read it are reachable before they type anything to the agent.
- decision Teams have to decide whether repository inspection itself runs inside the sandbox, because the trigger is the open.
- precedent VS Code's Restricted Mode set the bar for treating an opened folder as untrusted, and agents that index a repository on open will be judged against it.
An approval prompt sits at the point where the agent decides to run a command. `git status` clears that check on any sensible allowlist, because reading repository state is the first thing a coding agent does [4]. Git then loads its configuration, and if core.fsmonitor names an external program, Git starts that program [4]. Git is doing exactly what the configuration told it to do.
The helper is a child process of a command that was already approved. The model was never contacted [3]. According to the dev.to account of Manifold Security's findings, in vulnerable versions that child could run outside the agent's sandbox. It ran without the approval prompt a user would expect before something executes on the machine [5].
For the finding to reach a given install, the agent has to run git in the background when a folder is opened, the git it runs has to read configuration the repository supplied, and the installed build has to be one of the vulnerable ones [4][5]. The post reports background `git status` and `git diff` as routine for the seven tools it names: Claude Code, Codex, Cursor, Goose, Hermes Agent, Qwen Code and Grok Build [2][4]. It does not give version numbers or CVE identifiers [10]. Eight issues spread across seven agents means at least one of the seven carried two [8].
The broader argument in the post is about what a project directory now holds: editor settings, tasks, formatter configuration, package scripts, development containers, compiler plugins and CI configuration. Some of those point at executable programs [9]. Its author wrote that "somewhere along the way we've made opening a folder surprisingly close to executing a program" [7].
VS Code reached that conclusion years ago. Workspace Trust's Restricted Mode limits tasks, debugging, workspace settings, extensions and terminals when you open unfamiliar code [6]. The equivalent for an agent is a trust decision taken before the first background git call. Doing it that way costs something real: the appeal of these tools is that the repository is already understood by the time you type, and understanding it means running programs the repository can influence [4][9].
I would put the boundary at the process. Every process the agent spawns, and every process those spawn, runs inside the sandbox. In my view an allowlist keyed to command names cannot hold this line, because the program's path was in the repository's configuration and never on the command line [4].
What to watch
- Per-tool advisories from Manifold Security or the vendors naming fixed releases, which would let a team tell a patched install from a vulnerable one.
- Whether any of the seven agents ships a workspace-trust gate that runs before the first background git call.
- Whether the remaining issues in the class turn on other repository-supplied Git options besides core.fsmonitor.