
Erstellen Sie ganz einfach vollständige virtuelle Maschinen, die für Entwicklungs- oder Computernutzungsmodelle in einer Sandbox gekapselt sind.
App Sandbox ist eine Virtual-Machine-App für Windows und macOS mit Fokus auf Leistung und Benutzerfreundlichkeit.
Windows-Funktionen:
asb.py) zum programmatischen Erstellen und Steuern GPU-beschleunigter VMsMac-Funktionen:
asb.pyAnforderungen: Windows 11 mit einem x64-Prozessor oder macOS Tahoe (M-Serie)
App Sandbox erstellt und betreibt vollwertige Desktop-VMs — Windows 11, Ubuntu und macOS. Es ist kostenlos und Open Source (MIT) und wird als vorkompilierte Binärdateien (EV-signiert unter Windows, Apple-Developer-signiert unter macOS) auf der Seite Releases verteilt. Die Steuerung erfolgt auf zwei Wegen: über eine grafische Oberfläche oder programmatisch über einen Headless-Daemon mit einem abhängigkeitsfreien Python-SDK (asb.py). In beiden Fällen wählst du ein Betriebssystem, verweist auf ein Installationsabbild, und App Sandbox bereitet die Festplatte vor, führt eine unbeaufsichtigte Installation durch und startet den Gast. Du stellst eine Windows- oder Ubuntu-ISO bereit; macOS-Gäste laden ihr Wiederherstellungsabbild automatisch herunter. Es läuft auf einem Windows-11-PC (x64) oder einem Apple-Silicon-Mac, einschließlich Laptops.
Läuft unter Windows 11 Home, ohne Hyper-V. Unter Windows nutzt App Sandbox weder Hyper-V noch den Hyper-V-Manager; es erstellt und betreibt VMs über die APIs des Windows Host Compute System (HCS) und des Host Compute Network (HCN), die nur das Feature Virtual Machine Platform benötigen. Hyper-V ist auf Windows 11 Pro und Enterprise beschränkt, während die Virtual Machine Platform unter Windows 11 Home verfügbar ist — eine Windows-11-Pro-Lizenz ist also nicht erforderlich. Die Virtual Machine Platform ist dasselbe Windows-Feature, das auch WSL2 verwendet.
Wofür du es verwenden kannst:
Headless-API.
appsandbox.exe --headless
(oder sudo /Appsandbox.app/Contents/MacOS/AppSandbox --headless unter macOS) startet einen Daemon, der einem einzigen Besitzer vorbehalten ist, der denselben Kern wie die GUI hostet und ihn als Docker-artige lokale HTTP/JSON-API auf 127.0.0.1 bereitstellt, auf beiden Plattformen identisch. Das nur auf der Standardbibliothek basierende Python-SDK (asb.py) kapselt diese API: Erstelle GPU-beschleunigte VMs (GPU-PV ist eine Erstellungsoption namens gpuMode), stelle SSH über einen automatisch bereitgestellten Schlüssel her (Windows-, Ubuntu- oder macOS-Gäste), erstelle Snapshots und Branches, öffne die Live-Anzeige und betreibe mehrere gleichzeitig — wie viele parallel laufen, ist durch CPU, RAM und GPU-Speicher des Hosts begrenzt, nicht durch eine feste Grenze. Der Daemon ist auf einen einzelnen Host beschränkt — er betreibt VMs auf der Maschine, auf der er läuft, und stellt keine Cloud-VMs bereit; für CI führe ihn auf einem selbst gehosteten Runner aus. Die Bereitstellung einer VM führt eine vollständige unbeaufsichtigte Installation durch; Snapshots, Branches und Vorlagen (nur Windows) starten eine neue VM aus einem bereitgestellten Zustand, statt neu zu installieren. Eine VM bleibt bestehen, bis sie gelöscht wird. Ein Snapshot ist ein Prüfpunkt des Festplattenzustands, der bei gestoppter VM erstellt wird, und ein Branch erzeugt daraus eine beschreibbare Festplatte, um abweichende Aktionen auszuführen. Die vollständige API-Referenz und ausführbare Beispiele findest du in tools/headless-api/.
So funktioniert es: Dieses Repository soll auch ein funktionierendes Beispiel dafür sein, vollständige Desktop-VMs programmatisch mit den Windows-HCS/HCN-APIs und Apples Virtualization.framework zu erstellen. Unter Windows übermittelt App Sandbox ein manuell erstelltes HCS-Maschinendokument an computecore.dll / computenetwork.dll — die HCS/HCN-Ebene, die auch WSL2 und Windows Sandbox zugrunde liegt — anstatt über den Hyper-V-Manager zu gehen. Für die GPU-Beschleunigung wird GPU-Paravirtualisierung (GPU-PV) verwendet, um die im Host installierte GPU mit dem Gast zu teilen — derselbe Weg wie bei WSL2, also kein dedizierter Passthrough (kein VFIO/IOMMU, keine zweite GPU). Windows-Gäste erhalten DirectX 12, OpenGL, Vulkan, CUDA und OpenCL; Ubuntu-Gäste dasselbe ohne DirectX; macOS-Gäste Metal. Ein benutzerdefinierter IddCx-Indirect-Display-Treiber und ein virtuelles Audiogerät übertragen Bildschirm und Ton; Gast↔Host-Zwischenablage, Audio, Eingabe und SSH laufen über Hyper-V-Sockets. Gastfestplatten werden von einem im Repository enthaltenen Tool erstellt, das ext4, squashfs, qcow2 und VHDX unterstützt. Unter macOS verwendet App Sandbox Apples Virtualization.framework (VZVirtualMachine, VZMacOSInstaller) über virtio-vsock. Unter Windows erreichen Linux-Gäste (Ubuntu) die GPU über ein benutzerdefiniertes DRM/KMS-Kernelmodul (asb_drm), Microsofts WSL2-dxgkrnl und einen benutzerdefinierten Mesa-Build. Die Apps sind in nativem C / Objective-C mit einer HTML/JS-Oberfläche geschrieben (WebView2 unter Windows, WKWebView unter macOS).
[Windows] Hotkeys aktivieren oder VM-Audio stummschalten: Verbinde dich mit der VM und klicke mit der rechten Maustaste auf die Titelleiste der Verbindung
[Windows] Du benötigst einen leistungsstarken Remote-Desktop, um aus der Ferne auf deine VM zuzugreifen? Phaze funktioniert gut
[Windows] Du kannst überprüfen, ob die GPU-PV-Treibereinrichtung funktioniert, indem du gpu-test.exe in deiner App-Sandbox-Windows-VM ausführst. gpu-test.exe zeigt ein Fenster mit 6 rotierenden Würfeln, die jeweils eine andere Rendering-Engine verwenden (D3D9, D3D10, D3D11, D3D12, OpenGL und Vulkan). Wenn eine oder mehrere fehlschlagen, wird für diese Rendering-API kein rotierender Würfel korrekt angezeigt. gpu-test.zip. Hinweis: Eine erfolgreiche Rendering-API bedeutet, dass die GPU-PV funktioniert hat, aber manchmal sind Spiele oder Apps so programmiert, dass sie das GPU-PV-System nicht korrekt erkennen und trotzdem einen Fehler anzeigen.
AppSandbox ist unter der MIT-Lizenz lizenziert — Copyright (c) 2026 James Stringer.
Es enthält Komponenten von Drittanbietern, die nicht unter der MIT-Lizenz stehen und ihre eigenen Bedingungen behalten — insbesondere den Microsoft-WSL2-GPU-Treiber dxgkrnl (GPL-2.0) und den eingebetteten XZ-Decoder (0BSD). Die vollständige Liste findest du in THIRD-PARTY-NOTICES.md. AppSandbox' eigenes Linux-DRM-Kernelmodul (tools/linux/asb_drm/) ist unter MIT ODER GPL-2.0 dual-lizenziert, damit es die GPL-only-Symbole des Kernels auflösen kann.
Über meine eigenen Erfahrungen mit der Entwicklung von Easy-GPU-PV hinaus fand ich NanaBox eine wirklich hilfreiche Ressource, um HCS zu verstehen.
James Stringer — Autor von Easy-GPU-PV.