Sandbox Escapes That Never Leave the Sandbox

Pillar Security spent several months reproducing sandbox bypasses across all four of the dominant coding agents , Cursor, OpenAI Codex, Google Gemini CLI, and Antigravity , and the headline finding is precise: in almost every case, the agent did not need to break the sandbox at all. It only had to write something that a trusted component outside the sandbox would later run, load, or treat as safe. The containment held. The host executed the code anyway.

The Architectural Problem#

The sandbox model for coding agents draws a perimeter around the project folder. Inside is the agent; outside is the host. The assumption is that confining the agent to that folder confines the risk.

That assumption fails because the files inside the folder are not inert. A Python extension resolves an interpreter from the virtual environment. A Git integration scans hooks. Docker Desktop exposes a local socket. When the agent writes into any of those locations, it is not escaping , it is authoring a future instruction that a privileged host process will carry out voluntarily. Pillar Security via vuink.com puts the implication directly: "an agent's blast radius is not the agent process; it includes everything the agent can write that the host later trusts."

Detection tools watching for explicit breakouts see nothing. The sandbox logged no violation. The boundary was never touched.

Four Failure Modes, Not One Bug#

Pillar sorted seven findings across the four tools into four repeatable patterns. Denylist sandboxes that cannot keep pace with OS complexity. Workspace configurations that are really executable code. Command allowlists that trust a name but not its invocation arguments. Privileged local daemons sitting entirely outside the sandbox.

Each pattern is structural. None requires a novel exploit. In Antigravity, researchers injected the -X flag into the find_by_name tool's Pattern parameter, converting a file search into arbitrary binary execution. In Cursor, agent-created Python virtual environments and workspace hook configurations ran with host privileges. A single Docker Desktop socket bug hit Cursor, Codex, and Gemini CLI simultaneously.

The trigger in most scenarios is prompt injection , a malicious instruction embedded in a README, a dependency, or a diff , but the injection itself is downstream of the real problem. The real problem is that the project folder is treated as trusted territory, so anything the agent reads there can direct what the agent writes, and anything the agent writes can direct what the host runs.

Google Declined to Patch#

Cursor patched its workspace hook flaw as CVE-2026-48124 in version 3.0.0. OpenAI fixed a Codex Git-allowlist bypass and paid a bounty. Neowin reported that Google classified both Antigravity findings as valid but downgraded their severity as hard to exploit, and did not ship a patch. Google did describe one of the reports as "of exceptional quality."

Pillar's response to the "hard to exploit" classification is worth noting. The attack requires a developer to trust a poisoned repository. That is not a hypothetical edge case , it describes the everyday working condition of every developer using these agents.

What the Review Surface Actually Includes#

This is where the finding bites deepest for anyone running autonomous code review. The intuitive model of agent risk is about the diff: what did the agent change? Pillar's research demonstrates that framing is insufficient. The agent read files on the way to producing that diff. Some of those files may have shaped what the agent wrote. Some of what the agent wrote may influence what privileged host processes execute next.

The review surface is the read set, not just the change set. Workspace configs, hook definitions, virtual environment contents, and CI task files all belong on that surface. Pillar's specific recommendations include treating workspace configurations that can trigger execution as sensitive assets, requiring explicit approval before agents create or modify host-side automation, and preserving provenance that distinguishes user-created files from repository-generated or agent-generated ones. CSO Online adds: monitor trust handoffs throughout the development workflow, not just at the point of agent invocation.

The Vendor Claim That No Longer Holds#

"Our agent runs in a sandbox" has been a sufficient answer for most security conversations about coding agents. After this disclosure, it is not. The useful questions are different now: Where exactly is the sandbox boundary? What can the agent write to? Which host components trust those writes? Which local daemons can the agent reach? What telemetry exists when a trusted helper executes something the agent influenced?

Pillar's four-tool finding , spanning three vendors, seven distinct bugs, and a one-week structured release of deep-dives , makes the universality hard to argue with. This is not a Cursor problem or a Codex problem. It is a shared architectural assumption that did not survive contact with how coding agents actually operate inside a developer's environment. The supply chain risk that prompt injection creates is covered in more depth in the hallucinated dependency attack, but the Pillar research extends that concern: the agent does not need to be fed a malicious package name. A malicious instruction anywhere in the repo's read surface is enough.

Hyrax is live at hyrax.dev.