AI Coding Agent Sandbox Escapes: How Cursor, Codex, Gemini CLI and Antigravity Were Bypassed

On July 20, Pillar Security published a series called The Week of Sandbox Escapes, covering seven findings across Cursor, Codex, Gemini CLI and Google Antigravity.

The title undersells the most useful idea in it. In most of these cases, the agent never broke its sandbox. It stayed inside, wrote a file, and waited for something outside the sandbox to trust that file.

If you use an AI coding tool every day, as I do, that changes where you should look for risk. I expect it will age better than any individual CVE in the list.

Three layers of a coding agent sandbox

Pillar splits the boundary into three layers:

Direct execution: what the agent process can run.
Workspace writes: what files it can create or change.
Host trust: what unsandboxed components do with those files.

Vendors have put a lot of work into the first layer. Pillar says the third layer is where the most interesting failures are.

An IDE, a Git extension, a Python language server and a hook runner all sit outside the sandbox with your full privileges. Their job is to read your project files and act on them. Once an agent can write to the project, it can leave instructions for those components.

The seven findings

Product	Mechanism	Status as reported by Pillar
Antigravity	An allow-default macOS Seatbelt profile left operating system features reachable	Accepted as a valid issue, downgraded as hard to exploit. No fix reported
Codex, Cursor, Gemini CLI	A reachable Docker socket gave restricted agents an unsandboxed execution environment	Cursor advisory GHSA-v4xv-rqh3-w9mc. Pillar says OpenAI paid and rated it informational, and Gemini CLI treats it as a documented risk
Cursor	The agent edited a virtualenv interpreter, and the unsandboxed Python extension ran it during discovery	Fixed, GHSA-p9g2-cr55-cw9c
Cursor	Git metadata indirection evaded path rules, and the Git extension triggered fsmonitor	Fixed in 3.0.0, CVE awaited
Codex CLI	An allowlisted `git show --output` could write `.git/config`	Fixed in v0.95.0, bounty paid, CVE awaited
Cursor	A workspace hook configuration led to unsandboxed command execution	Fixed in 3.0.0, CVE-2026-48124, CVSS 8.5
Antigravity	The agent wrote a `.vscode` task that the host later ran	Accepted as a valid issue, downgraded as hard to exploit. No fix reported

Source: Pillar Security, July 20, 2026. Vendor positions here are as Pillar describes them.

This series follows an April disclosure from the same team. There, a find_by_name tool in Antigravity passed its Pattern parameter straight to fd, so a value such as -Xsh turned a file search into command execution. Pillar says it ran with what it calls Secure Mode on, because the native tool call fired before those checks were evaluated. Google marked it fixed on February 28.

The four patterns behind these bypasses

Denylists lose to platform complexity. A sandbox that lists what is forbidden has to anticipate everything an operating system can do. An agent can try combinations no policy author considered, with unlimited patience.

Workspace configuration is often code. A virtualenv interpreter, a Git config, an fsmonitor helper and a task definition all look like data until a trusted tool loads them. We have treated these as settings for so long that we stopped seeing them as executables.

"Safe" commands are not safe by name. Allowlisting git show sounds reasonable. It ignores flags, config and side effects. The name of a command tells you very little about what an invocation will do.

Local daemons sit outside the sandbox. If the agent can reach a privileged daemon, such as Docker's, it can ask that daemon to do what it cannot. The daemon is a very cooperative accomplice.

Why prompt injection makes this worse

Most of these need an agent willing to write the malicious file, and the rest need one willing to run the command. That is where the risk stops being theoretical.

You do not need a rogue model. You only need a useful one that follows an instruction it found in a README, an issue or a dependency. Pillar's April write-up describes the indirect route: an attacker's comment in a file from an untrusted repository, with no account access required. The reported proof of concept there used direct injection, so the indirect path is described rather than demonstrated.

That combination gives an attacker a chain: a poisoned repository, an obliging agent, a file write that looks harmless, and a trusted host component that executes it. The human approval step might show a one-line config change.

My own setup is in scope for this

I built Career Rafeeq, an AI SaaS product, with Claude Code as my main engineering collaborator from the first commit, so this is not abstract for me. My working assumption has been that the tooling compresses the typing, while tests and my own review keep correctness.

This research argues for a third assumption: the workspace itself is part of the attack surface. A diff that touches .vscode, a hook file or Git config deserves a slower review than a diff that touches business logic, even though it looks far less interesting.

What I would change as a developer

Update your tools. Cursor 3.0.0 and Codex v0.95.0 are the versions named in these fixes.
Review agent changes to host-side automation first. Hooks, task files, Git config, CI files, virtualenvs and anything under a dot-directory.
Keep the Docker socket away from agents. Grant it only where it is explicitly needed.
Open unfamiliar repositories in a disposable environment. A container or VM with no credentials costs a minute.
Separate your credentials. The host tools run as you. Long-lived tokens in your home directory are the prize at the end of this chain.

What I would ask a vendor

If you are choosing a coding agent for a team, Pillar's list of questions is more useful than a feature comparison. The ones I would start with, plus one of my own on tool dispatch:

Is policy enforced at tool dispatch, so native tools cannot skip it?
Is enforcement based on side effects, or on command names and paths?
Which host components trust files the agent writes?
Can the product tell user-created state from agent-created state?
What telemetry appears when a trusted helper runs something an agent wrote?

If I were building one of these tools, I would also put argument handling into one shared builder, with an end-of-options marker that no wrapper can forget. And I would fuzz every tool parameter with flag-shaped strings under each approval mode. The April bug would not survive that test.

What these findings really show

None of this means AI coding tools are unsafe to use. I will keep using them. Vendors patched most of these, and Pillar's work is what responsible disclosure is supposed to look like.

The durable point is about how we model the problem. A sandbox is usually described by what is inside it. These findings say the more useful question is what outside it trusts the inside.

That question extends well beyond laptops. Any system that runs an agent in a box and then consumes what the box produces, a package, a dataset, a report, a config, has the same seam. The boundary is only as strong as the most trusting thing on the other side of it.

Sources

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise RAG, agentic AI, and AI-assisted software engineering.