How this guide decides what to trust.

Method

Risk scanner, applied consistently

The repository assessments use the local Repo Adoption Risk Scanner process: establish identity and supported platforms; search for high-severity failure families; group recurring symptoms rather than counting random issues; inspect maintainer response; normalize complaints by apparent usage; and state evidence confidence. Stars are not a reliability score.

A recommendation is about likely adoption pain for a sandboxing use case. It is not a penetration test, a security guarantee, or a claim that a project has no vulnerabilities.

Local evidence

Read before external research

The guide began with the workspace’s local collection: the cleaned sandbox survey, the local index, the saved Please Do Not Escape inventory, author notes, and source/README inspection of cloned repositories including MXC, Cloud Hypervisor, Multipass, App Sandbox, NanaBox, CUA, Agent Desktop, EdgeBox and Windows-MCP.

• Local inventory: INDEX.md and sandboxes-research-cleaned.mdUsed as a discovery funnel, not treated as final evidence.
• Local source evidence: current checkout READMEs, release notes, policy/threat-model documents and Git history where available.Used to confirm scope, explicit maturity warnings, supported platforms and local activity.
• Saved master list: pleasedonotescape.com ↗Used to find candidates, then narrowed rather than deep-reviewing hundreds of entries equally.

Primary technical sources

What the primitives actually say

• Podman: rootless limitations ↗Documents low-port, networking, subuid/subgid, resource and filesystem constraints.
• gVisor: architecture and security introduction ↗Primary explanation of its application-kernel approach.
• gVisor: security model ↗Useful reminder that no one layer eliminates every host attack surface.
• Firecracker: snapshot support and limitations ↗Documents networking, identity, latency, disk and preview caveats.
• Kata Containers: quick start & isolation scope ↗Explicitly distinguishes VM-backed workload isolation from complete multi-tenancy.
• Linux kernel: Landlock userspace API ↗Primary reference for policy semantics and ABI evolution.
• Microsoft: WSL documentation ↗Primary entry point for the Windows-hosted Linux VM environment.
• Microsoft: Windows Sandbox documentation ↗Primary entry point for disposable Windows guest configuration.

Repo & complaint signals

Evidence of adoption pain

For mature and actively used projects, issue counts alone are deliberately not used as a verdict. The review looks for repeated high-severity classes across releases, current open problems, documentation around limitations, and signs that fixes are tested or regress. Examples surfaced in the current pass:

• gVisor ARM64 startup-latency report ↗Concrete scale/performance evidence; not a general condemnation of gVisor.
• Podman-in-WSL compatibility issue ↗Illustrates why a Windows/WSL path needs a real trial, especially nested containers.
• MXC Windows working-directory hardening issue ↗Matches the project’s own warning that preview policies are not yet a boundary.
• Firecracker issue tracker ↗Shows active triage alongside known networking, snapshot and host-topology work.
• nono repository ↗Source for current namespace migration and pre-1.0 API-stability statement.

Secrets

Broker, don’t hand over

Secret swapping is presented as a pattern, not an endorsement of one startup-shaped repo. The useful design is: the agent gets a capability or placeholder; a separate trusted service checks a narrow policy and injects the real credential at the last responsible moment; the agent cannot bypass that route or read the vault.

• nono ↗Agent policy and phantom-token credential proxy approach.
• Agent Vault Proxy ↗Loopback proxy that fetches and injects vault credentials just in time.
• Infisical Agent Vault ↗Open credential-broker option for agent traffic.
• CredProxy ↗Useful explicit caveat: proxy control alone fails if the agent can still read files or directly access secrets.