The Sandbox Was Never Broken — Tools Outside the Box Trusted and Ran the Files That Cursor, Codex, and Gemini CLI Wrote

Plenty of teams assume that running a coding agent "inside a sandbox" makes it safe. A series of investigations published by the Israeli security firm Pillar Security under the title "Week of Sandbox Escapes" shows that this assumption has a hole in it. The targets were Cursor, OpenAI's Codex, Google's Gemini CLI, and Google's Antigravity — four widely used agents. The work drew renewed attention in mid-August when it was reported by BleepingComputer and others.

Follow the rules inside the box, plant the tool outside it

None of the seven issues brought to light this time actually broke the sandbox itself. The agent behaved by the rules inside its isolation — it simply wrote a single file. A hook configuration, a virtual-environment interpreter, a Git setting, a task definition — and then a separate tool living outside the sandbox later trusts that file, loads it, and runs it. That was the blind spot. The trigger is an indirect prompt injection slipped into a README, an issue, a dependency, or a diff. An agent that reads the malicious instructions performs a "harmless write" on the developer's machine, and outside the box that write turns into execution.

Pillar sums up the pattern in a single line: an agent's blast radius extends to everything the host's components will later trust. Isolating the process alone, they argue, is not enough.

Four recurring weakness patterns

Rather than treating these as isolated bugs, the research identifies four recurring failure modes as a structural problem.

• Denylist-style sandboxes: an "allow by default, block only the dangerous stuff" design can't keep pace with the complexity of the OS. Any operation someone forgot to block becomes a way out.
• Executable configuration files: .vscode tasks, .claude hooks, and virtual-environment interpreter settings are effectively "code that gets executed." The agent writes them, and a component outside the box trusts and runs them.
• Allowlists that look only at the command name: judging safety by the name rather than the full invocation is precarious. git show was treated as "read-only and therefore safe," but the actual invocation could write files.
• Privileged local resident processes: a resident service like Docker Desktop sits outside the sandbox. Reach it, and you have a foothold to execute code beyond the isolation.

Which tool, and what was found

Each vendor has already shipped fixes. Some issues have CVE numbers assigned; others are still awaiting one.

The fact that a single Docker socket issue pierced Cursor, Codex, and Gemini CLI at once is telling. It's less an agent-specific bug than a structural hole in a shared foundation. Google acknowledged the two Antigravity findings as "other valid vulnerabilities" but lowered their severity, arguing that exploitation requires social engineering such as the user trusting a malicious repository. It rated the quality of the research itself as "outstanding."

What changes from here

The key point is that none of these are "implementation mistakes in the sandbox" — they exploit the limits of the sandbox idea itself. You can put the agent in a box, but as long as the tools outside that box (the Python extension, Git integration, VS Code, Docker, the hook mechanism) unconditionally trust the files the box writes out, execution can always leak outward. The reassurance of "it's running, so it's safe," resting on process isolation alone, no longer holds. Developer endpoints have entered a phase where they need to be reexamined not through conventional process separation but through a threat model specific to agents.

What you can do on the ground right now

Pillar recommends defense in depth. Translated straight into operations, the essentials look like this:

• Update your tools first: move Cursor to v3.0 or later and Codex CLI to v0.95.0 or later. The fixes are already shipping.
• Stop auto-adopting configuration files: when an agent modifies a "configuration that leads to execution" — a hook, a task, an interpreter setting — require explicit human approval.
• Apply the same rules to direct execution and to "helper processes": enforce one policy not only on the agent's own execution but also on the work spawned by host-side auxiliary tools.
• Track file provenance: distinguish "written by a human / written by an agent / originating from the repository," and watch the points where trust is handed off.
• Narrow access to privileged daemons like Docker: review the paths by which an agent can reach a resident service's socket.

When adopting or evaluating these tools, the questions to put to vendors are concrete, too. "Which files can the agent write?" "Which host component auto-executes those files?" "Which local daemons are reachable?" "Is command approval judged by name, or by the actual invocation?" Handing an unattended agent to a party that can't answer these would be premature.

The attack surface that grows behind the convenience

The more a coding agent expands the scope of what it can "read, write, and execute," the more room there is for unintended code to run on the developer's own machine, starting from an indirect prompt injection. The vendors' responses this time were swift, but the more fundamental issue is that the line for "how far should tools outside the box trust what an agent wrote?" is not yet settled as a shared industry practice. The observation that convenience comes at the cost of a larger attack surface is not fearmongering — it is becoming a premise that teams pushing toward unattended operation need to confront head-on.

References: The Week of Sandbox Escapes (Pillar Security) / BleepingComputer / Techzine / The Next Web / DevOps.com