Docker Desktop Bypass Lets AI Coding Agents Escape Their Sandboxes

Codex CLI, Cursor, and Gemini CLI all moved to closed, deny-default sandbox profiles, a stricter model than the allow-list approach seen in earlier agent sandboxes. On paper this should block an agent from executing arbitrary processes or writing outside its workspace. Researchers found the same escape chain works against all three products anyway, through Docker Desktop.

The sandbox restricts writes outside the workspace but doesn't block process execution, file reads, or outbound network access. Combined, those let an agent run the docker CLI, read the Docker socket (effectively root over the daemon), curl a container rootfs tarball and docker import it to dodge registry restrictions, and launch a --privileged container bind-mounted to an already-allowed directory. From inside that container, mounting VirtioFS grants read/write access to the user's entire home directory. Because this all happens inside the Docker VM, it's outside the sandbox's jurisdiction and looks like a policy-compliant write from the agent's perspective.

The three vendors responded differently to the identical finding. Cursor confirmed the issue, shipped a fix, and published a high-severity security advisory. OpenAI paid the bounty but classified it as informational rather than a bug, arguing that Unix socket access is deny-by-default in their network proxy unless explicitly allowlisted, so it isn't a default-path escape. The Gemini CLI team considered the risk already documented and declined to treat it as a bug.

The finding matters because sandbox security is usually judged by which syscalls it blocks, not which privileged local daemons remain reachable. A large share of developer machines run Docker Desktop by default, and the same chain can be triggered via indirect prompt injection through a README or code comment, not just a direct instruction.