> ## Content Index > Fetch the complete content index at: https://wuu73.org/aiguide/llms.txt > Use this file to discover other available public pages before exploring further. # Sandboxes for AI Agents - URL: https://wuu73.org/aiguide/sandboxes-for-ai-agents/ - Published: 2026-09-17T00:54:06.000Z - Updated: 2026-09-20T21:32:12.000Z - Author: WUU73 - Tags: Blog ### Update 9/19/2026 - I am going to try turning this into something much better but it is half done: [https://wuu73.org/minis/sandbox-field-guide/](https://wuu73.org/minis/sandbox-field-guide/?ref=wuu73.org) ### I asked ChatGPT to research sandboxes, Because I want to make some kind of visual app, CLI commands are just annoying for me. I like to visually see whats going on. The output was pretty good so I am going to post it here. # Local Open-Source Sandboxes for Parallel AI Coding Agents: Reliability, Hacker News Sentiment, Cloning, and the GUI Opportunity ## Bottom line The space has changed substantially in 2026\. There are now many agent-sandbox projects, but **very few combine all of the properties you care about**: local-only operation, open source, Windows and Linux support, a strong isolation boundary, fast cloning/forking, safe host-folder handling, multiple coding-agent harnesses, and a good desktop GUI. The landscape is still fragmented between security primitives, VM/container managers, agent orchestration tools, and UIs. The most important discovery is that **Sculptor is now very close to the GUI concept you described**. It is an MIT-licensed local desktop app explicitly designed for parallel coding agents. Its current product page says each workspace gets its own isolated Git worktree, branch, terminal, and diff view; it supports 5+ simultaneous agents and model/provider switching. Earlier versions also emphasized containerized execution and bidirectional IDE pairing. So there is prior art and validation for the UX, but there is still room for a product whose defining feature is **sandbox-backend choice and visibly understandable security boundaries**, rather than primarily worktree orchestration. For the actual sandbox backend, I would **not select one technology and hard-wire the application to it**. The architecture should treat the sandbox as a provider: ```text Same task │ ┌──────────┴──────────┐ │ Fan-out controller │ └──────────┬──────────┘ │ ┌─────────────────┼──────────────────┐ │ │ │ Sandbox lane A Sandbox lane B Sandbox lane C ... Podman/rootless Microsandbox VM Quicksand/QEMU Claude/Codex Codex/OpenCode Claude/etc. │ │ │ workspace A workspace B workspace C │ │ │ └─────────── diff/review ────────────┘ │ host project ``` For a **first usable release**, I think your instinct is right: use **rootless Podman plus per-agent workspaces/worktrees** as the boring, dependable baseline. Podman is open source and daemonless, can run unprivileged containers, exposes a management API, and has first-class Windows clients. On Windows, Podman Machine runs the Linux engine inside either WSL2 or Hyper-V, so you naturally get an outer VM boundary around the container engine. However, the project that now looks **technically closest to the long-term backend you described is Microsandbox**. Its current repository describes a Rust-based, embeddable microVM runtime with Linux/KVM, Apple Silicon macOS, and Windows/WHP support; OCI images; live sandbox branching; snapshots; volumes; network allowlists; Rust/Python/TypeScript/Go SDKs; and no required long-running daemon. Crucially, the maintainers still label it **beta software**, which is exactly why I would integrate it as an optional provider rather than make your entire application dependent on it yet. **Microsoft Quicksand is more interesting than its \~50 stars make it look.** It is MIT-licensed, has a security policy, tests and CI structure, about 310 commits in the repository snapshot I inspected, and is specifically an async API around QEMU for AI-agent sandboxing. It supports x86-64 and ARM64 on Windows, Linux, and macOS without requiring Docker or root; host directory mounts; network isolation by default; checkpoints/revert; persistent saves; multiple Linux users; and even desktop VMs with screenshot/keyboard/mouse control. Its weakness is maturity and ecosystem evidence, not conceptual fit. My short list therefore looks like this: | Technology/project | My role for it | Confidence now | | ------------------------------------ | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | **Podman** | Default fast/container backend | **High** — mature foundation, boring in a good way. | | **Git worktrees + staged workspace** | Default fan-out mechanism for Git repos | **High** — built into Git and used by several agent UIs. | | **Microsandbox** | Strong-isolation microVM backend | **High interest, medium production confidence** — almost tailor-made for this use case, but explicitly beta. | | **Quicksand** | Cross-platform QEMU backend | **Medium-high interest** — unusually good API/defaults, but young and small. | | **gVisor** | Stronger Linux container mode | **High confidence in technology**, Linux-centric. It is **not a microVM**. | | **Kata Containers / Firecracker** | Strong Linux VM-backed mode | **High confidence in foundations**, poor fit as your first cross-platform desktop backend. | | **Incus** | Linux VM/container power-user or worker-server backend | **High confidence**, but Linux-centric for your use case. | | **VMTREE** | Later self-hosted worker-pool inspiration | **Good operational evidence**, not really a desktop sandbox library. | | **Rivet sandbox-agent** | Normalize Claude/Codex/OpenCode/etc. inside any backend | **Very interesting complement**, not itself an isolation boundary. | One correction to a common terminology confusion: **gVisor is not a microVM**. It supplies a user-space application kernel and an OCI runtime called `runsc`; applications interact with that sandbox kernel rather than directly with the host Linux kernel. Its architecture deliberately gives VM-like kernel separation without actually placing every sandbox in a hardware VM. Firecracker, by contrast, is a real KVM-based microVM VMM. ## What Hacker News actually seems to like HN discussion is useful here, but I would not treat HN points as a security score. The strongest threads repeatedly distinguish between **"interesting new sandbox"** and **"something I'd let an autonomous coding agent loose in every day."** The community is surprisingly consistent about wanting local control, simple isolation, disposable environments, easy parallelism, and a way to inspect what the agents are doing without memorizing another large CLI. Among the threads I found, this is the rough ranking by discussion traction: | Project/thread | HN traction when researched | What the discussion tells you | | -------------- | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Juggler** | \~280 points / 119 comments | Strong appetite for a real GUI around coding agents. Juggler is more agent UI than sandbox runtime, but the amount of engagement is important evidence for your visual-management idea. | | **Clawk** | \~226 points / 158 comments | Extremely relevant discussion of local sandbox approaches. Commenters compared QEMU/KVM, Gondolin/libkrun, bubblewrap, gVisor, Firecracker, Podman and Incus rather than converging on one winner. | | **Tilde.run** | \~205 points / 133 comments | Lots of enthusiasm for local/open-source execution, but also obvious "sandbox fatigue": people want a crisp reason a new project is better than the growing pile of wrappers. SmolVM, Microsandbox and BoxLite came up organically. | | **Sculptor** | \~176 points / 85 comments | Strong validation for a parallel-agent desktop UI. Users liked isolation and parallelism; discussion also exposed concerns about weight/complexity and how much UI is actually useful. | | **FleetCode** | \~103 points / 52 comments | Positive interest in a provider-neutral multi-agent UI based on Git worktrees; comments also pointed toward DevContainers/DevPod-style isolated environments as the natural next step beyond bare worktrees. | | **ERA** | \~62 points / 19 comments | Positive technical interest around local VM isolation/libkrun and fast startup, but too little independent usage evidence to count as mature. | | **Hotcell** | \~2 points / 3 comments | Interesting because its creator explicitly targets creating multiple local sandboxes and running OpenCode, but essentially no community signal yet. | A very telling Clawk comment said the commenter's strongest setup was effectively **a separate QEMU/KVM machine plus a proxy/helper that creates disposable VMs**. Other participants argued that bubblewrap was a more sensible performance/security tradeoff for ordinary local coding. Yet another thread of the discussion praised Incus because Linux VM/container management was so simple. In other words, HN does **not** appear to have reached consensus that "microVM everywhere" is the answer. What people want is a selectable isolation level. The Docker Sandboxes discussion contained perhaps the closest real-world architecture I found to what I would recommend for your application. One commenter had removed Docker and used **rootless, daemonless Podman**, with user-namespace mapping for repository mounts, a dedicated SSH-agent exposure mechanism, an external credential broker for LLM access, and a separate egress proxy enforcing HTTPS allowlists. The important idea is not "copy this person's Podman command"; it is that **network and credential authority remain outside the agent container**. Another recurring theme is that Git worktrees solve a lot of parallelism pain but do **not** solve the human-management problem. People running multiple coding agents describe accumulating terminals/tabs and losing track of which agent is blocked, finished, or worth reviewing. Sculptor's developers explicitly argued that an at-a-glance UI is the missing piece; another tester asked for live streamed output and stronger keyboard navigation. HN also contains cautionary anecdotes that justify isolating the **Git working state**, not merely shell commands. In one discussion around running Claude in Docker, users praised worktrees for parallel sessions, while another recounted an agent rewriting Git history badly enough that the project was nearly lost. That is exactly the failure mode your "keep changes / discard / copy to `-boxN`" workflow protects against. My synthesis of the HN sentiment is: **People do not especially want another sandbox CLI. They want disposable environments to become invisible infrastructure behind their coding workflow.** That is a much better product thesis for your GUI than "make Podman commands easier." ## The open-source landscape and which projects I would trust There are now enough projects that "all AI sandboxes" is effectively a moving target. I found a broad set spanning host-policy wrappers, containers, lightweight VMs, full VMs, worktree orchestrators and desktop apps. The useful distinction is **not** stars; it is what security boundary the project actually supplies. For example, **AIO Sandbox** has roughly 5.9k GitHub stars and bundles browser, terminal, file APIs, Jupyter, VS Code Server and MCP into one Docker container. That looks impressive as a ready-made agent environment. But its documented quick start launches the container with `--security-opt seccomp=unconfined`. That makes it a potentially convenient *payload image* or developer environment, not something I would choose as the security foundation for hostile or highly autonomous code. Conversely, Quicksand has only about 51 stars in the repository snapshot but defaults its VM networking to isolated, provides explicit mounting instead of implicit whole-host access, supports checkpoint/revert and has an MIT license plus security policy and contributing/test infrastructure. Stars alone would rank these two in exactly the wrong order for your purpose. Here is the practical census I ended up with. The **"confidence" column is my assessment for use as part of a real desktop product, not a claim that a security audit has certified any of these projects.** | Project/family | Boundary / purpose | Assessment for your app | | ---------------------------------------- | ---------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Podman** | OCI containers; rootless/daemonless; Windows uses Linux VM | **Build on it now.** Mature foundation and excellent first backend. | | **Microsandbox** | Hardware-isolated local microVMs; Rust runtime/SDK; branch/snapshot | **Prototype seriously now.** The closest dedicated sandbox backend to your desired abstraction. Still explicitly beta. | | **Quicksand** | QEMU VMs through a clean Python API | **Prototype seriously.** Particularly attractive because Windows/Linux/macOS are all first-class goals. | | **SmolVM / Celesto open-source runtime** | Local microVM sandboxes with persistent state and snapshots | **Watch/prototype.** Active, promising, strong emphasis on coding-agent environments; current public docs emphasize macOS/Linux local operation. | | **NVIDIA OpenShell** | Policy-controlled isolated runtime for autonomous agents | **Watch closely, not default yet.** Serious backing and open-source intent, but still a fast-moving new agent runtime. | | **Anthropic Sandbox Runtime** | OS-native command sandboxing around agent commands | **Good inner policy layer**, not the strongest outer boundary. The larger ecosystem is converging on Seatbelt/bubblewrap-style host enforcement for lower-cost local isolation. | | **nono / Fence / Landrun / similar** | Landlock, bubblewrap, Seatbelt and command-policy wrappers | **Useful optional "light" mode.** I would not make a young host-policy wrapper the one security boundary your whole application promises. | | **gVisor** | User-space application kernel and OCI runtime | **Excellent Linux hardened-container option.** Not a microVM and not your cross-platform default. | | **Firecracker** | KVM hardware-isolated microVM | **Very mature primitive for Linux hosts.** Real microVM, very small device model, sub-125-ms startup claim, Apache-2.0; Linux host/guest requirement makes Windows/macOS desktop integration awkward. | | **Kata Containers** | OCI/container workflow backed by lightweight VMs | **Strong Linux "secure container" mode**, but considerably more infrastructure than a first desktop release needs. | | **Incus** | System containers + full VMs + snapshots | **Excellent Linux power-user backend.** Particularly interesting later for a pool of persistent local/self-hosted workers. | | **VMTREE** | Incus/LXD or QEMU ephemeral dev machines on your own server | **Good later server backend/reference.** Authors report eight-plus years of internal use, which is much stronger evidence than its tiny star count. | | **AIO Sandbox** | All-in-one Docker-based browser/shell/VSCode/Jupyter environment | **Useful image/integration reference; not my isolation layer.** Documented quick start disables seccomp. | | **Rivet sandbox-agent** | Unified server/API for running coding-agent harnesses inside a sandbox | **Very relevant complementary component.** Apache-2.0, Rust binary, unified Claude/Codex/OpenCode/Cursor/Amp/Pi API. | | **Sculptor** | Desktop parallel-agent workspace | **Best GUI prior art.** Study carefully; potentially a competitor more than a dependency. | | **Imbue mngr** | Parallel agent manager across hosts/containers/sandboxes | **Strong orchestration prior art.** Built on SSH, Git and tmux with no managed service required. | | **FleetCode** | Multi-agent/worktree UI | **Useful UX reference**, less relevant as strong sandbox infrastructure. | | **Clawk** | Local agent sandbox/tooling | **Interesting experimental project with unusually good HN discussion**, but I would keep it out of the trusted core until maturity grows. | | **ERA** | Local VM/libkrun-oriented sandboxing | **Interesting experiment**, insufficient independent maturity signal so far. | | **Hotcell** | Parallel local agent sandboxes | **Too early to rely on.** Concept strongly overlaps your use case but almost no independent signal. | I also found a much wider experimental tail: projects/catalog entries such as **cage, Agent Safehouse, sandbox-shell, SandVault, vibebox, yoloAI, sandlock, Matchlock, Microbox, ai-jail, treebeard, BoxLite, boxed, coderunner, K7, agent-vm, drydock, CubeSandbox, HyperAgent, strangeClaw, bromure, AgentBox, EdgeBox, ClaudeBox, codex-lockbox, conch, packnplay, sandclaude, runbox and sbox**, plus foundational tools such as bubblewrap, Firejail, Minijail and libkrun. The existence of this long tail is itself a reason not to build your product around the API of one small pre-1.0 wrapper. ### Microsandbox deserves a closer look than I initially expected Microsandbox is notable because its current API almost reads like a backend specification for your app. Its README advertises: - a Rust SDK in addition to TypeScript, Python, Go and other bindings; - local hardware microVM isolation; - Linux/KVM, Apple Silicon macOS and Windows/WHP; - OCI images; - named long-running sandboxes; - `branch` to fork a running sandbox; - full snapshots and restores; - CPU/memory/network metrics; - allowlisted networking; - directory/disk/volume concepts; - no setup server or persistent daemon requirement. The reliability caveat is not theoretical. The project labels itself beta and is actively changing. Its current issue tracker also reveals real filesystem-edge-case work; that is actually a healthy sign for transparency, but it means **your application should not promise that its sandbox layer is infallible just because it is a microVM**. There is also a particularly relevant open feature request about snapshot storage. As of August 2026, Microsandbox's managed snapshots were still copying a sparse raw `upper.ext4`; reflinks make those copies efficient on APFS and some Linux filesystems, while NTFS may copy all allocated extents. The issue proposes true filesystem-independent COW snapshot chains using qcow2 or an equivalent delta format, and notes that some qcow2 groundwork is already present but managed child snapshots are not yet implemented. This directly intersects your desire to fan one large environment out into five or twenty almost-instant copies. So my interpretation is: **Microsandbox has leapfrogged from "interesting experiment" to "serious integration candidate," but not yet to "bet the whole app on its storage semantics."** ### VMTREE is useful for a different reason VMTREE is not really competing with Microsandbox. Its authors describe a Bash-based self-hosted system that provisions ephemeral Ubuntu environments by SSH, backed either by LXD/Incus containers or QEMU VMs, with a persistent shared directory and automatic cleanup. More importantly, they state that their team has used it and an earlier internal incarnation for more than eight years. That makes VMTREE compelling prior art for a **future "my own worker machine" backend**: ```text Desktop GUI │ ├── Local Podman / microVMs │ └── My Linux workstation/server │ ├── vm-agent-1 ├── vm-agent-2 ├── vm-agent-3 └── vm-agent-N ``` That could let a laptop GUI transparently dispatch heavier agents to a home server without becoming a paid-hosted-sandbox product. VMTREE's longevity makes its operational model worth borrowing even if you never reuse its Bash code. ## Copy-on-write, worktrees, and instant project fan-out This part is more important than it initially appears. There are really **two different things you need to clone**: 1. the sandbox's operating-system/toolchain state; 2. the user's project working directory. They do not have to use the same mechanism. For the root environment, container image layers already give you cheap shared immutable layers, while QEMU's qcow2 format is explicitly designed around copy-on-write and backing files. A VM can therefore start from one immutable base disk with each agent storing only its changed blocks. For the project itself, **Git worktrees are the least surprising default whenever the folder is a Git repository**. Git officially supports multiple working trees attached to one repository so multiple branches can be checked out simultaneously. That is why so many parallel-agent tools have converged on them. But worktrees are not magical filesystem COW. They share repository metadata/object history, while each working tree still needs its own checked-out files. So a repository with enormous generated assets, `node_modules`, build outputs or model files can still make N-agent fan-out expensive unless those things live in shared caches, sandbox images or a separate mount. That leads to the hierarchy I would implement: | Project fan-out method | Speed / space | Portability | Recommendation | | ------------------------------------- | ------------------------------------------------------------------------- | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | **Git worktree** | Very good, shares Git object database | Windows/Linux/macOS | **Default for Git repos.** | | **Filesystem reflink copy** | Excellent when filesystem supports it; blocks copied only on modification | Highly filesystem-dependent | **Try automatically, fall back safely.** Linux cp --reflink=auto already follows this model. | | **OverlayFS lower + per-agent upper** | Excellent; reads shared base and copies changed files upward | Linux environment | **Very attractive inside a Podman/WSL/Linux VM**, particularly for non-Git trees. OverlayFS uses lower and upper layers with copy-up semantics. | | **qcow2 backing disk** | Excellent block-level COW | VM-oriented | **Best for VM filesystem/root images.** | | **Incus snapshots/copies** | Can be extremely efficient depending on storage driver | Primarily Linux host | Good advanced/backend option. Incus explicitly exposes snapshots/copies and says behavior depends on storage driver. | | **Normal directory copy** | O(size) | Universal | Reliable fallback; not first choice for N-way fan-out. | I would specifically **not use `git clone --shared` as your default clever optimization**. Git's own documentation calls it a "possibly dangerous operation": it sets up object alternates referencing the source repository, and if referenced source objects later become unreferenced and pruned, the dependent clone can become corrupt. You can manage that correctly, but there is no reason to put that sharp edge in a product when `git worktree` is better suited to this workflow. The workspace lifecycle I would expose is therefore: ```text host project │ snapshot / worktree │ ┌──────────────────┼──────────────────┐ ▼ ▼ ▼ workspace-A workspace-B workspace-C agent/model A agent/model B agent/model C │ │ │ diff A diff B diff C └──────────────────┼──────────────────┘ ▼ Review results / | \ Apply Export Discard │ │ host project project-box-B ``` The key decision is that **the original project should normally not be mounted read-write into an autonomous agent at all**. Give the agent a writable derivative. The host original can either be invisible or mounted read-only for reference. Then "Keep changes?" becomes a controlled host-side operation instead of trusting the sandbox to reverse whatever it did. For a Git project, "Keep" can mean commit/cherry-pick/apply selected hunks. For an arbitrary folder, it can mean a host-side diff/copy transaction. "Keep as separate folder" can produce exactly the naming scheme you described: ```text my-project/ my-project-box1/ my-project-box2/ my-project-box3/ ``` A direct RW bind mount should still exist as an explicit expert mode because sometimes a developer genuinely wants instant live editing. But I would visually label it **"writes directly to original"** rather than merely displaying `RW`. That communicates the consequence far better. Podman's container-image COW does **not** solve this automatically when you bind-mount the real project from the host: a bind mount deliberately exposes that host directory. That is another reason to separate the concepts "sandbox root filesystem" and "project workspace" in your architecture. One especially nice optimization would be to choose the fastest workspace strategy dynamically: ```text Is this a Git repo? │ ├─ yes → git worktree │ └─ no │ ├─ reflink available? → reflink clone │ ├─ Linux sandbox FS? → overlay │ └─ otherwise → normal copy ``` The user never needs to learn which one happened. The GUI could simply say: > **Workspace clone: 37 ms, 1.8 MB initially allocated, source protected** That is exactly the kind of visual feedback missing from today's CLI-first sandbox projects. ## Existing GUIs and what the visual layer should actually show **Yes, there are UIs now, but Sculptor is the only project I found that substantially overlaps the complete parallel-coding-agent workflow you described.** Its current documentation calls it an extensible, local, open-source parallel coding workspace. It gives each agent its own worktree, branch, terminal and diff; it explicitly advertises running 5+ agents simultaneously and supports switching models/providers. That is important because I would *not* make your differentiator simply: > "Sculptor, but Rust." Your interesting differentiator is instead: > **Sculptor-like parallel-agent UX plus visible/selectable isolation technology, reproducible sandbox templates, strong workspace lineage, and one-click fan-out/comparison.** FleetCode independently validates the same general direction: an open-source UI managing multiple coding agents through separate Git worktrees received meaningful HN attention. Juggler has even stronger HN traction as a coding-agent GUI, although sandbox isolation is not its core contribution. That again suggests the UI layer is not frivolous—the terminal-tab problem is real. Generic sandbox GUIs exist as well—Podman Desktop for containers, Firejail-related GUI tooling, terminal UIs around bubblewrap, VS Code/devcontainer managers—but they visualize *machines and containers*, not the higher-level question a developer actually has: > "I gave one task to five agents. Which result is good, what did each agent touch, and what authority did I give it?" That is where I think your graph idea is much better than a traditional VM-manager table. ### The primary screen should be lineage, not a container list I would make the central canvas something like: ```text TASK "Implement streaming upload API" │ ┌────────────┴────────────┐ │ project @ 4ea91b7 │ │ source: READ ONLY │ └────────────┬────────────┘ │ ┌────────────┬──────┼──────┬────────────┐ │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ... ┌──────────┐ │ BOX A │ │ BOX B │ │ BOX E │ │ Codex │ │ Claude │ │ cheap/fast│ │ Podman │ │ microVM │ │ Podman │ │ running │ │ testing │ │ done │ │ +4 -1 │ │ +7 -2 │ │ +3 -0 │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ diff diff diff └─────────────┴──────────┬──────────────┘ ▼ COMPARE / ACCEPT ``` The arrows should carry information. An ordinary node graph wastes the most interesting part of your concept if every edge is just a decorative line. For example: ```text project ── RO snapshot ─────► box1 project ── worktree branch ─► box2 cache ── RO shared ───────► box2 LLM API ◄─ brokered HTTPS ─── box2 box2 ── proposed diff ───► review ``` That makes the security model understandable without users memorizing `--volume`, namespace or mount syntax. ### Each sandbox should have an "authority card" Instead of a vague green lock icon, show what the sandbox can actually do: ```text BOX B — Claude / Microsandbox Filesystem Original project READ ONLY Workspace READ + WRITE ~/.ssh NO ACCESS ~/.config NO ACCESS dependency cache READ ONLY Network api.anthropic.com ALLOW github.com ALLOW everything else DENY Credentials Anthropic BROKERED GitHub BROKERED SSH agent NONE Isolation Hardware VM YES Shared host kernel NO Host directory mounts 1 ``` This would be a genuinely useful visualization rather than cosmetic sandbox chrome. HN's rootless-Podman commenter provides a particularly good model: broker credentials and constrain egress outside the agent instead of placing powerful secrets directly in its environment. ### Fan-out should be a first-class operation Your "50% frontier, 50% cheap/fast" idea is unusual enough that I would make it one of the core interactions: ```text Run task in: [ 8 ] sandboxes Model mix Frontier / strongest ██████████ 50% → 4 lanes Fast / cheap ██████████ 50% → 4 lanes Isolation [✓] Same base environment [✓] Same starting commit [✓] Same prompt [✓] Independent writable workspaces Network [ GitHub + model only ▼ ] Time limit [ 30 min ] RAM / lane [ 4 GB ] ``` The scheduler can resolve that to specific models without making the user manually create eight terminals. A more advanced mode could vary multiple dimensions: ```text MODEL A B C ┌───────┬───────┬───────┐ Podman│ lane1 │ lane2 │ lane3 │ ├───────┼───────┼───────┤ microVM│lane4 │ lane5 │ lane6 │ └───────┴───────┴───────┘ ``` That would even let developers answer questions such as "does this model only succeed when it has the full toolchain image?" rather than merely comparing model text output. ### The comparison screen may be more important than the terminals The terminal is necessary, but the real bottleneck after fan-out is **evaluation**. HN discussions about multi-agent workflows repeatedly circle back to human context switching and keeping track of finished/blocked agents. So I would make the review page a serious product surface: | Lane | Model | Status | Tests | Diff | Time | Decision | | ---- | ---------- | ------- | ------- | --------- | ---- | ---------- | | A | frontier A | done | 128/128 | +214 −31 | 6m | **Review** | | B | frontier B | done | 126/128 | +91 −22 | 4m | reject | | C | fast A | done | 128/128 | +63 −8 | 2m | **Review** | | D | fast B | blocked | — | +12 | 8m | inspect | | E | fast C | done | 128/128 | +418 −270 | 3m | reject | Clicking a lane could reveal its terminal, agent transcript, changed files, tests, network activity and sandbox authority in one place. Then provide: ```text [ Apply all changes ] [ Apply selected files ] [ Apply selected hunks ] [ Create branch ] [ Export as project-box3 ] [ Keep sandbox ] [ Discard ] ``` That is a much stronger user-facing abstraction than "stop container" versus "delete container." ## What I would build around The research changed my view slightly from "just use Podman first" to **"use Podman first, but design the provider API around the capabilities that Microsandbox and Quicksand already demonstrate."** I would define a backend contract roughly around capabilities rather than commands: ```text SandboxProvider create(spec) start() stop() destroy() exec() terminal() mount(source, target, mode) copy_in() copy_out() snapshot() restore() fork() set_network_policy() expose_port() metrics() inspect() ``` Then capability detection: ```text ProviderCapabilities container_isolation hardware_vm native_snapshot live_fork directory_mount readonly_mount network_allowlist credential_broker gui_desktop gpu ``` That prevents a Podman-specific detail such as "container image" or a QEMU-specific detail such as "qcow2 backing file" from leaking into the GUI. For the first backend, **Podman remains the conservative choice**. It is open source, daemonless, supports unprivileged operation, and on Windows the engine lives inside WSL2 or Hyper-V. That means a Windows user naturally gets something like: ```text Windows host └── WSL2 / Hyper-V Podman Machine ├── agent container 1 ├── agent container 2 ├── agent container 3 ├── agent container 4 └── agent container 5 ``` Those five containers are separately namespaced, but they share the Podman Machine's Linux kernel; they are **not five hardware-isolated VMs**. The UI should say that clearly. On native Linux the distinction is even more important because ordinary Podman containers use the host Linux kernel. For developers wanting a stronger level, offer a second backend rather than pretending a container is a VM. My current provider roadmap would therefore be: **Fast mode — Podman.** Rootless containers, worktree/reflink/overlay workspace, original source protected, restricted mounts, external credential handling. This is the reliable MVP. **Strong mode — Microsandbox.** This is now the most intriguing second implementation because it is Rust-native, explicitly embeddable, supports Windows/Linux/macOS, exposes microVM branching and snapshots, runs OCI images, and already thinks in terms very close to your API. Its beta label and unfinished cross-platform COW snapshot optimization are reasons for extensive soak-testing, not reasons to ignore it. **Compatibility VM mode — Quicksand/QEMU.** Quicksand's API is unusually clean and its cross-platform QEMU approach could make it an excellent fallback where the more specialized microVM stack has problems. It also gives you desktop-VM functionality almost for free if you eventually want agents that need a browser/GUI. **Hardened-container mode — gVisor on Linux.** This sits nicely between ordinary containers and hardware VMs. It remains compatible with OCI/container tooling while inserting a user-space application kernel as an additional barrier. **Heavy Linux VM mode — Kata/Firecracker or Incus.** Useful later for hostile workloads, persistent machines, GPU configurations or a self-hosted worker server; unnecessary complexity for the first desktop release. **Remote-my-own-machine mode — VMTREE/Incus-style worker pool.** This preserves the "free/open/local infrastructure" philosophy while allowing serious fan-out beyond a laptop. For the agent harness itself, I would seriously investigate using or borrowing the protocol design from **Rivet's `sandbox-agent`** rather than writing six bespoke terminal scrapers. It runs as a lightweight Rust server inside a sandbox and normalizes Claude Code, Codex, OpenCode, Cursor, Amp and Pi through one HTTP/SSE API and one event/session schema. The project explicitly separates the *sandbox provider* from the *agent-control protocol*, which is exactly the separation your application needs. That gives you a much cleaner architecture: ```text Rust/Tauri or egui desktop app │ ├── task / model scheduler ├── workspace manager ├── diff / merge engine ├── credential broker ├── network policy controller │ └── SandboxProvider │ ├── Podman ├── Microsandbox ├── Quicksand/QEMU ├── gVisor-enabled Podman └── Incus / remote worker │ ▼ sandbox-agent-style harness adapter │ ┌─────────┼─────────┐ ▼ ▼ ▼ Claude Codex OpenCode ... ``` And I would make one architectural rule non-negotiable- > **The sandbox never gets more host authority merely because an agent asks for it.** Mount changes, credential grants, host writes and "apply this result" should cross an explicit host-side broker/controller. That follows the strongest pattern I found in real HN setups and removes an entire class of "the model convinced its own shell to escape its intended permission set" mistakes. Before calling any backend "trusted" in the UI, I would also make it pass your own provider test suite: symlink/path traversal attempts, writes through supposed read-only mounts, hidden-file access, `.env` access, SSH-agent misuse, localhost/service probing, network deny/allowlist checks, fork/snapshot correctness, cleanup after process crashes, disk exhaustion, runaway process trees, stale mounts, weird Windows paths, and 5/20/50-way concurrent fan-out. A young project can change under you; your app's definition of "Safe mode" should therefore depend on **your regression tests**, not on the upstream project's README. The strongest product opportunity I see after this survey is consequently **not another sandbox implementation**. There are already plenty. It is a local, open-source **visual control plane over multiple trustworthy sandbox implementations**, where the developer can see: ```text what was copied what is shared what is writable what is isolated what has network which credentials exist which model is running what changed what passed and exactly what will happen when "Keep" is clicked ``` Sculptor demonstrates that developers want a parallel-agent desktop workspace. Microsandbox, Quicksand, Podman, gVisor, Kata and Incus demonstrate that there is no single isolation primitive that wins on every host. Git worktrees, reflinks, overlays and qcow2 demonstrate that fan-out can be made much cheaper than N full copies. The missing layer is the **coherent visual abstraction joining those pieces together**.