Eight code execution findings, across seven different command line AI coding agents, and not one of the seven escaped. Manifold Security published the research on 1 September 2026 under the name GitSpawn, covering Claude Code, OpenAI Codex, Cursor, Goose, Qwen Code, Grok Build and Hermes Agent. Four of the eight findings were still unpatched on the day it went public.
The mechanism is almost disappointingly simple. Git has a setting called core.fsmonitor which points at an external program that git runs to speed up index checks. A repository carries its own configuration. When a coding agent opens a project and runs a routine command such as git status to work out what it is looking at, that configured program executes, with the full privileges of the logged in user, outside whatever sandbox the agent believes it is operating in.
The delivery route is how consultancies actually work
The detail that turns this from an interesting finding into a practical concern is how a poisoned repository has to reach you.
It cannot arrive through a normal clone, fetch or pull. Those operations never transmit a remote repository's local configuration, so the ordinary path by which developers obtain code is not the vector. That is genuinely reassuring and it is where most coverage stopped.
What does work is a project folder arriving as files with its hidden git directory intact. A zipped archive. A shared drive. A synced folder. A USB stick. A handover from a departing contractor. If you have ever built custom software for somebody else, you have received code exactly this way, probably this quarter.
We take delivery of client codebases as archives regularly, because that is how a client who is not a software company sends you their existing system. Nobody clones from a repository that was never hosted anywhere. Somebody zips the folder their previous developer left on a server and emails a download link, and the archive contains the git directory because zipping a folder includes everything in it.
The sandbox did not help, and that is the point
Most of these agents run tool calls inside some form of restricted environment, and teams have reasonably taken comfort from that.
The comfort does not apply here because the execution does not happen through the agent's tool interface. It happens inside git, which the agent invoked legitimately, as a normal subprocess of a normal operation. From the agent's perspective nothing unusual occurred. It asked git for status and git answered.
This is a useful general lesson about where trust boundaries actually sit. A sandbox constrains what the agent is permitted to do directly. It does not constrain what the programs the agent runs decide to do on its behalf, and those programs have their own configuration formats, their own extension points, and their own long history of being told what to execute by a file in the working directory.
Git is not unusual in this respect. It is unusual in being the one thing every coding agent runs first, before anybody has read a line of the code.
Read More - Ninety-Five Percent of Executives Say Roles Are Changing. Your Tools Assume They Are Not
The immediate fix, and the durable one
Three actions, in decreasing order of urgency and increasing order of effort.
Update your agents. Four findings were unpatched at disclosure and vendors have been shipping since, so the version you installed in July is not the version you want. This is the whole fix for most people and it takes a minute.
Then check how your own tooling calls git. If you have scripts, hooks or internal automation that run git commands against directories you did not create, the mitigation the researchers recommend is to neutralise the setting explicitly on those calls rather than trusting the repository. Running git with core.fsmonitor disabled for background inspection is a small change and it closes this specific route regardless of what the repository asks for.
Then decide, as a policy, what happens to an incoming archive before anyone opens it in a tool. That is the durable fix and the one that survives the next finding of this shape, because there will be one.
Treat handed over code as untrusted input
Developers are careful with untrusted data and remarkably trusting of untrusted repositories. A file uploaded by a user gets validated, scanned and quarantined. A folder from a client gets opened in an editor with an agent attached.
Our own habit until this month was to unzip the archive and start reading, with an agent already attached to the folder, because that is the fastest way to understand an unfamiliar system. That is precisely the behaviour this research targets, and it took a disclosure rather than a review for us to notice it.
The workable habit is to strip rather than to inspect. Delete the git directory from any archive you did not produce, then initialise a fresh repository if you want history tracking. You almost never need the client's git history to begin an assessment, and if you do need it, that is a deliberate decision made knowingly rather than a default.
Where you genuinely need the history, get it through a hosted remote rather than as files. Ask the client to push to a repository you can clone, which sidesteps this entire class of problem because clone does not carry local configuration. It is also better practice for a dozen unrelated reasons.
For anything you cannot avoid opening as files, open it somewhere disposable first. A container or a virtual machine with no credentials, no access to your key store and nothing mounted from your home directory. First contact with an unknown codebase is exactly the moment to be somewhere you can throw away.
Nobody audits what a tool does on startup
The wider finding here is not about git. It is that the research came from asking a question almost nobody asks: what do these agents actually do in the first second after you point them at a directory.
The answer, across seven independent products, was enough to produce eight code execution findings. That is not seven careless vendors. It is a category of software that grew extremely quickly, where startup behaviour is invisible, undocumented and identical in shape across every implementation because they all solve the same problem the same way.
The practical consequence for anyone choosing these tools is that a security question belongs in the evaluation. Not whether the vendor has a certification, but what the tool does before you ask it to do anything, and what its response was to this disclosure. Speed of patch is a better signal of a vendor's security practice than any statement on their website, and this incident produced a public, comparable answer for seven of them.
The same reasoning applies to what these tools are allowed to reach once running, which we worked through in what your agents are actually allowed to do. A capable tool with broad standing access to your environment is a large asset to anyone who finds a way to speak to it, and this month somebody did.
This belongs in your handover process
If you build software for other people, handover is now a security event in both directions, and it is worth writing down.
Code you receive gets its git directory removed and gets opened somewhere disposable. Code you send goes through a hosted remote rather than as an archive, which protects the recipient and takes less effort than zipping a folder anyway.
That is a two line addition to a document most agencies already have, and it is the kind of small procedural change that only gets made in the week a disclosure is in the news. Make it now, while somebody remembers why.
It sits alongside the other handover question worth asking, which is whether anybody can explain the code they are inheriting, covered in what happens when nobody understands the system. Our custom software development team treats an incoming codebase as untrusted input by default, because the alternative is trusting the security practices of a developer who left before we were hired.
Frequently Asked Questions
Are we affected if we only ever clone from GitHub?
Not by this route. Clone, fetch and pull do not transmit a repository's local configuration, so code obtained that way cannot carry the setting. The risk arrives with folders that come to you as files, which is a smaller but very common path.
Is updating the agent enough?
For the specific findings, largely yes, and four of the eight were unpatched at disclosure so check your version rather than assuming. It is not enough as a strategy, because the underlying pattern of a working directory configuring a tool that an agent invokes is not unique to this one setting.
How do we safely inspect an archive we cannot avoid?
Open it in a disposable container or virtual machine with no credentials mounted and no access to your key store. Remove the git directory before bringing anything onto your normal workstation. The inconvenience is measured in minutes and the alternative is code execution as your own user.
Should we stop using AI coding agents over this?
That would be a large response to a patched vulnerability class in a young category. Every one of these tools is fixable and most are fixed. The reasonable conclusion is that they belong inside your security review rather than outside it, which for many teams is the actual change.
Does this affect editors and IDEs too?
The research covered command line agents, and the underlying behaviour of running git against a working directory is not unique to them. Treat any tool that automatically inspects a folder you just opened as being in the same category until you know otherwise.
What should we ask a vendor about this?
What the tool executes before the first user instruction, whether it neutralises repository supplied configuration on background calls, and how quickly they shipped a fix for GitSpawn. The third question is answerable from public record and tells you the most.
Our clients send us zip files. How do we change that politely?
Offer to set up a repository for them and frame it as making the handover easier, which it genuinely does. Most clients have no preference about the mechanism and were only sending an archive because nobody suggested anything else.
Talk to our team if you take delivery of client codebases and have never had a policy for opening them.