How this guide was researched
Every claim in this guide comes from a primary source where one exists: vendor documentation, repository code and metadata, issue trackers, release notes, security advisories, public discussion threads, or the independent comparative security study of AI sandbox engines. This page explains the procedure, the sources, and — importantly — what was not verified.
The procedure
Repository assessments follow a fixed procedure, applied identically to every project so that the comparisons mean something. It is an adoption-risk scanner, not a security audit: it estimates the practical risk of adopting a project today and looks for recurring failure patterns that popularity metrics hide.
1 · Establish identity and state
Canonical repository, official documentation, licence, latest release and cadence, whether the project is active, archived, moved or mid-rewrite, and which platforms and installation methods actually exist. Forks and similarly-named projects are treated carefully so bugs are not mixed across them.
2 · Hunt failure families
Search the issue tracker, discussions and release notes for variants of crash, hang, data loss, corruption, upgrade-broke, regression, resource leak, authentication failure, and platform-specific breakage. Then search for related wording and duplicates — one report is not a pattern.
3 · Cluster, and date
Group reports that share a subsystem or root cause even when the error text differs. For each family, record the earliest and latest evidence, the number of independent reports, the affected versions and platforms, whether a fix exists, and whether the problem reappeared. A family that recurs across releases matters far more than a pile of unrelated issues.
4 · Look outside the repository
Firsthand reporting elsewhere: discussion threads, mailing lists, blog posts, security advisories, independent studies, and other projects that depend on it. The goal is concrete symptoms mapped back to failure families, not sentiment analysis.
5 · Measure maintainer behaviour
Acknowledgement time, time to a first fix, time to a release, whether duplicates accumulate for months, whether issues close without resolution, and whether the architecture changed when patches kept failing. Fast closure is not automatically good: "duplicate" or "stale" without a working resolution is not a fix.
6 · Normalise popularity
Complaints relative to apparent usage, not raw counts. Where a trustworthy denominator does not exist, the assessment says so rather than inventing one. A project with real adoption and predictable problems is frequently safer than an unknown repository with a clean-looking tracker.
The seven procedural steps and the automatic red flags — data loss, upgrades that strand users, recurring startup failures requiring state deletion, unbounded growth, fixes followed by recurrence, security behaviour with poor disclosure — come from the Repo Adoption Risk Scanner skill used to evaluate every project here.
It does not produce a numeric score. The underlying procedure defines six dimensions that a formal scan would rate — runtime reliability, data safety, upgrade safety, recovery quality, maintainer response and operational predictability — but collapsing them into one number destroys the information that makes them useful, and an "8.7/10" would imply a precision no public evidence supports. Ratings here are categories with prose justification, and the security discussion is kept separate from the reliability discussion, because a project can be impeccably maintained and still have an architectural flaw that matters for your threat model.
Sources, ranked by how much weight they were given
| Priority | Source type | Used for |
|---|---|---|
| 1 | Official product documentation, READMEs, security models | The execution model, network policy, credential handling, persistence and integrations. Everything factual about a tool comes from here first. |
| 2 | Vendor and independent engineering posts about containment | The best primary material on agent threat models: why sandboxing needs approvals and network control, what breaks on each platform, and what the vendor knows it does not do. |
| 3 | Security advisories, CVEs and vendor advisories | Escape classes, credential exposure, fail-open bugs, and the difference between "no known bugs" and "nobody has looked". |
| 4 | Issue trackers, discussions and release notes | Failure families, recurrence over time, and maintainer response patterns. |
| 5 | Independent comparative studies | Where a measurement exists, prefer it to an opinion. One study is leaned on heavily and cited by name throughout. |
| 6 | Public discussion: forum threads, community archives, blog write-ups | Real-world frequency and impact, the gap between documented behaviour and lived experience, and the questions people are actually asking. |
| 7 | Repository metadata via the GitHub API | Stars, forks, open issues, creation date, last push, licence, archived status. Descriptive only — never used as a quality signal. |
| 8 | Curated datasets and lists | Inventory and discovery. Where a dataset carried an evidence trail, it was followed back to the primary source rather than quoted. |
| 9 | Local test runs and the author's own reports | What happened on one specific machine, and only that. Anything sourced this way is labelled as anecdote on the Field Notes page, is never used to support a verdict, and is never generalised into a claim about a tool. It ranks last on purpose: a refusal to run because /dev/kvm is missing is a fact about the host, not about the sandbox. |
Named sources worth reading yourself
- AI Code Sandboxes: A Comparative Security Study (arXiv 2606.08433, June 2026) — five products, six engine-level axes, one host, with per-axis orderings and an explicit refusal to produce a composite score. The companion repository publishes the harness.
- please do not escape (pleasedonotescape.com) — an evidence-carrying dataset of agent sandboxes in which every non-identity field is a claim traceable to a primary source, with an explicit evidence level. The three-tier threat model used on this site comes from the same thinking.
- Vendor containment engineering posts from the major agent vendors — the most candid public documents about what sandboxing an agent on Windows, macOS and Linux actually involves.
- The Show HN and Ask HN threads on agent sandboxing, which supplied both discovery and a large amount of practical detail that no documentation contains. Discussion threads are treated as evidence of real-world experience, not as authority.
- Curated taxonomies and awesome-lists for inventory.
restyler/awesome-sandbox,webcoyote/awesome-AI-sandboxandbureado/awesome-agent-runtime-security. - Project documentation for the newer runtimes — the BoxLite OSS pages
and repository (boxlite.ai/oss,
github.com/boxlite-ai/boxlite: README, FAQ, architecture notes and the supported-platform matrix) and the crosvm Book (crosvm.dev/book, including its snapshotting page, which is why snapshot support is described there as experimental rather than absent). Both are vendor-authored sources, and both are treated as claims about the vendor's own product until something independent corroborates them. - Published adversarial research on computer-use agents, browser agents and container escapes — used wherever a number existed rather than an adjective.
- Our own field notes — a small, explicitly anecdotal log of what the author ran on personal machines, published on the Field Notes page with the local test results. It is included because "it did not work on my laptop" is reader-relevant information, and it is quarantined from the assessments because a sample of one cannot support a verdict.
The local repositories we actually opened
This guide began from a working directory containing eleven checked-out repositories. Each was inspected at the level the question required: README, licence, commit history, and code where the claim depended on it — and, for the runtimes in the Field Notes log, installed and run. Three sources beyond that directory were read in full rather than summarised: the BoxLite OSS documentation (README, FAQ, architecture notes and platform matrix), the crosvm Book and its repository README, and Lima's own documentation on VM types and host support. Each is vendor-authored, and each is treated as a claim about that vendor's own product until something independent corroborates it.
| Repository | What it is | Verdict |
|---|---|---|
| sbx / Sandbox Studio | A local Rust + Tauri prototype: rootless Podman lanes, embedded terminals, checkpoints, fan-out. | Not a dependency — it is the application this research feeds. Its validation notes are unusually good: five lanes in ~3 s warm, no host mounts, network off, checkpoint/restore verified, and an explicit statement that containers share the host kernel and that this is not a security certification. |
| mxc | Microsoft Execution Containers. | Steal the JSON policy schema and the per-Windows-build enforcement matrix. The README says plainly that no profile is a security boundary yet. |
| cloud-hypervisor | Intel-led Rust VMM. | Committed the same day as this audit, shipping its 52nd major release, deployed at AKS and Fly.io with a same-day coordinated CVE response. The phase-two strong-isolation provider. |
| appsandbox | HCS/HCN desktop VMs with GPU-PV on Windows 11 Home, plus a headless HTTP/JSON API. | The right architecture and the right API shape; it also would not run here regardless of configuration, which matches its strict host requirements and its single-maintainer risk. |
| NanaBox | Hyper-V-lite VMs built on the Host Compute System API with a portable JSON VM format. | Actively maintained but needs elevation and is Gen2/UEFI only. Its README is the best public documentation of Host Compute System gotchas. |
| wsl-ui | A Tauri + React WSL distribution manager. | GPL-3.0, so patterns rather than code. Its live-status dashboard and distribution-parsing crate are the shape a Windows provider wants. |
| agent-desktop | Rust CLI driving applications through accessibility trees. | Excellent engineering, released regularly, and macOS-only today. A future computer-use component, not an isolation boundary now. |
| cua | Computer-use suite: drivers, local macOS VMs, cloud fleets, benchmarks. | Big, active, MIT, and Apple-Silicon-centric with a heavy cloud component. Adopt the VM path, not the host-driver path. |
| EdgeBox | Electron desktop with a containerised GUI desktop over VNC. | Last commit April 2026, no releases, GPL-3.0, and a README that injects a recommendation for an unrelated project. The UX idea is worth taking; the repository is not. |
| Windows-MCP | An MCP server giving an agent control of the Windows desktop. | Actively maintained and genuinely useful, and it runs on the host as you. It is the inverse of a sandbox and belongs in a different chapter of your architecture. |
| boxlite | An embeddable microVM runtime that runs OCI workloads inside a per-box VM. | On the host without KVM the Python SDK imported cleanly and then refused to start, exactly as its documented requirements say; on the WSL2 host with KVM, the released CLI ran an Alpine microVM end to end. Its README, FAQ, architecture notes and platform matrix are the primary sources behind the microVM chapter's BoxLite entry and its assessment. |
Data provenance and what was not verified
Provenance
- Repository metadata — stars, forks, open issues, creation date, last push, licence, archived status and language — was captured from the GitHub API in a single sweep on the date shown in the footer, covering 174 repositories. Facets such as isolation model, network policy and credential handling are editorial classifications made from each project's documentation and code, and are stated as such in the directory.
- Assessments — 29 repositories received a full write-up. Selection was deliberate rather than exhaustive: everything widely used, everything technically important, everything unusually promising for agent work, the strongest example of each architectural approach, and a set of cautionary cases worth documenting.
- Measurements are attributed inline to the study or report they came from. Where a figure is vendor-claimed rather than independently measured, it is presented as a claim.
- We did not hands-on test most of these tools. This is a research guide, not a lab
report. The exceptions are the handful of runtimes in the local test log — Podman, gVisor, Incus,
Lima, nono, SmolVM and BoxLite — attempted on two hosts, neither of them a security test bed. They
are recorded in full, dated, on Field Notes: the host with
no
/dev/kvm, where three of them could not start, and the WSL2 host with KVM available, where an LXC container and a BoxLite microVM did run. Everything else rests on documentation, advisories and published measurement rather than on our own execution, and no security claim in this guide comes from our own testing of a boundary. - No security audit was performed. Every security statement comes from a vendor's own documentation, a published advisory, an independent measurement, or a demonstrated bypass — never from our own testing of a boundary.
- Metrics are a snapshot. A project that looked stalled may have restarted, and one that looked healthy may have changed licence. Check the date before relying on any number.
- Language bias. A significant amount of the best practical detail about these tools is published in languages other than English, and search coverage of community archives is uneven.
- Selection bias is real. The set of repositories came from curated lists, a starting dataset, discussion threads and searches, which means projects with better documentation are over-represented relative to equally good projects with less.
- Some cited discussion is unreviewed. Several relevant papers are recent preprints. Where that matters, it is flagged at the point of use.
If a claim here is wrong, the fix is a primary source. The most likely places for error are the editorial facets in the directory — a project's isolation model or credential handling is sometimes ambiguous in its own documentation — and the freshness of any activity figure. Both are straightforward to correct, and correcting them makes the guide more useful to the next person who is trying to work out which sandbox to trust.