Which repos deserve your time?

The practical local default when you need a container workflow now.

Rootless operation is first-class, the project is long-lived, and its documented limitations are unusually explicit. For an agent, it is a useful reduction in privilege—not a replacement for a VM when the workload is genuinely hostile.

Project ↗Rootless caveats ↗

A small, proven primitive for wrapping a single local process with a visible filesystem and namespace policy.

It is not a whole sandbox platform and deliberately leaves policy composition to you. That narrowness is a virtue when a launch policy is audited, versioned, and tested. It is a poor fit if you need cross-platform GUI or VM orchestration by itself.

Repository ↗Docs & issues ↗

A valuable building block for self-restricting Linux processes, especially when paired with namespaces and a dedicated account.

Landlock is not a container, VM, firewall, or secrets manager. It constrains filesystem and, in newer ABI levels, network actions according to kernel support. Treat support level and graceful degradation as part of deployment validation.

Project ↗Kernel docs ↗

The boring, capable answer when an Ubuntu VM is enough and you value a maintained developer workflow.

It uses the native virtualization path per OS—Hyper-V on Windows, KVM on Linux and QEMU on macOS. It is VM management, not a fine-grained agent policy engine; separate project sharing, credentials, and egress still need deliberate design.

Project ↗Repository ↗

A serious isolation runtime for Linux workloads, with a compatibility and operational cost worth proving on your exact tools.

gVisor reduces direct host-kernel exposure by implementing a substantial system interface in userspace. Its open issue traffic is large because it is heavily used; the actionable recurring concern is compatibility and performance edge cases, including networking, checkpoint/restore, GPU and startup behavior—not a lack of engineering activity.

Project ↗Security model ↗

Technically important, purpose-built microVM infrastructure—not an all-in-one desktop sandbox.

The design is mature for its intended Linux/KVM service environment. Agent builders should price in guest image construction, networking, snapshots and observability. The official snapshot documentation itself flags connection loss, clone identity issues, disk capacity, and preview-status differential snapshots.

Project ↗Snapshot limitations ↗

A well-scoped, active VMM for modern cloud workloads; a strong phase-two backend, not turnkey sandbox UX.

The local checkout documents a deliberately minimal Rust VMM with seccomp, threat-model and snapshot material. Its boundary is meaningful only after the caller safely supplies kernel, rootfs, devices, virtiofs mounts, egress and lifecycle handling. Expect integration engineering.

Project ↗Repository ↗

A serious way to give standard containers VM-backed isolation when your platform already speaks OCI/containerd.

Kata maps workloads to lightweight VMs while retaining OCI/CRI compatibility. It is an integration win for container platforms but adds hypervisor, guest, runtime and networking moving parts. Kata’s own docs correctly say VM isolation alone does not deliver whole-system multi-tenancy.

Project ↗Isolation caveat ↗

The most interesting local secret-swapping mechanism in this guide—and still a tool to trial behind an outer boundary.

nono can provide a phantom token to an agent and swap it at an authorized route, so the agent need not receive the real credential. The project has active development and a public migration toward 1.0, but API/registry movement is still occurring. Its authors also frame it as a sandbox layer, not escape-proof magic.

Repository ↗Project ↗

Borrow the design vocabulary. Do not yet rely on it as a security boundary.

Its local README says exactly that: early preview, profiles can be overly permissive, and should not be treated as security boundaries. The multi-backend schema and lifecycle concepts are useful reference material. Recent issues show the team actively hardening Windows paths, which is encouraging but confirms the early label.

Repository ↗Recent hardening issue ↗

A compelling agent-shaped microVM experience, but beta is an engineering status, not a marketing adjective.

The local research records promising cross-platform microVM, snapshot, branching and OCI-image ideas. That makes it worth a time-boxed evaluation—not a foundational dependency until the exact host/guest matrix, upgrade path, failure recovery and long-run behavior are exercised.

Project ↗Directory context →

A good idea with a clean API shape and limited adoption evidence so far.

It is noteworthy for avoiding Docker/root assumptions and exposing desktop-capable QEMU guests, snapshots and lifecycle operations. It has not yet earned the confidence of an operationally mature, widely deployed sandbox substrate. Use as research or a contained prototype.

Repository ↗Where it fits →

Unusually relevant HCS/HCN and GPU-PV reference code; not a dependency recommendation from this evidence.

The local source describes full desktop VMs, snapshots, a loopback HTTP API and Windows 11 Home support through HCS. It is useful for learning how host compute APIs, virtual displays and VM lifecycle can work. Local attempts reportedly failed, so its path needs a reproducible system-specific trial before adoption.

Repository ↗Local evidence ↗

A useful map of Windows HCS constraints and lifecycle gotchas, with a narrower audience than the agent-sandbox problem.

Active source and detailed Windows-focused documentation are positives. Elevation, generation/firmware constraints and niche host requirements make it less attractive as a portability dependency. It is more valuable as reference for native VM plumbing.

Repository ↗Configuration ↗

Useful when your agent needs to drive a desktop. Neither should be confused with the security boundary around that desktop.

The local CUA checkout has extensive work on fleets, desktop drivers and test fixtures; Agent Desktop focuses on accessibility-driven automation. Both help explain the computer-use layer. Put them inside a deliberately provisioned VM/container or remote environment, rather than granting them host control by default.

CUA ↗Agent Desktop ↗

The likely maintenance cost exceeds the evidence of a healthy dependency.

The local clone’s last commit is April 2026, it has no releases in the captured evidence, and its Electron/GPL posture does not fit a lightweight proprietary-friendly foundation. Its desktop/VNC product ideas are fair inspiration; the dependency decision should be no until activity and support evidence change.

Repository ↗Local evidence ↗

This is the inverse of a sandbox: a route to control a Windows host.

It may be useful later as a deliberately supervised automation surface. It does not constrain an agent’s authority or isolate its filesystem, processes or credentials. Putting it in a sandbox shortlist would be a category mistake.

Repository ↗Correct placement →