Opening the Project Is Enough: Eight AI Coding Agents Ran an Attacker Command Without Asking

Opening the Project Is Enough: Eight AI Coding Agents Ran an Attacker Command Without Asking

We are used to reading about AI in cybersecurity from one angle: an attacker wielding agents to move faster. The second angle matters more to your organisation and gets far less attention. The agent you run on your own developer machine is itself a new attack surface. Over two months, three independent research groups published findings that all point the same way.

What these cases share is not a flaw in the model or a bad answer. The agent never broke out of its sandbox and never violated a rule. What happened is that the agent read or wrote a file inside the project, and then a trusted tool running outside the sandbox executed the contents of that file. The sandbox held. The compromise went around it.

The mechanism: a years-old Git performance setting

The clearest example was published by Manifold Security on 2 September 2026 under the name GitSpawn. It turns on a per-project Git setting called core.fsmonitor, a legitimate and documented performance option whose value is a command Git runs to identify changed files quickly instead of scanning the whole directory.

Now put the two halves together:

• An AI coding agent, when it starts work on a project, automatically runs Git commands such as git status and git diff to understand the state of the repository. This is normal and necessary behaviour.
• If the repository carries a malicious core.fsmonitor value, simply running those commands runs the attacker command.

The result is that opening a code repository stops being a read event and becomes an execution event. No click, no approval, no prompt shown to the developer. According to the report, eight command-line agents were exposed, and patches followed for several: goose in 1.44.0, Claude Code in 2.1.196 for the core.fsmonitor path, Codex CLI in 0.131.0, plus Cursor. The report noted four paths still unpatched at publication. The class was tracked under identifiers including CVE-2026-72718, CVE-2026-19592 and CVE-2026-55607.

Not one incident but a whole class

Six weeks before GitSpawn, researchers at Pillar Security published a series they called a week of sandbox escapes on 20 July 2026, documenting seven vulnerabilities across four coding agents from three vendors: Cursor, Codex, Gemini CLI and Antigravity. Their description of the mechanism is worth reading twice. The agent stays inside the box and follows every rule. It just writes a file that a trusted tool outside the box later runs, loads or scans.

• In Cursor, a workspace-controlled hook configuration file enabled execution outside the sandbox, tracked as CVE-2026-48124 and fixed in version 3.0.0.
• In Codex CLI, the command allowlist trusted git show by name alone, even though the parameters passed to it can make it more than read-only. Fixed in version 0.95.0.
• A Docker socket issue affected Codex, Cursor and Gemini CLI at the same time.
• In Antigravity, a macOS Seatbelt denylist bypass and an editor task-configuration issue, both of which Google classified as difficult to exploit.

Then on 10 September 2026, Upstarts Media reported a third disclosure, from a startup called Accomplish, covering leaky sandboxes in Claude Code, Codex and Cursor. The interesting number there is not the vulnerability but the time to fix: the Cursor issue was resolved in roughly a week, two OpenAI issues in August, while the Anthropic issue took around fifty days across dozens of releases. Three research groups, three reports, two months, one pattern.

Why this matters if you never write code

Because the risk does not land on the agent. It lands on the machine running it and the network that machine sits on. A developer workstation is one of the most privileged devices in any company: it holds server access keys, deployment tokens, and often an open connection to a production database. Executing one command on it is not a small event.

The scenario is not theoretical in the Saudi market. Check these cases against your own company:

• An outside contractor or development agency delivers code that your team then opens with an AI agent on a machine inside your network.
• An open-source project a developer pulls down to try a library or a quick fix.
• A file sent by email or WhatsApp from a supplier, unzipped and opened straight in the editor.
• A job candidate submitting a sample project that a technical reviewer opens.
• An old branch or a transferred repository handed over during an acquisition or a project handoff.

In every one of these, the unspoken assumption is that opening files to read them is a safe act. That assumption is what broke.

What to do this week

Five steps, and the first needs no budget:

1. Update agent tooling across the whole team today. Patches exist for most of these tools, and the value is in everyone being on a patched version rather than one person. Start by knowing who runs what and at which version, because that inventory itself is usually missing.
2. Treat incoming code as untrusted content. Code from a contractor or an open source is not a document you read, it is something that executes. Open it the first time on a machine or container separated from the work network.
3. Separate the development machine from production keys. Do not keep live server tokens on the machine where externally sourced projects get opened. The loss then stays within that device.
4. Route deployment through a central pipeline, not a personal laptop. When deployment passes through one build pipeline with scoped permissions, compromising a single machine stops being a path to production.
5. Add a clause to outsourced development contracts. You are entitled to specify how code is delivered and from which repository, and to require the vendor to keep its tooling updated. This is a contract term, not a technical debate.

Locally, none of this is optional good practice. The Essential Cybersecurity Controls issued by the National Cybersecurity Authority include explicit domains for endpoint security, change and development management security, and third-party security, while responsibility for personal data protection stays with the organisation under the Personal Data Protection Law. If the door opened through a developer machine that opened a vendor project, that does not reduce the liability.

The Origami view

We read these three reports as a correction to an idea that spread quickly: that a sandbox is enough as long as the agent is locked inside it. These vulnerabilities did not break the isolation. They used a legitimate bridge that carries something written inside the box to a tool running outside it. Which means the right question is not whether the agent is sandboxed, but which tools read what the agent produces, and with what privileges those tools run.

A practical observation from what we see at clients: adoption of AI tooling inside development teams runs months ahead of any policy governing it. A developer tries a tool, likes it, and it becomes part of the daily workflow with no decision, no review and no inventory. The problem is not the tool. The problem is that it entered through a door nobody watches. When we review client environments we start exactly here: which tools actually run on team machines, with what privileges, and what happens if one command executes on one of them tonight. If you want a review from that angle, you will find us on the contact page.

The bottom line

Three independent disclosures in two months say the same thing: an AI coding agent turns opening a project from a read into an execution, and all it takes is an outside party placing one line in a config file. Patches shipped for most tools and some paths remained open, but the lesson outlives any release. Any tool you run on a highly privileged machine is part of your attack surface, whether or not your policies list it. Start with one question: who on your team is running an AI agent right now, on which machine, and at which version?

Sources

• The Hacker News — Malicious .git Configs Can Make Claude, Codex, Cursor and Other AI Agents Run Attacker Code, 2 September 2026: the Manifold Security GitSpawn disclosure, the core.fsmonitor mechanism, the list of eight agents, patch versions and identifiers CVE-2026-72718, CVE-2026-19592 and CVE-2026-55607.
• BleepingComputer — Cursor, Codex, Gemini CLI, Antigravity hit by sandbox escapes: the Pillar Security series published 20 July 2026, seven vulnerabilities across four agents, CVE-2026-48124 and the 3.0.0 and 0.95.0 fixes.
• Upstarts Media — Claude Code, Codex and Cursor Have Leaky Sandbox Problems, 10 September 2026: the Accomplish disclosure and time-to-fix across the three vendors.
• National Cybersecurity Authority — Essential Cybersecurity Controls, and Saudi Data and AI Authority — Personal Data Protection Law.