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

I'll pull the source article so the paragraphs stay grounded in real details—names, mechanics, and claims—without inventing numbers.**Pillar Security** researchers disclosed a shared sandbox escape that hits **Codex CLI**, **Cursor**, and **Gemini CLI** when those tools run with sandboxing on and network access enabled on machines that also run **Docker Desktop**. The finding is part of their **Week of Sandbox Escapes** series. All three agents use closed, deny-default seatbelt-style profiles meant to pin writes to the workspace and temp paths. The researchers reported the same chain to each vendor and got three different outcomes: Cursor shipped a high-severity fix (**GHSA-v4xv-rqh3-w9mc**), OpenAI paid the Codex report but classed it informational with no CVE, and the Gemini CLI team treated it as a documented risk rather than a product bug.

The escape does not break the sandbox’s own file-write rules. It reaches around them through a privileged local daemon the agent can still talk to. With network and execution allowed, the agent can run the **docker** CLI, reach the Docker socket (treated as a network connect on macOS), curl an **Alpine** minirootfs tarball into the workspace, and **docker import** it so registry pull restrictions never apply. It then starts a **privileged** container with a bind mount into an already-permitted directory and, inside that container, mounts **virtiofs** (`virtiofs0`) to expose the user’s full home directory for read and write. From the agent’s view, every write stayed in allowed paths; the real host access happens inside Docker Desktop’s VM, outside the sandbox’s jurisdiction. A proof-of-concept ends by appending a command to **.zshrc** so a host process runs on the next terminal open—Calculator in the demo, or any payload.

For engineers who treat “run in sandbox” as a hard host boundary, this is a concrete failure mode, not a theoretical one. Auto-run plus network plus a local Docker socket turns the agent into a proxy for unsandboxed work: SSH keys, credentials, and browser data become reachable without the agent ever writing outside the workspace itself. Indirect injection is enough; the steps can live in a README, comment, or doc the agent reads during normal work, not only in an explicit malicious prompt. Anyone shipping agent-driven CI, local auto-run, or “safe by default” coding agents on Docker-heavy Mac fleets is in the blast radius of that assumption gap.

The market split is the other story. Cursor restricted Launch Services in its seatbelt profile, still hit Docker under Auto-Run in Sandbox with network on, then fixed the Docker-socket path so the issue stopped reproducing on the next build. Codex shows the same escape under `workspace-write` with `sandbox_workspace_write.network_access=true`; OpenAI agreed the behavior was unintended and boundary-breaking but argued Unix sockets are mediated by the network proxy and denied unless explicitly allowed, so they do not call it a default escape. Gemini CLI’s response was shorter: same chain, same virtiofs mount, risks already in the docs. Three near-identical products, one finding, three severity philosophies—fix, bounty-plus-informational, documentation.

Practical takeaway: judge sandboxes not only by blocked syscalls but by which privileged daemons and sockets the agent can still reach. On a Docker Desktop machine, the socket is a second execution environment one curl away. Watch whether Codex and Gemini CLI tighten socket and Docker access the way Cursor did, whether default profiles keep network-to-socket paths closed without an explicit allow, and whether vendors move beyond seatbelt deny lists toward stronger containment (for example gVisor-style userland kernel mediation, real execution containers, and human-in-the-loop for high-risk ops). Until then, treat “sandbox on + Docker installed + network allowed” as an incomplete isolation story, not a host-trust guarantee.