App Sandbox: Full Desktop VMs on Windows 11 Home and Apple Silicon

Windows 11 Home, without the Hyper-V licence requirement

App Sandbox is a virtual machine application for Windows and macOS focused on performance and ease of use, and it creates and runs full desktop machines: Windows 11, Ubuntu and macOS. The claim that shapes its Windows design is that it works on Windows 11 Home or Pro without Hyper-V. On Windows it does not use Hyper-V or Hyper-V Manager at all, and instead creates VMs through the Windows Host Compute System and Host Compute Network APIs, which require only the Virtual Machine Platform feature. The reasoning is spelled out: Hyper-V is limited to Windows 11 Pro and Enterprise, while Virtual Machine Platform is available on Windows 11 Home, so a Pro licence is not needed. Virtual Machine Platform is the same Windows feature WSL2 uses, which is also why the project positions itself as a working example of the same underlying layer rather than a separate hypervisor.

Sharing the host GPU through paravirtualization

GPU acceleration is GPU paravirtualization, described as the same WSL2 path, not a dedicated passthrough, with no VFIO or IOMMU and no second GPU. The guest graphics coverage differs by guest: Windows guests get DirectX 12, OpenGL, Vulkan, CUDA and OpenCL, Ubuntu guests get the same set minus DirectX, and macOS guests get Metal. On the Windows host, no GPU acceleration is offered for Windows guests. Linux guests reach the GPU through a custom DRM and KMS kernel module named `asb_drm`, along with Microsoft's WSL2 `dxgkrnl` and a custom Mesa build. That combination is the hard part of the project and explains why it ships custom kernel and graphics components rather than relying on stock drivers. A GPU hardware video decoder and encoder are also supported.

A display driver, an audio device and vsock plumbing

The screen and sound are carried by custom virtual hardware rather than by a software framebuffer. A custom IddCx indirect display driver presents the guest screen, and a virtual audio device provides two channel audio. Guest to host clipboard, audio, input and SSH all run over Hyper-V sockets on Windows and over virtio-vsock on macOS. SSH therefore needs no network at all, which is what makes the offline provisioning path workable. The display is fixed at 1080P60 for Windows guests and dynamically sized for macOS guests. Host to client hot-key support is included, and on Windows you enable hotkeys or mute the VM audio by connecting to the VM and right-clicking the connection title bar. Guest disks are built by an in-repo tool that supports ext4, squashfs, qcow2 and VHDX.

Driving VMs from the headless daemon and the Python SDK

The application can run without its interface. On Windows the daemon is started with the headless flag.

appsandbox.exe --headless

On macOS the same core runs from the application bundle.

sudo /Appsandbox.app/Contents/MacOS/AppSandbox --headless

That process is a single-owner daemon exposing the same core as the GUI as a Docker-style local HTTP and JSON API on `127.0.0.1`, identical on both platforms. The dependency-free, standard-library-only Python SDK named `asb.py` wraps it: create GPU-accelerated VMs, with GPU-PV as a `gpuMode` create option, SSH in over an auto-deployed key, snapshot and branch them, open the live display, and run several at once. Concurrency is bounded by host CPU, RAM and GPU memory rather than a fixed limit. The full API reference and runnable examples live in `tools/headless-api/`.

Snapshots, branches and the difference from reinstalling

The lifecycle model has three verbs and each one costs something different. Provisioning a VM runs a full unattended install. A snapshot is a disk-state checkpoint taken with the VM stopped, and a branch forks a writable disk from that checkpoint so divergent actions can run without touching the original. Templates, which are Windows-only, start a new VM from an already provisioned state instead of reinstalling, which is the fast path for repeated test runs. A VM persists until it is deleted, so cleanup is your responsibility rather than the tool's. The daemon is single-host, meaning it drives VMs on the machine it runs on and does not provision cloud VMs, and the documentation points at self-hosted runners for CI rather than promising a hosted fleet.

What the virtual machines are for

The documented use cases split into development and agent workloads. For development, you get a full Windows or Ubuntu desktop with GPU acceleration for building and testing your own software on a clean install, or a place to run a program kept separate from your main OS and files. Driver development has specific support: a built-in Test Mode enables test-signing inside the guest, so the host's Secure Boot and boot configuration stay unchanged. For computer use agents, the arrangement is that App Sandbox provides the desktop and the VM while the agent's own model loop runs inside the guest, and several agents can run at once, each in its own VM, on a single laptop or desktop. The Windows guest additionally supports running Claude Cowork and Docker inside the VM, which is possible because of nested virtualization support.

Zero touch install and provisioning without a network

Getting a guest from an installer image to a running desktop is the part that decides whether a VM tool is usable in a script. The stated flow is that you pick an OS, point the tool at an installer image, and App Sandbox provisions the disk, runs an unattended install and boots the guest. You supply a Windows or Ubuntu ISO yourself, while macOS guests download their restore image automatically. Both host platforms can provision and boot with or without internet, which is the requirement that makes offline and hermetic testing possible. On Windows the install is fully zero touch; on macOS there are three onboarding steps that cannot be skipped. The distributed binaries are prebuilt and signed, EV-signed on Windows and Apple-Developer-signed on macOS, and are published on the releases page.

Native code, a web view, and how the project is built

The implementation is native C and Objective-C with an HTML and JavaScript interface, hosted in WebView2 on Windows and WKWebView on macOS. The repository layout reflects that split: an `AppSandbox.sln` with Visual Studio project files for the Windows side, an `AppSandbox.xcodeproj` for the macOS side, a shared `AppSandboxCore.vcxproj`, plus `src/`, `tools/`, `vendor/` and `web/` directories. There is a `THIRD-PARTY-NOTICES.md` alongside the MIT licence, which matters given how much third-party code is vendored for the graphics and kernel components. The maintenance record is short and recent: v0.1.7 added Vulkan DLSS on 2026-09-15, v0.1.8 added GPU selection on 2026-09-16, and v0.1.9 brought more NVIDIA API support on 2026-09-22, with the last push on 2026-09-22. The version numbers are still pre-1.0, so expect the interface to move.

Editorial conclusion

App Sandbox fits a developer who needs a clean guest desktop on Windows 11 Home without a Pro licence, or a team running several computer use agents each in its own VM. It is the wrong choice if you need cloud-provisioned VMs, since the daemon drives only the host it runs on, or if you need a reproducible CI fleet without your own runner. Before your first boot, change the guest credentials from the documented defaults of user and test123, and confirm the GPU path by running gpu-test.exe inside a Windows guest.

Frequently asked questions

Official sources

1. jamesstringer90/appsandbox on GitHub
2. License: MIT
3. Project website
4. README
5. Releases