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

I'll pull the source article so the five analytical paragraphs stay factual and specific, without inventing numbers or dates.Pillar Security published research showing a shared sandbox escape across OpenAI Codex CLI, Cursor, and Google Gemini CLI. Researchers reported one near-identical chain to all three vendors: with sandbox and network access enabled, an agent could still reach Docker Desktop, break out of the workspace boundary, and read or write the user’s full home directory. Cursor shipped a fix and rated the issue high (advisory GHSA-v4xv-rqh3-w9mc). OpenAI agreed the behavior was not intended, paid the report, marked it informational, and declined a CVE. Gemini CLI treated it as documented risk rather than a product bug.

The mechanism sits outside deny-default process sandboxes. The agent can still execute binaries (including the docker CLI), read files (including the Docker socket), and use network access. On macOS, connecting to that Unix socket counts as a network operation. The PoC curls an Alpine minirootfs tarball (v3.19.1 for x86_64 or aarch64) into the workspace, imports it with docker import so registry pull rules never fire, then runs a privileged container with a bind mount only to sandbox-allowed paths. Inside the container, mount -t virtiofs virtiofs0 exposes the host home via Docker Desktop’s VirtioFS share. From the sandbox’s view, every write still lands in allowed space; the real work happens in the Docker VM.

For engineers running coding agents with Auto-Run or workspace-write plus network, this is not a theoretical model jailbreak. Docker Desktop is common on developer Macs, so the second execution environment is already local. Prompt injection is enough: the same steps can live in a README, comment, or doc the agent reads during normal work. Once home is mounted, credentials, SSH keys, browser data, and shell configs (for example appending to .zshrc) are in scope. Seatbelt and similar profiles judge syscalls; they do not judge what a privileged local daemon will do on the agent’s behalf.

Vendor responses split the market signal. Cursor closed the Docker path so the socket is not usable from inside the sandbox. Codex still exposes the chain when workspace-write and network_access are both on; OpenAI argues Unix sockets are mediated by a network proxy and denied unless explicitly allowed, so they frame it as configuration-dependent rather than a default escape. Gemini CLI points at docs. Three products, one chain, three risk labels: fixed high, paid informational, and “already documented.”

If you run these agents with sandbox and network together, treat Docker Desktop as part of the trusted computing base or keep network off unless you need it. Prefer updated Cursor builds that address the advisory; for Codex and Gemini CLI, assume documented or paid-but-unpatched exposure until product defaults change. Watch whether vendors start blocking docker, the Docker socket, and other privileged local daemons from agent sandboxes by default, not only Launch Services and workspace writes. Containment that only fences the agent process without fencing what it can call will keep losing to the next local helper already running on the machine.