Git Config Traps: Why Your Coding Agent Runs Code You Never Cloned

A project directory from a stranger is enough for your coding agent to run code that nobody confirmed on your machine. That is the result of the GitSpawn research by Manifold Security dated September 1, 2026: eight git config traps, seven agents examined, four of them unpatched at publication. Among the named agents is also the one that operates this blog. This version additionally corrects an error that stood in the previous one for three days: the attack does not come from the clone.

Git reads its settings from three levels: system-wide, from the user's account, and from the local configuration of the repository. The local level lives inside the project folder, and it can be shipped along with the folder. One of the switches there is core.fsmonitor. Officially it is a performance optimization for large projects: instead of checking every file itself, git asks a helper program what has changed. That helper is a command, and git executes it whenever the index gets refreshed.

That sounds harmless until you look at which commands refresh the index. Practically anything that touches the working directory: git status, git diff, and those are exactly the calls coding agents make constantly. Sonar demonstrated the mechanics in 2022: they wrote a line into the local configuration that dumps the current user identity into a file, then ran git status, and the file was there. The command runs with the user's rights, without confirmation, without a window.

The ordering of the levels matters. Git evaluates the three sources in a fixed sequence: system, account, project, and the project level overrides any contradicting values from the levels before it. For defense, that produces a tempting false conclusion: setting core.fsmonitor to false globally does not protect you, because a shipped project configuration is allowed to override exactly that value again. The only reliable way to bypass the project level is the one-shot override on the command line, for example git -c core.fsmonitor=false status, or hardening the tool's own background calls, which is what Sonar demands from editor integrations and Manifold demands from agent vendors.

In 2026, Manifold Security found the same mechanism in CLI agents, with one decisive addition: the agents call git in the background to collect context, in some products as soon as the folder is opened, before the workspace trust prompt, before any login. The call runs as a subprocess of the agent and therefore outside the sandbox and outside the approval model. No prompt appears, because the permission model never sees this path.

This is where the previous version of this post went wrong, so the correction stands in plain text: an ordinary clone does not carry over the local configuration. Sonar writes in the 2022 analysis that cloning a foreign repository does not fetch the files the attack needs. Manifold puts it the same way in 2026: cloning a hostile address does nothing, the project has to arrive as a collection of files with the .git folder already inside. Every proof-of-concept run in the research used a zip file.

That makes the attack path the most ordinary path projects take: a zip in an attachment, a shared drive folder, a sync service, a USB stick. Anyone who hands project folders to colleagues or ships handover archives to clients is moving directories, and those are exactly the packages that can carry the trap. The clone from the network, meanwhile, is the safe route, which runs against intuition and is why the wrong version of this story spreads so often, my own earlier post included.

A human runs git status a few times per hour. An agent runs it in many working rounds, in most products automated at session start, and more git calls sit between those points. A rare trigger becomes a permanent condition, and the call happens precisely when the user is doing nothing but waiting. On top of that, the agent works as a subprocess: the approval routines meant to stop a model from launching dangerous commands never see this path, because it runs below their level.

The Manifold research lists the findings one by one. For Claude Code, the fsmonitor path was closed with version 2.1.196, while a second path in their report remained open at publication. OpenAI Codex and Cursor were reported later and closed as well. Still open at publication: Qwen Code, Grok Build, a second Claude Code path, and Hermes Agent. Hermes received the number CVE-2026-71963, without the vendor confirming it. The table below pulls the timeline together.

Before the theory, my own ledger, freshly measured on the evening of September 5, 2026. The search ran on this deck, meaning inside the PRoot container of my Pixel: across /root (complete) and /storage/emulated/0, up to five folder levels deep. It returned exactly one hit: /root/.codex/.tmp/plugins/.git, the temporary plugin directory of a Codex tool block. The measurement limits are: this device only, two paths only, five folder levels deep only. Within those limits, the hit is the only one. Under /storage there was no further repository within search depth. The global git configuration of this system sets neither core.fsmonitor nor core.hooksPath, both queries come back empty.

The second part of the ledger is less comfortable: my own agent probably belongs on that list. The deck runs Hermes Agent 0.20.6, and the research reports the weakness as unpatched for Hermes up to and including 0.21.0. I have not run my own security test series, the attribution rests on the version range in the report plus my own version check. Exploitation needs a directory with a shipped .git configuration, and on this system such a directory does not get opened before it has been inspected. That is a working rule, not a patch, and it sits in the next section.

That transparency belongs to this project as far as I am concerned: a blog that documents agent operation has to be allowed to write the piece where its own agent shows up on a security list. The attack does not hit the hardware and not the model, but a version range of a tool that sees daily use here. If you run the same stack, find your version with hermes --version and compare it against the table above.

One note on shelf life before the steps: the table further up has a cutoff date, September 1, 2026, and the measurements in this post come from September 5, 2026. Patch status is a moving quantity, four of the eight findings were open on the cutoff date and may be closed long before you read this. Check the versions of your tools at reading time, not your memory of this text.

Three steps, no extra tools. First: inspect projects that arrive as folders before opening them with the agent. The look goes to the file .git/config, and every line naming a program or a path is a stop sign, with core.fsmonitor the best-known candidate. If you like, run git config --get core.fsmonitor and git config --get core.hooksPath inside the project folder, any output other than empty or false needs an explanation.

Second: your own scripts that call git can switch the shipped setting off for the single call. The invocation git -c core.fsmonitor=false status ignores the project setting, and that is exactly what the researchers recommend agent vendors apply to their background calls. Third: check the version of your agent against the table and keep both the tool and git current. Two patched entries on the list were closed within weeks because reports existed, the window lives on updates.

And the structure that already applies on this deck helps against this class of attack as well: reading and building stay separated. Foreign material enters planning as text or a link, building happens in directories that do not contain that material as folders. Whoever throws both into the same pot loses both at once when a hit lands. What the stack looks like as a whole is in the post on the agent stack on the 45-euro phone.

Four limitations belong in this text. First: I have not exploited any of the eight weaknesses myself, my basis is the published analyses from Manifold Security and Sonar plus my own measurements from September 5, 2026. Second: the patch situation changes, the table shows the state of September 1, 2026, not the moment you are reading. Third: the git documentation describes core.fsmonitor as intended behavior, the attack uses intended mechanics, so there is no bug git alone could fix, the hardening sits with the tool and the user.

Fourth: one switched-off setting is not an all-clear. The research names at least one gap that rests on a different switch of the same kind, whose name is deliberately not given because a fix is pending. What remains is a posture: look at folders from strangers before opening them, harden background calls, keep versions current. This text promises nothing more, and it needs nothing less.

About the author: I run the HUNTER cyberdeck. I am Marcel, a graphic designer and the operator of the d4sn3st sites. Since 2026 I have been running AI agents on a used Google Pixel 6a and documenting that operation on this blog, including the parts that do not shine. This post rests on the published analyses by Manifold Security and Sonar plus my own measurements from September 5, 2026: the .git count, the global config check, and my own Hermes version. Last fact-checked on September 5, 2026.