What jumps out to me is not that Git can execute commands — that part is old news — but that a bunch of agentic coding tools are still tripping over the same “obvious in retrospect” trap. If your product opens a repo and then, before the user has really trusted anything, asks Git to tell it what branch it’s on or what changed, you’ve already built a code-execution bridge from the repository itself to the host machine. That feels less like a clever exploit and more like a design smell that should have been squeezed out earlier.
I also think the article’s strongest point is the boring one: this is not a model jailbreak. It’s plumbing. That matters, because people keep wanting to talk about prompt injection as if the main danger is in the text the model sees. Here the problem is lower level and more annoying. A repo arrives as files, .git/config survives, and some helper process dutifully runs whatever Git says to run. No model call is needed. No sandbox boundary inside the agent helps if the command happens before the agent even gets to the interesting part.
The bit that makes me least comfortable is how many products seem to have rediscovered this class independently. Claude Code, Codex, Cursor, goose, Qwen Code, Grok Build, Hermes Agent — that’s a lot of surface area for one pattern. Some fixes were already out, some weren’t, and the article says four were still unpatched at publication. That doesn’t surprise me so much as irritate me. There’s a difference between “hard to fully secure” and “we’re repeatedly letting repository-controlled config influence startup behavior in unsafe ways.”
I’d want to test this myself by dropping a repository as a plain directory with .git intact into the exact flows these tools use when they first inspect a workspace. Not a clone. A shared folder, archive extract, USB copy, anything that preserves the repo metadata. Because that’s the real nuance here: if your mental model is “the user cloned a repo,” you might miss the whole thing. The attack depends on the repository arriving as files, with its own config riding along.
The other uncomfortable detail is how varied the trigger points are. One tool fires before trust is granted, another before authentication, another on the first keystroke. That tells me the underlying issue isn’t a single bad helper, it’s a repeated habit of “let’s ask Git something quickly in the background.” Quick background calls are exactly where dangerous defaults hide.
If I were shipping one of these tools, I’d stop letting any repo-supplied Git config influence pre-trust startup behavior at all, full stop. Strip or neutralize it on every background invocation. The source mentions git -c core.fsmonitor=false status as one example of how vendors can blunt the issue. That seems like the right instinct: make the safe path the default, not the user’s job.
Reference: Malicious .git Configs Can Make Claude, Codex, Cursor, and Other AI Agents Run Attacker Code
