One Docker socket to rule them all: Escaping Codex, Cursor, and Gemini CLI

Fetching the Pillar Security article so the paragraphs stay factual and avoid invented details.Pillar Security researchers showed that **OpenAI Codex CLI**, **Cursor**, and **Google Gemini CLI** can all leave their macOS sandboxes through the same path: a live **Docker Desktop** install and a readable **Docker socket**. The report sits in their **Week of Sandbox Escapes** series and was disclosed to all three vendors after the same chain reproduced on each product. On Hacker News the write-up was still quiet at one point and zero comments when listed. The core claim is simple: deny-default seatbelt profiles block many direct host writes, but they do not stop a privileged local daemon from doing those writes for the agent.

Technically the break is not a kernel bypass. With sandbox and network access enabled, the agent can still run binaries such as the **docker** CLI, read the Docker socket, and make outbound HTTP. An injected script curls an **Alpine minirootfs** tarball into the workspace, **docker import**s it so registry image rules never apply, then **docker run --privileged** with a bind mount only to an already-allowed directory. Inside that container, **mount -t virtiofs virtiofs0** exposes the user’s full home via Docker Desktop’s own **VirtioFS** share. Writes then land in places like **.zshrc** outside the workspace, while every file operation from the agent’s perspective still looks local and allowed.

For engineers and builders this collapses the usual mental model of agent safety. Seatbelt and workspace-write modes answer “what can this process call on the kernel?” They do not answer “what can this process ask Docker to do?” If Docker Desktop is on the machine—common for Mac developers shipping containers—the agent effectively has a second execution environment outside the sandbox’s jurisdiction. Prompt injection need not be a dramatic jailbreak string either; the same steps work from a README, comment, or doc the agent reads while doing normal work, so auto-run plus network plus Docker is the real risk surface.

Vendor responses split three ways on one near-identical chain. **Cursor** treated it as high severity, agreed the Docker socket should not be reachable from inside the sandbox, shipped a fix, and published advisory **GHSA-v4xv-rqh3-w9mc**. **OpenAI** agreed the workspace boundary could be broken under that configuration, paid the report, labeled it informational, and declined a CVE on the grounds that Unix-socket access is mediated by the network proxy and denied unless explicitly allowed—so they frame it as non-default. **Gemini CLI** said the same chain is not a bug because the risks are already documented. That is a useful market snapshot: same class of agent tooling, same host helper, three different definitions of “fixed.”

Practical takeaway for teams running these CLIs on Docker-heavy Macs: treat “sandbox on” as incomplete isolation while the agent can talk to Docker. Prefer profiles that keep network and Docker socket access off unless a task truly needs them; run agents without Auto-Run when untrusted repos or docs are in scope; and assume Cursor builds after their advisory behave differently from Codex workspace-write-with-network and Gemini CLI under the same Docker-present layout. Watch whether Codex and Gemini tighten socket mediation the way Cursor did, and whether future agent sandboxes start denying daemon sockets and VirtioFS-style host mounts by default rather than only blocking direct filesystem syscalls.