Three researchers spent months not attacking the sandbox
Eilon Cohen, Dan Lisichkin and Ariel Fogel of Pillar Security asked a narrow question about the sandboxes that ship with AI coding agents. Not whether the walls hold, but whether the walls stand in the right place. On 20 July 2026 they began publishing the answer as a series they call the Week of Sandbox Escapes, one write-up a day, covering Cursor, the OpenAI Codex CLI, the Google Gemini CLI and Google Antigravity.
In every case the agent behaved. It stayed inside the workspace it was given and it broke no rule the sandbox enforces. It wrote a file. A process outside the sandbox then read that file, trusted it, and ran what it said. The escape happened without the agent ever touching the boundary.
Pillar put the finding in a single line: an agent's blast radius is not the agent process, it is everything the agent can write that the host later trusts. That sentence is the story, and it is why patching the individual bugs does not close the subject.
One socket explains three of the four products
The clearest finding is also the least exotic. Codex CLI, Cursor and Gemini CLI could all reach the local Docker socket from inside their sandboxes. A privileged daemon on the host will start a container for anyone able to talk to it, and that container runs outside the sandbox entirely. A single advisory, GHSA-v4xv-rqh3-w9mc, covers three of the four products tested. It is fixed.
Codex carried a second problem of a different shape. Its safe-command allowlist trusted commands by name. It permitted git show as a read-only operation without modelling what dangerous arguments to git show can actually do. That is patched in version 0.95.0, and the report earned a high-severity bounty.
Read the two together and the pattern is visible. Both are allowlists. Both were written against the thing an operator can see, a socket path and a command name, rather than against what that thing can do once it is reached.
The escapes arrived through files your editor already trusts
Cursor produced three. An agent could rewrite the interpreter inside a Python virtual environment and wait for the editor's own Python extension, which runs unsandboxed, to execute it. It could create a Git directory under a non-standard name so that path-based sandbox rules failed to match, then let fsmonitor pick it up. And it could drop a hook configuration into the workspace that the tooling executed without sandboxing. The last of those carries CVE-2026-48124 and advisory GHSA-pc9j-3qc2-95wv, and all three are patched in Cursor 3.0.0.
Google's two came from the same family. The macOS Seatbelt profile behind Antigravity was written as a denylist, which permits anything not explicitly named, and a .vscode task configuration could get past the protections of Secure Mode. Google told the researchers the report was of exceptional quality, then classified the findings as difficult to exploit because they require social engineering, and downgraded them on that basis.
The classification is defensible on its own terms and beside the point for anyone running these tools. Social engineering, for an agent, means a sentence in a README, a comment on an issue, or a paragraph in a dependency's documentation. Reading untrusted text is the agent's ordinary working day.
The boundary you bought is not the boundary you have
Each of these products presents the sandbox as the control that makes autonomous coding acceptable. That is the answer a security review receives, and it is the reason approvals were granted. The research shows the sandbox governs one thing, the agent process. It was never a claim about the workspace.
The workspace is the real surface, because the workspace is read by a long list of processes designed years before agents existed, all of which assume a human typed what they are reading. The Python extension. The git daemon. The Docker socket. The pre-commit hook. The dependency installer. The CI runner that clones the branch. None were built to treat repository contents as hostile input, and every one of them now does exactly that.
So the governance object is wrong. Owners have been approving agents. The thing that needs a policy is the workspace, and the rule is short: a repository an AI agent can write to is untrusted input to every process downstream of it, on the same footing as a file uploaded by a stranger.
What to change this week
Start with the socket, because one advisory covered three of the four products. No coding agent needs access to a Docker socket, and removing it is a configuration change rather than a project. Then move the versions. Cursor 3.0.0 and Codex CLI 0.95.0 are the fixed lines, and developer tooling updates per user rather than per fleet, so a vendor shipping a patch is not the same as your engineers holding it.
The durable change is where agents run. A branch an agent has touched should arrive at CI as untrusted, which in practice means the pipeline does not execute repository-supplied hooks, tasks or interpreters from that branch until a human has approved the diff. That is a pipeline decision rather than a tooling one, and it survives the next disclosure.
Under NIS2 an incident that starts in a developer's editor and ends in your production pipeline is reportable on the same clock as any other. The duty does not distinguish between an attacker who phished an engineer and an agent that read a poisoned README, so the control has to sit where the pipeline can enforce it.
Read next: The nginx Patch Is Out, the Exploit Lands in August | ServiceNow Patched Its Cloud First, You 103 Days Later
