Windows: a real VM with a deliberate hole in it
Windows has the strongest containment primitive of any desktop platform — Hyper-V — and the most commonly misrepresented one — WSL2. Getting this right is mostly about knowing which of the two you are actually relying on.
The four Windows containment options
| Option | Boundary | SKU | Good for | The catch |
|---|---|---|---|---|
| Windows Sandbox | Hyper-V VM, disposable | Pro/Enterprise/Education | A genuinely throwaway Windows desktop: run suspect installers, test a Windows agent, open a risky attachment. Configurable with a .wsb file. |
One instance at a time, must match the host OS build, everything is destroyed on close, no host workspace integration, cold start per launch, and Hyper-V is absent from Home. |
| Hyper-V / HCS VMs | Hyper-V VM, persistent | Pro/Enterprise; HCS-based tools can target Home | A real Windows or Linux guest with GPU paravirtualisation, snapshots and a headless API. The best boundary available on a Windows desktop. | You have to drive it. GPU-PV means shared paravirtualised driver code, and every tool built on the Host Compute System API has its own byzantine requirements. |
| WSL2 (+ WSLg) | Real VM with host bridges | Any Windows 10/11 | Everything Linux-shaped: Docker, Podman, containers, agents that are POSIX tools. WSLg puts Linux GUI apps on your Windows desktop, which is the nicest cross-boundary GUI experience that exists. | Interop and /mnt are deliberate bridges. A Linux sandbox inside WSL2 cannot contain a Windows process spawned through them. See below. |
| AppContainer / restricted tokens | Process isolation | Any | What Codex CLI uses for its Windows sandbox, composed from a synthetic SID, a write-restricted token and dedicated local users. | Microsoft's own documentation says shared-kernel process isolation is not a security boundary for hostile multi-tenant use. AppContainer needs capabilities declared up front, which fits packaged apps and fits an agent's dynamic toolchain badly. Known leaks: Everyone-writable directories, NTFS hard-link aliasing, and advisory-only network control without elevation. |
Why "runs in WSL2" is not a containment claim
WSL2 is genuinely good architecture: a real Linux kernel in a Hyper-V utility VM, with memory and kernel separation. Everything you have read about WSL1's syscall-translation "Pico process" model — where AppLocker, Code Integrity and AMSI could all be bypassed — does not apply to WSL2.
What does apply is that two features exist specifically to blur the boundary:
- Filesystem mounts.
/mnt/c,/mnt/dand so on expose your Windows drives, read-write by default, through 9P/virtiofs with Windows ACLs mapped to Linux permissions. The agent's sandbox may make them read-only on the Linux side; that only constrains Linux processes. - Interop. A Linux process can execute
powershell.exe,cmd.exe,wsl.exeor any Windows binary. WSL's init intercepts the call and spawns a native Windows process — outside every namespace the sandbox built, running with the current Windows user's full token.
Put those together and the consequence is blunt: a bubblewrap sandbox with --ro-bind / /
can be defeated by calling Remove-Item through interop. A 2026 proof of concept deleted
26.8 GB from a Windows drive from inside a write-restricted sandbox, with no approval prompt. Codex
responded by masking interop sockets inside restricted filesystems and denying AF_VSOCK and
io_uring. Claude Code's documentation says native Windows is unsupported and to run inside
WSL2 — which does not by itself close the interop path.
None of this makes WSL2 bad. It makes it a VM with a host bridge, and host bridges are exactly what a sandbox cannot reason about on its own.
docker-desktop distribution as root, and that all WSL distributions share one Linux kernel,
so kernel integrity cannot be guaranteed. In 2026 a security vendor documented Docker Desktop VM-escape
techniques under WSL2 that abused /mnt/host/c together with Docker's backend sockets and
user-writable CLI plugin paths. If your Windows isolation story is "Docker Desktop", it is a container
story wearing a VM's clothes.
Microsoft's own answer: MXC
At Build 2026 Microsoft introduced Microsoft Execution Containers, and you should read it for exactly what it is: a unified policy schema over many containment backends, plus a TypeScript SDK, used in production-ish form by Copilot CLI for model-generated code.
The backends it can drive are a tour of every option on this page: a process container (AppContainer-style), Windows Sandbox, WSLC (Linux containers via WSL), a Hyperlight microVM, NanVix, an isolation session that creates a throwaway Windows session, and on Linux bubblewrap and LXC, with Seatbelt on macOS.
Its policy vocabulary is the best public description of what constraining an agent actually involves: filesystem read/write path lists, network proxy and allow/block, and a UI policy covering clipboard, display and GUI access — plus a documented matrix of which of those each Windows build can enforce.
"There are known cases where the current policies generated by the MXC SDK in this repository are overly permissive and will be addressed before this is made more generally available… no MXC profiles should be treated as security boundaries currently." Denied paths are not yet supported on Windows, and network policy on Linux and macOS is described as cooperative.
Steal the schema vocabulary and the per-version capability matrix. Use it to launch Windows Sandbox and WSLC consistently. Do not ship a security promise that rests on an MXC profile today — and note that at least one serious agent harness evaluated MXC's Windows path and chose raw ACL restricted tokens instead, on the grounds that starting from a fresh AppContainer SID means retrofitting DACLs on every path.
Windows GUI desktops for agents
If you want an agent that drives a Windows desktop, you have three routes, and only two of them are containment.
Contained: a Windows guest in a VM
Windows Sandbox for throwaway work, or a Hyper-V/HCS VM with GPU paravirtualisation for real work. Reference implementations exist and are worth reading: NanaBox for Host Compute System gotchas and a portable JSON VM format, and appsandbox for GPU-PV desktop VMs on Windows 11 Home plus a headless HTTP/JSON API that is exactly the shape a workstation manager wants. Both are filed under Watch rather than Recommended, for one simple reason: neither is something we could get to run reliably.
Contained: Linux desktop via WSLg
Run a Linux desktop or individual GUI applications inside WSL2 and let WSLg render them as normal Windows windows. You get a VM boundary and a familiar desktop experience, and it is the single most pleasant GUI isolation story on any platform. The caveats are GPU-heavy applications and, of course, the interop bridge if you leave it open.
Not contained: host-control MCP servers
Windows-MCP is excellent software that gives an agent UI control of your machine by running on your machine as your user. It is the inverse of a sandbox. The problem is not the project, it is that it appears in comparisons alongside sandboxes, which is how "the agent can control Windows" gets misremembered as "the agent is contained on Windows". Use it inside a VM, and never where your real credentials live.
A sane Windows setup
Practical Windows agent isolation
recommended shape/mnt absent or read-only, non-admin account
If you need a Windows guest rather than a Linux one, substitute Windows Sandbox or a Hyper-V VM for the first layer and keep everything below it the same. If you need the strongest available boundary, make the first layer a Hyper-V VM with no host share at all.