Microsoft's Quicksand puts local coding agents inside a pip-installable QEMU VM
Quicksand is a Python API for rootless, Docker-free QEMU VMs with snapshots and network off by default, for developers running agents locally.
Picture a freelance developer with a client's Django repo and a coding agent in her terminal. She wants the agent to grind through a dependency upgrade unattended: install packages, run the test suite, fix, repeat. Today she has two bad options. She can approve every shell command, which defeats the point of an agent. Or she can skip permissions on her own laptop, where her SSH keys and cloud credentials sit one cat away from a prompt-injected README. Her agent's built-in sandbox helps, but it runs on her host kernel. Docker isn't installed on this machine, and she'd rather not add a daemon just to contain one agent. When the agent wrecks the environment halfway through, she rebuilds it by hand.
That's the gap Quicksand aims at. Microsoft's README describes it as "an async Python API to launch, control, and snapshot QEMU virtual machines with a particular focus on sandboxing AI agents." It installs with pip, needs no root or Docker, starts with networking isolated, and can roll a whole VM back to a checkpoint. At least one other Microsoft project already relies on it: Hysen Labs' write-up of MagenticLite says Magentic-UI runs its browser sessions inside a Quicksand VM.
What it is
According to the README, here is what ships, mapped to the pain above:
- A separate kernel, not a filtered process. Quicksand boots pre-built Ubuntu 24.04 and Alpine 3.23 images under QEMU, on x86_64 and ARM64, across macOS, Linux and Windows. That matters because, as VDF.AI's comparison of isolation options puts it, ordinary containers share the host kernel; it cites the runc escape CVE-2024-21626 and three more runc flaws disclosed in November 2025. In VDF.AI's table, escaping a VM-based sandbox requires a hypervisor escape, while escaping an OS-level sandbox needs "a kernel bug or a gap in the policy."
- Network off unless you ask. The README says sandboxes are network-isolated by default. The config lists
NONE,MOUNTS_ONLY(the default) andFULL, plus host-to-guest port forwards. - Only the workspace goes in. You share host directories at boot or hot-mount them into a running VM.
- Undo for agent mistakes.
checkpoint()captures full VM state andrevert()snaps back.save()writes disk state to a directory you can load later, "even on a different machine." - Several agents, one VM.
create_user()gives each agent its own Linux account inside a single sandbox. - Computer-use. Desktop images ship Xfce4 and a browser, with
screenshot,type_textand mouse control. Aquicksand-cuaimage adds Playwright, Chromium and noVNC; aquicksand-agentimage bundles Python 3.12, uv and build-essential. - Small by default. Guests get 512M of RAM and one vCPU unless you set
memory,cpusordisk_size.
The alternatives, each described from its own source:
- Claude Code's
/sandbox(docs): built in, uses Seatbelt on macOS and bubblewrap plus socat on Linux and WSL2, no native Windows. Nothing extra on macOS, but it's OS-level isolation on your kernel, and per Developers Digest's comparison it wraps shell commands only while hooks, local MCP and LSP servers run with your full access. - Codex and Copilot CLI (same comparison): Codex sandboxes by default with network off; Copilot CLI's local sandbox went GA on October 7 with native Windows 11 support but network on by default. Lightweight, but each covers only its own agent.
- Docker Sandboxes (HelixML): per-sandbox microVMs with their own kernel, network policies and credential proxying for Claude Code, Codex and others. Strong and ready-made, but it runs via Docker.
- E2B (Developers Digest, prices as of October 8, 2026): hosted Firecracker microVMs with pause and fork. Managed and fast, but metered, with a $150/month Pro plan for 24-hour sessions (Hobby caps runs at one hour), and your code runs in someone else's cloud.
Who it's for
Pick it up if you write Python, run agents on your own machine, and want a real VM boundary with snapshots without installing Docker or granting root. It fits people building their own agent harness, anyone running more than one agent (the Developers Digest comparison recommends a single boundary such as a VM around all of them, since each built-in sandbox covers only its own agent's commands), and anyone prototyping computer-use agents who wants the browser off the host.
Skip it if you use one CLI agent and its built-in sandbox, with credential paths denied, already does the job. Skip it if Docker is already on your machine and you want agent integrations out of the box; Docker Sandboxes is closer to that. Skip it if you need hosted scale, forking or team-shared infrastructure. And hold off if your company requires a vetted license: the README text we reviewed doesn't state one.
Before and after
Before:
- The agent runs on your host as you.
- You either approve each command or turn approvals off.
- If you enable the built-in sandbox, reads stay wide by default; Claude Code's docs, as summarized by Developers Digest, say sandboxed commands can read "most of the machine," including
~/.ssh, until you deny those paths. - A bad
apt installor broken virtualenv means rebuilding by hand.
After, using the calls the README shows:
- Boot a
Sandboxfrom an image such asquicksand-agent, mounting only the project directory. - Route the agent's shell commands through
sb.execute(), which returnsstdoutandexit_code. - Call
checkpoint()before a risky step;revert()if it goes wrong. - Switch to
NetworkMode.FULLonly for the run that needs internet. save()a working environment and boot from it next time.
Step 2 is your code. The sources don't show a ready-made hook for Claude Code, Codex or Copilot CLI, so you're writing the bridge between your agent's tool calls and the VM.
Try it
The README gives a one-line install that bundles QEMU and the Alpine image:
pip install 'quick-sandbox[qemu,alpine]'
Or install the core package and add pieces separately:
pip install quick-sandbox
quicksand install qemu alpine
Its first program:
import asyncio
from quicksand import Sandbox
async def main():
async with Sandbox(image="ubuntu") as sb:
result = await sb.execute("echo 'Hello from the sandbox!'")
print(result.stdout)
asyncio.run(main())
That example boots ubuntu, so you'd also need quicksand install ubuntu, or change it to image="alpine" to match the install above. Then the rollback loop, inside the same async with block:
await sb.checkpoint("before-experiment")
await sb.execute("apt install -y something-risky")
await sb.revert("before-experiment") # the VM snaps back to the checkpoint
Budget for downloads. Per the README's table for the September 14, 2026 releases, alpine is about 82–85 MB, ubuntu about 309–357 MB, and quicksand-cua about 489–500 MB on top of its bases. The README says the bundled runtime covers "supported platforms" but, in what we reviewed, doesn't list per-OS prerequisites or hardware acceleration requirements. Its Performance guide is listed as covering "TCG vs KVM." The only version evidence is Magentic-UI's pin of quick-sandbox[qemu,cua]~=0.11.14, per Hysen Labs. The sources don't mention pricing.
Where it breaks
- Unconfirmed basics. The current release number and the license aren't stated in the README text we reviewed. Hysen Labs' MIT note applies to MagenticLite, not Quicksand.
- No speed data. We found no benchmark of boot time versus a container, and none for checkpoint, revert or saved-image size. For comparison only, VDF.AI notes Firecracker states sub-125 ms boots; Quicksand publishes nothing comparable.
- Platform gaps undocumented. Mount filesystem performance, GPU passthrough and how complete Windows support is aren't covered in the sources found.
create_userisn't a VM per agent. Users in one sandbox share that VM's kernel, so treat it as weaker isolation than separate sandboxes. How strong it is isn't documented.- No reverse port forwards yet. Issue #55, opened two days before this piece, asks for exposing a host service inside an otherwise offline sandbox. That's exactly what you'd want for a package mirror or credential proxy; today forwards go host-to-guest.
- A boundary is half the job. VDF.AI stresses no standing credentials, default-deny egress and ephemeral state. A writable mount of your repo still lets the agent change your repo, and mounting
~/.awsdefeats the point. - Maintenance signal is thin. There's an active issue tracker and a dependent Microsoft project, but we found no news coverage, no independent hands-on reviews, and no statement of team ownership or commit cadence.
Bottom line: Quicksand offers a full-VM boundary and undo for agents you run locally, at the cost of writing your own integration and accepting undocumented performance and licensing.
Sources
- GitHub - microsoft/quicksand: Quickly sandbox your AI agent. · GitHub
- Feature request: port forwards in opposite direction · Issue #55 · microsoft/quicksand · GitHub
- MagenticLite: Magentic-UI for small models · Hysen Labs
- Sandboxing AI Agents: Containers vs gVisor vs MicroVMs · VDF.AI
- Configure the sandboxed Bash tool - Claude Code Docs · Claude Code Docs
- Self-Hosted E2B Alternatives: 6 AI Agent Sandboxes Compared — HelixML · HelixML
- E2B vs Daytona vs Modal: AI Agent Sandboxes Compared (2026) · Developers Digest
- Claude Code vs Codex vs Copilot CLI: Local Sandboxes Compared · Developers Digest