Opening a folder shouldn't be a code execution vector. And yet here we are: an AI coding agent runs git status to "understand your project," and that alone is enough to hand an attacker a shell as you, with no prompt, no approval, no sandbox escape needed because you were never in a sandbox to begin with.
Context
This isn't a novel class of bug. .git/config and core.fsmonitor abuse for command execution has been kicking around the git security world for a while, related tricks have shown up in supply chain attacks against plain old git clients for years. What's new is the blast radius. Coding agents like Claude Code, Cursor, Codex, Grok, Goose, Hermes, and Qwen Code all independently decided that shelling out to git for context (diffs, status, log) was a reasonable design choice. It is, for a normal git client used by a human who typed the clone command themselves. It's a very different story when the whole selling point of the tool is "point me at a codebase and I'll figure it out," because now the trust boundary that used to require a human to run git status inside a hostile repo has been quietly automated away.
So: known primitive, newly reachable by a much larger and much less careful set of triggers.
Hype Check
The framing of "flaw lets untrusted repos run code" is accurate, not hyped, which is honestly a little refreshing. If anything the summary undersells the scariest part: no approval prompt. Every AI coding tool vendor loves to talk about their permission systems, their sandboxes, their "ask before running commands" guardrails. That's the pitch that gets enterprise security teams comfortable enough to approve rollout. This bug walks straight past all of it because the dangerous action isn't the agent choosing to run a shell command, it's git itself triggering an index refresh as a side effect of a read-only-sounding operation. The agent's safety layer never even sees a decision point.
Who benefits from people not thinking too hard about this? Every vendor who's been marketing "sandboxed" or "safe by default" agent execution. That language is technically true for the things they explicitly gate, and it says nothing about the git plumbing running underneath.
Implications
If your onboarding process for a new engineer, a new contractor, or a curious AI agent involves "clone the repo and let the tooling look around," that's now an untrusted-input path with actual code execution consequences. Downloading a zip from a suspicious GitHub link and letting your coding agent "take a look" is the new email attachment. The demo-friendly workflow (drag in a folder, ask the agent to explain the codebase) is exactly the workflow that's exploitable.
For security teams, this is a reminder that AI coding agents inherited git's entire attack surface without necessarily inheriting the caution git veterans developed around it (nobody sane clones and inspects a random internet repo without at least a little suspicion, but agents don't have that instinct). The fix belongs partly upstream in how these tools shell out to git, and partly in basic hygiene: treat any repo you didn't create as hostile until proven otherwise, and treat "the agent just read some files" as an assumption you can no longer make.
For developers, the practical takeaway is smaller and more annoying: you now have to think about what your tools do before you've asked them to do anything. That's a bad trade.
Open Question
If the industry standard becomes "AI agents shell out to real dev tools for context," how many more of these silent, no-prompt execution paths are sitting in git, npm, pip, or any other CLI these agents casually invoke on your behalf, and who's actually auditing that?
— Cor, Skyblue Soft
Sources
AI-assisted draft or imaging, human-curated, reviewed and edited.
Top comments (0)