# The Agent Followed Every Rule. The Files It Wrote Did Not.
Pillar Security just spent several months breaking out of AI coding agent sandboxes across four tools from three vendors — and the most important word in that sentence is "across." This is not a Cursor bug, or a Codex bug, or a Google bug. It is a design assumption that the entire industry is building on, and it does not hold.
The pattern goes like this: the agent lives inside a project workspace. The sandbox draws a hard line — agent on the inside, host machine on the outside, never the twain shall meet. Except the agent writes files. And those files are read, executed, scanned, and acted on by tools that sit outside the sandbox entirely. The Python extension resolving interpreters. The Git integration watching for changes. VS Code's task runner. The hook engine. Docker Desktop with its local socket. None of these trust the agent. All of them trust the files.
So the agent obeys every rule it is given. And the file it is allowed to write becomes the command the host later runs. The escape happens on its own.
## Seven Findings, Four Ways the Wall Fails
Pillar's research team — Eilon Cohen, Dan Lisichkin, and Ariel Fogel — published their findings as a "Week of Sandbox Escapes," one write-up per day starting July 20. Seven vulnerabilities, four tools, and a clean taxonomy of what keeps going wrong.
Denylists that can't keep up. The first failure mode is the most predictable: security teams enumerate dangerous paths and commands, then the operating system or the IDE adds a new way to do the same thing. The list never catches up. One of the Cursor findings abused the fact that Git metadata doesn't have to live in a folder called .git — the fsmonitor path fired execution and slipped right past Cursor's path-based rules. Patched in version 3.0.0 with a CVE pending.
Workspace config that is secretly executable code. The second failure is more interesting. A .claude hook configuration file lives in the workspace. The agent is trusted to write to the workspace. The hook engine is trusted to read those files. Connect the dots: a sandboxed agent edits the hook config, the hook engine outside the sandbox fires the command. This became CVE-2026-48124 in Cursor, also fixed in 3.0.0.
Allowlists that trust the name, not the invocation. In OpenAI's Codex CLI, git show was on the safe list. Read-only by name, right? Except the actual invocation wasn't. The allowlist checked what command was called, not what it was being told to do. OpenAI patched this in v0.95.0 and paid a high-severity bug bounty.
Privileged daemons that live outside the sandbox entirely. The Docker socket finding hit Cursor, Codex, and Gemini CLI simultaneously. Docker Desktop exposes a local socket. A sandboxed agent can reach it. Code execution on the host, no sandbox escape required — because the socket was never inside the sandbox to begin with.
## How a Prompt in a README Becomes Root
The trigger for all of this is prompt injection — a malicious instruction planted in a README, a dependency, a pull request diff, or a GitHub issue. The developer opens the repo, the agent picks up the instruction while processing context, and the instruction becomes a file write. The file write becomes an action by a trusted outside tool. The action runs on the developer's machine.
This is what makes the attack surface genuinely uncomfortable. The developer doesn't have to run anything suspicious. They don't have to approve anything. They open a repository that a colleague sent them, or they pull down a dependency, and the agent helpfully processes the context it finds there.
## Google's Notably Cooler Response
Four of the seven findings were acknowledged and fixed with CVEs or pending CVEs. Google took a different approach to the two Antigravity bugs — a macOS Seatbelt denylist bypass and a .vscode task-config bypass of Secure Mode — classifying both as "other valid security vulnerabilities" and applying a severity downgrade on the grounds that exploitation requires social engineering or trusting a repository that carries an indirect prompt injection.
Pillar's team noted that Google's reviewers still called one report "of exceptional quality." But the downgrade framing is worth examining. "Requires social engineering" describes almost every initial access technique in the MITRE ATT&CK framework. Developers are constantly cloning unfamiliar repositories, evaluating open-source dependencies, and reviewing external pull requests. That is not a threat model edge case. That is Tuesday.
## An Old Pattern, a Wider Problem
This class of attack is not new. In April 2026, Cymulate documented what they named "Configuration-Based Sandbox Escape" across Claude Code, Gemini CLI, and Codex CLI, where a file written inside the sandbox runs on the host at next launch. Pillar's work extends that framework with additional failure modes and two new tools.
What's new is the breadth. The same fundamental assumption fails across four tools from three different vendors, each of which built their sandbox independently. That is the useful signal here: this is not a bug someone shipped, it is a design pattern the industry converged on without adequately stress-testing the trust relationship between sandboxed agents and the host tooling ecosystem they live inside.
---
## HackWire Analysis
The conventional mental model of sandboxing assumes that capability restriction maps cleanly to risk restriction. Contain the agent, contain the damage. What Pillar's research makes explicit — and what Cymulate was pointing at three months ago — is that this model breaks down whenever the sandbox is embedded in a living development environment.
Modern IDEs are not passive viewers. They are orchestrators. They watch the filesystem, resolve interpreters, fire hooks, connect to daemons, execute task configs. Every one of those behaviors is a potential trust bridge between what the agent is allowed to do and what the host actually does. The sandbox is only as strong as the weakest tool that reads from inside it.
The defensive implication that most coverage is underweighting: the problem is not just prompt injection as a trigger — it's the implicit trust that developer tooling extends to files in the workspace. Vendors can patch individual escape paths, but the broader pattern will resurface whenever a new IDE integration or extension creates a new outside-reads-inside relationship. The fix Pillar proposes — sandboxing file writes by intent rather than by path — is technically sound but architecturally ambitious. It requires vendors to reason about what each file write is *for*, not just where it lands.
For teams already deploying agentic coding tools at scale, the near-term hardening is unsexy but real: treat project-workspace config files as untrusted input, audit which host tools read from those paths, and be skeptical of any repository your agent might process that you didn't author yourself. The prompt injection risk is not theoretical — and it does not require the attacker to ever touch your machine directly.
— HackWire Editorial
---
## Related Coverage