Personal hands-on notes: what we ran ourselves, and what happened
The rest of this guide is built from documentation, advisories and published measurement. This page is the opposite: one person, a handful of machines, and a memory of what worked. It is here because "I tried it and it was annoying" is genuinely useful information — as long as nobody mistakes it for evidence.
Everything below is a personal report from the author's own machines, recorded with the tool name and the symptom that stuck. Sample size: one. Host mix: Fedora inside VMware, a Windows host, WSL2, and Ubuntu on a Linux kernel. Nothing here has been repeated, controlled, benchmarked or reproduced by anyone else, and several entries are impressions rather than measurements.
None of it overrides the assessments elsewhere in this site, and none of it is an assessment. No tool here was ranked, and no tool here was penetration-tested: this page is not a verdict, and it is not a claim about how strong any boundary is. Where a note agrees with the documented evidence it is corroboration; where it disagrees, the documentation and the issue tracker win. The point of publishing it is that the gap between "works per the README" and "works on my laptop" is the single most common thing readers write in about.
What we tried, and how it felt
| Tool | The personal note | What it does and does not tell you |
|---|---|---|
| gVisor app kernel |
Worked on Linux and inside WSL, but took manual effort to get going; testing was limited to a few workloads rather than a real agent session. Worth revisiting. | Corroborates the documented compatibility complaint (ENOSYS surprises, workloads that
need io_uring or exotic ioctls) and says nothing about whether the boundary holds — one
person's partial session is not an isolation test. The security record is
measured elsewhere, not here. |
| Lima full VM |
Worked well in Ubuntu under WSL2, and on Linux generally — not only on a Mac. It is a full virtual machine and it costs meaningful RAM relative to a container lane, which is why it did not stay running here. An attempt to use Lima on a Windows host was not successful. | A useful correction to Lima's macOS-only reputation (see Full VMs) and a data point on resource cost. The RAM observation is an impression, not a measurement against a baseline, and guest memory is a configuration choice. The Windows-host attempt is one person's experience: Lima's own documentation does claim Windows-host support through drivers it labels experimental, so the honest statement is "this did not work for me", not "it does not work". |
| SmolVM microVM |
Two unrelated sandbox projects share the name, and both install a binary called
smolvm — smol-machines/smolvm and CelestoAI/SmolVM. One of them
worked here; which one was which stopped being obvious several times, and a document written for one
was followed as if it described the other. Verify the repository before you follow any
SmolVM documentation, issue or benchmark. |
This is a real, checkable problem rather than a quality judgement: both projects' public
repositories exist, both ship a smolvm command, and third-party write-ups explicitly
disambiguate them. It is also a warning about how easily adoption evidence gets mixed across similarly
named projects — a category the guide's method treats carefully. |
| nono secrets / process sandbox |
Worked on Linux. The secret filtering and substitution — the agent sees placeholders while the real credential is injected at the boundary — is the most useful idea encountered in this whole project, and it is why the pattern recurs throughout Secrets. The project itself is early, and its public record includes an escape-class advisory on Linux (a Landlock policy that allowed the per-user systemd D-Bus socket, fixed in 0.55.0) plus issue reports about leaks from its own runtime directories. So: copy the pattern, and do not treat nono as a trusted isolation boundary on current evidence. | Corroborates the guide's position that credential brokering is the highest-value idea in the field, and the guide's caution about adopting the sandbox around it. The advisory is a primary source; the sandbox's behaviour under an adaptive attacker is not something these notes tested. See the nono assessment. |
| VMware Workstation full VM |
Free, and it works. Occasional VM boot failures, usually after a configuration change or a host update — enough that known-good snapshots stopped being optional and became the workflow. | Matches the general guidance in Full VMs: snapshot after provisioning, before fanning agents out, and keep a known-good snapshot you have actually booted. A boot failure that is annoying in a desktop VM is a hard stop for a per-task sandbox, which is an argument for keeping a warm base rather than booting per task. |
| VirtualBox full VM |
Works similarly to the above, with the same shape of experience: reliable enough day to day, not something to leave unwatched, and snapshots doing the real work. | Nothing beyond the general VM trade-off. Neither desktop hypervisor is documented here as a security boundary in its own right; what matters is the guest and the shares you expose. |
| Hyper-V Windows |
On a Windows host the hypervisor itself is fine, but console keyboard and mouse handling — and peripherals generally — can be awkward when you are driving a guest desktop. Session and input redirection is where the friction lives, not the virtualisation. | A usability observation about viewing and driving a guest desktop, which is directly relevant to computer-use: how you get eyes and hands onto a guest is part of whether the setup survives a real workflow. It is not a statement about Hyper-V's security boundary, which Microsoft services properly. |
| Podman container |
Reliable, every time, on the machines tried — including on Linux, inside WSL2, and on Windows where its Linux engine runs in WSL. Clear-eyed about what it is: a container system, not a VM, so it shares the host kernel and is a blast-radius boundary rather than a hypervisor one. | The most reproducible report on this page, and consistent with the guide's recommendation: Podman is the default, and it is not a tier-3 isolation boundary. "Reliable" here means "it ran", not "it contained something hostile" — that was never tested. |
The local test log: 2026-09-20, on two hosts
Entries are kept verbatim in LOCAL-TESTS.txt next to the site source. That day's work ran on
two very different hosts, and the difference explains most of the results, so they are reported separately.
Host A · Fedora 44 guest inside VMware
4 vCPU, 6.1 GiB RAM, and no /dev/kvm — nested virtualisation was not
available. Half the results below are facts about this host rather than about the tools.
Host B · Ubuntu 26.04 under WSL2
Hardware virtualisation exposed: /dev/kvm present and openable by the
test user. Host AppArmor was unavailable under this WSL kernel, which is worth knowing before reading any
LSM-dependent claim. This is the host where a kernel boundary actually ran.
Host B — where the hardware boundary was available
| Tool | Version | Result | Reading |
|---|---|---|---|
| Incus (LXC containers) | 6.0.5 | An unprivileged Alpine 3.22 LXC container was created and ran. A static-address private NAT bridge worked, and a snapshot/restore on directory storage worked. | The container path works, and it is worth being precise about what it is: LXC containers do not use KVM and share the host kernel — the isolation is namespaces, cgroups and an unprivileged user namespace, not a hypervisor. Directory storage also proves the point that snapshot cost is a storage-driver question: it worked, but this is the backend where snapshots are ordinary rather than near-free. |
| Incus (bridge setup) | 6.0.5 | Creating the default DHCP bridge failed until an existing UDP/67 listener was accounted for. A private NAT bridge with static addressing worked. | A host port conflict, not an Incus container failure — worth recording because the error appears at the same moment as instance creation and is easy to misread as one. It is also the distinction to keep straight in Incus: the container path above is LXC and never touches KVM, while Incus VM instances are the QEMU/KVM ones. |
| BoxLite (CLI) | 0.10.2 (released) | An alpine:3.22 KVM microVM booted with its own 6.12-series guest kernel.
Guest command execution, NAT/DNS, and root-filesystem persistence across stop/start all worked.
/tmp was transient across a restart. |
The most informative result of the day, and the narrowest in scope: one host, one image, one
session. It shows the packaged runtime does what its documentation says on a host with
/dev/kvm, that the OCI-image workflow runs inside a guest kernel rather than beside it, and
that persistence is per-box rather than global. The transient /tmp is the guest's tmpfs
mount, not a bug — and the kind of detail that bites anyone who stores work there.
Do not read this as a security assessment or a benchmark. |
Host A — where it was not
| Tool | Version | Result | Reading |
|---|---|---|---|
| Podman | 5.x | Passed — pulled alpine:3.22 and printed podman-ok. |
The one boundary we actually crossed and came back from, and a shared-kernel one at that. This is the only row here that is a test result rather than a note about a missing host feature. |
| Incus | 6.23 | Daemon, API and network came up (btrfs pool plus incusbr0); incus
launch of an Alpine container failed with "System doesn't have a functional idmap
setup", with the root and user subuid/subgid ranges present. Incus also logged KVM unavailable for
VM instances. |
A manager that installs and initialises cleanly is not an isolation layer you can use. Worth recording that the failure was in subordinate-ID mapping rather than in the storage or the network, because it is the kind of setup detail the documentation assumes away — and that the same tool worked on Host B with a working idmap setup. |
| Lima | 2.2.0 (Linux x86_64 release) | An Alpine QEMU instance booted through networking under TCG software emulation; SSH and guest-agent initialisation never completed in a practical time. Instance removed. | Lima runs on Linux — this is the test behind that correction. The slowness is TCG, not Lima: with
no /dev/kvm there is no hardware acceleration, and a software-emulated guest is too slow
for interactive agent work. |
| BoxLite (Python SDK) | 0.10.2 | Installed and imported successfully; SimpleBox initialisation aborted with
"unsupported: KVM is not available on this host." |
The documented prerequisite, enforced with a clear error — which is better behaviour than a silent fallback to something slower. It is still a refusal to run, so nothing about BoxLite's isolation was observed on this host. The same version's CLI ran a microVM on Host B. |
Most results were limited by a missing host feature, not by the tools, and the one hypervisor-isolated run was a single image on a single host. Nothing on this page shows that any tool is broken or insecure, and nothing here validates or invalidates an isolation claim — we never attacked a boundary. In particular, every microVM security statement in this guide remains supported by documentation and published reporting, never by our own execution.
Three things worth knowing before you start. First, /dev/kvm is a hard
gate: without it, the whole microVM family — and hardware-accelerated anything — is off the
table, and the useful move is to change hosts or fall back to a container boundary. Second,
installation success is not a boundary: Incus, Lima and BoxLite all installed cleanly on
Host A and none of them gave us a working sandbox there. Third, the container/VM distinction is
not academic: the thing that finally worked without KVM was LXC, precisely because it shares the
kernel and needs no hypervisor.
What these notes changed in the guide
Lima's platform statement
The Full VMs chapter no longer describes Lima as a macOS-only tool. It manages real Linux VMs on Linux hosts, which is how it works in Ubuntu under WSL2; the Windows-host drivers are documented but experimental, and the note about them not working here is kept as anecdote.
Incus's two isolation levels
The same chapter now says plainly that Incus containers share the host kernel and do not use KVM, while Incus VMs are real virtual machines. A local test that runs an LXC container successfully is not evidence of a hypervisor boundary.
BoxLite and crosvm, cautiously
BoxLite OSS is described in the microVM chapter as a local KVM/Hypervisor.framework runtime that runs OCI workloads inside a per-box VM, and carries an assessment; the CLI result above is recorded as a narrow smoke test. crosvm's role in ChromeOS and Android is stated as an adoption and maturity signal, verified against its own README and documentation — never as a security guarantee.
Corrections are welcome, and the right fix is a primary source — including a primary source that contradicts something on this page. If you have run one of these tools on hardware where it actually worked, or on hardware where it did not, that is exactly the evidence this guide is short of.