Verdicts · skip

Skip for now

This is the chapter that saves the most time, and the one nobody writes. These repositories are not necessarily bad — most contain at least one good idea — but the expected hassle and risk look larger than the likely benefit, and there are better uses for your evening.

The five shapes of a repo to skip, and one category error

1 · The stalled wrapper

A few hundred stars, a promising README, and no commits for four to eight months. It is not archived, which is worse: the blocklists and default profiles are rotting in place and there is no signal that maintenance stopped. Look at the last-commit date before the star count, every time.

2 · The launch-week project

Impressive architecture, a Hacker News thread, and development that stopped days after the launch. One thorough first-wave project — with egress inspection, branch isolation and blocked merges — went quiet two days after its announcement thread. The engineering was real; the commitment was not.

3 · The single-day repository

Twelve commits on one day, no releases, one author, five to fifteen stars, and a README describing a complete security model. These are sketches, not software. Some contain a genuinely good idea — time-travel debugging for agent microVMs is a real invention — and the idea is the part worth keeping.

4 · The licence trap

A GPL-3.0 desktop application that would be useful to study, except that copying any of it would relicense your product. Combine that with a stalled project and there is nothing left to take but the screenshots.

5 · The repudiated repo

The project that built its reputation on being open source and then closed the production code while leaving the public repository unmaintained. For a sandbox, the source is the trust boundary, so this is not a licensing inconvenience — it removes the mechanism by which you could check the claim.

6 · And the category error

Tools that give an agent more access, presented in lists alongside tools that contain it. An MCP server that controls your Windows desktop, a runner that executes on your host, an "agent framework" with no boundary at all. Useful, sometimes excellent, and not what you are looking for when you search for a sandbox.

The list

Each entry names the reason. Several are worth reading for their ideas — that is why some of them appear in the watch list analysis rather than being dismissed outright.

daytonaio/daytona

PROBABLY SKIP FOR NOW

Went closed source in June 2026; the public repository is now explicitly unmaintained. Also the reason this site treats 'open source' as a claim to verify. → full assessment

Hosted sandbox API / CDEagent-specificcloud
★ 71k issues 457 pushed 2026-07-24 lic none GitHub ↗project site ↗

codesandbox/codesandbox-client

PROBABLY SKIP FOR NOW

The browser IDE. Interesting history in WebContainers; the agent story moved to the SDK.

Hosted sandbox API / CDEbrowser
★ 13k issues 615 pushed 2026-09-07 lic NOASSERTION GitHub ↗project site ↗

FerretDB/FerretDB

PROBABLY SKIP FOR NOW

Not a sandbox. Included only because it showed up in a sandbox list; left here as a reminder to check your sources.

Adjacent toolinglinux
★ 11k issues 449 pushed 2026-06-05 lic Apache-2.0 GitHub ↗project site ↗

stackblitz/webcontainer-core

PROBABLY SKIP FOR NOW

Node.js in a browser tab. Nobody has committed to the public repository since April 2025.

WASM / language isolatebrowser
★ 4.6k issues 817 pushed 2025-04-22 lic MIT GitHub ↗project site ↗

strongdm/leash

PROBABLY SKIP FOR NOW

Cedar-policy container wrapper from StrongDM. Ships a DISCLAIMER.txt disclaiming support, and the repo has been quiet since April 2026.

Agent sandbox wrapperagent-specificlinux · macos
★ 592 issues 21 pushed 2026-04-06 lic Apache-2.0 GitHub ↗project site ↗

genuinetools/bpfd

PROBABLY SKIP FOR NOW

BPF program runner for container awareness. Archived since May 2021.

Network / egress controllinux
★ 484 issues 5 pushed 2021-05-07 lic MIT GitHub ↗

BIGPPWONG/EdgeBox

PROBABLY SKIP FOR NOW

E2B-based local sandbox with a VNC desktop, Electron shell, GPL-3.0, stalled since April 2026, and a README that injects an unrelated project recommendation. → full assessment

Computer-use / desktop automationagent-specificlinux · macos · windows
★ 213 issues 2 pushed 2026-04-22 lic GPL-3.0 GitHub ↗

robcholz/vibebox

PROBABLY SKIP FOR NOW

Fast Apple-Silicon Seatbelt wrapper. Commits stopped in February 2026.

Agent sandbox wrapperagent-specificmacos
★ 188 issues 0 pushed 2026-02-18 lic MIT GitHub ↗project site ↗

obra/packnplay

PROBABLY SKIP FOR NOW

Docker sandbox with automatic worktrees. Quiet since March 2026 and never took off.

Agent sandbox wrapperagent-specificlinux · macos
★ 174 issues 9 pushed 2026-03-21 lic none GitHub ↗

deepclause/deepclause-sdk

PROBABLY SKIP FOR NOW

DML-style runtime authorization SDK. Fifty-six stars.

Policy, approval & auditagent-specificlinux · macos
★ 56 issues 4 pushed 2026-09-10 lic none GitHub ↗

Kiln-AI/Kilntainers

PROBABLY SKIP FOR NOW

MCP server that hands out ephemeral shells. Last push March 2026.

Agent sandbox wrapperagent-specificlinux
★ 51 issues 8 pushed 2026-03-03 lic MIT GitHub ↗project site ↗

HQarroum/microbox

PROBABLY SKIP FOR NOW

Lightweight ephemeral Linux sandboxes. Last push October 2025.

Agent sandbox wrapperagent-specificlinux
★ 47 issues 0 pushed 2025-10-09 lic none GitHub ↗

cirruslabs/chamber

PROBABLY SKIP FOR NOW

Tart-backed ephemeral macOS VM per agent. AGPL, quiet since December 2025.

Full VM / hypervisoragent-specificmacos
★ 46 issues 2 pushed 2025-12-10 lic AGPL-3.0 GitHub ↗

colony-2/shai

PROBABLY SKIP FOR NOW

Resource Sets as committed team policy. Forty-three stars and no traction since March.

Agent sandbox wrapperagent-specificlinux
★ 43 issues 1 pushed 2026-07-02 lic MIT GitHub ↗project site ↗

akshayaggarwal99/boxed

PROBABLY SKIP FOR NOW

Multi-backend (Docker/Firecracker/WASM) execution engine. Thirteen stars.

Agent sandbox wrapperagent-specificlinux
★ 13 issues 0 pushed 2026-09-11 lic MIT GitHub ↗

divmain/treebeard

PROBABLY SKIP FOR NOW

Ephemeral worktrees with copy-on-write and network gating. Twelve stars and two days of development.

Filesystem / copy-on-writeagent-specificlinux · macos
★ 12 issues 0 pushed 2026-01-06 lic NOASSERTION GitHub ↗

matheusmoreira/virtdev

PROBABLY SKIP FOR NOW

Per-project Arch VMs with nftables egress zones. 8 stars, one author, no credential story.

Full VM / hypervisoragent-specificlinux
★ 8 issues 0 pushed 2026-09-04 lic AGPL-3.0 GitHub ↗

PunkGo/punkgo-jack

PROBABLY SKIP FOR NOW

Merkle-logged audit receipts for hook events. Seven stars, clever, unproven.

Policy, approval & auditagent-specificlinux · macos
★ 7 issues 0 pushed 2026-07-02 lic MIT GitHub ↗project site ↗

ligon/sucoder

PROBABLY SKIP FOR NOW

Unix permissions as a boundary. Six stars; the idea is old and the repo is thin.

Agent sandbox wrapperagent-specificlinux
★ 6 issues 1 pushed 2026-09-19 lic Apache-2.0 GitHub ↗

paulux84/codex-lockbox

PROBABLY SKIP FOR NOW

Five stars, one author, stale since February 2026.

Agent sandbox wrapperagent-specificlinux
★ 5 issues 0 pushed 2026-02-04 lic none GitHub ↗

PredicateSystems/predicate-secure

PROBABLY SKIP FOR NOW

Policy-based authorization with post-run verification. Five stars.

Policy, approval & auditagent-specificlinux · macos
★ 5 issues 0 pushed 2026-02-28 lic NOASSERTION GitHub ↗project site ↗

Sarthak30/agentsafe

PROBABLY SKIP FOR NOW

Per-task Firecracker VMs. Four stars and one day of commits.

Agent sandbox wrapperagent-specificlinux
★ 4 issues 0 pushed 2025-09-21 lic none GitHub ↗

ashishgituser/nervos

PROBABLY SKIP FOR NOW

Agent microVMs with a Git-first workflow. The repository no longer resolves at its original URL — which is itself the cautionary point about building on a wrapper with one author and no release history.

Agent sandbox wrapperagent-specificlinux
★ – issues – pushed – lic none GitHub ↗

Daytona

PROBABLY SKIP FOR NOW
★ 71kforks 5.6kopen issues 457created 2024-02-06last push 2026-07-24licence none detected
Type
Hosted dev-environment and agent-sandbox platform
Platforms
Cloud (vendor-hosted, with a customer-cloud data plane); Linux for self-hosting, which is no longer supported
Agent-specific
Yes
Open source
No longer. The public repository is explicitly unmaintained; AGPL survives only on tagged releases.
Isolation model
Docker/OCI containers by default, with Kata or Sysbox only if you configure them. That means the default isolation level is a shared kernel. Persistent workspaces are the default behaviour, which is convenient and is also why idle billing surprises people.
Adoption evidence
Seventy-one thousand stars made it the most visible name in the category and it was recommended widely through 2025. That reputation was built on being open source, which is the claim that subsequently changed.
Development activity
The public repository has not moved since July 2026 and its own messaging says it will not. Development continues in private.
Common complaints
The most serious complaint is the one that cannot be fixed by a patch: the code you were told to trust is no longer inspectable. Simon Willison's widely quoted reaction was that it is "not a great advertisement for a sandboxing product" to effectively say you do not trust your own security enough to publish the source. Alongside that, container-level default isolation is a weak boundary for untrusted generated code, self-hosting is gone, persistent workspaces quietly bill unless idle timeouts are configured, there is no supported static egress, and some ecosystem plugins have already been removed.
Security considerations
The open-source-looking reputation and the actual trust model diverged in 2026. For a sandbox, the source is the trust boundary: if you cannot read the isolation code, you are trusting a vendor's assurance about the one component whose entire job is to be trustworthy. Whether or not the closed code is good, the auditability is gone.
Interesting features
Genuinely fast workspace creation, persistent stateful environments, and a polished developer experience — which is why so many people adopted it before the licensing change.
Why this rating
This is the clearest cautionary example on the site, and it is not about a bug. A project built its entire reputation on open source, then closed the production codebase and left the public repository to rot, while continuing to advertise the brand. For a developer tool that might be fine. For the component whose job is to contain untrusted code, it removes the only mechanism you had for checking the claim. The complaints-to-adoption ratio is not the story here; the story is that the trust model changed under existing users.
Our take
Do not build on the public repository: nothing in it is maintained, and a frozen sandbox accumulates unpatched escape bugs. If you are evaluating the closed product, evaluate it as a proprietary service with the usual vendor-review process, not as an open-source project. This is also the reason the guide insists that 'open source' be treated as a claim you verify rather than a property you assume.

EdgeBox

PROBABLY SKIP FOR NOW
★ 213forks 26open issues 2created 2025-09-12last push 2026-04-22licence GPL-3.0
Type
Electron desktop sandbox with a full GUI desktop inside a container
Platforms
Linux, macOS, Windows
Agent-specific
Yes
Open source
Yes, GPL-3.0
Isolation model
E2B-derived E2B code-interpreter components running locally in a container, with a VNC-exposed desktop so the agent can drive a browser and GUI applications. Container, not VM.
Adoption evidence
Two hundred and thirteen stars, two watchers, no releases, and last activity in April 2026. The Hacker News and directory attention it received has not translated into usage.
Development activity
Effectively stalled. No commits since April 2026, no releases at all.
Common complaints
The observable signals are the complaint: no release cadence, no issue traffic, a GPL-3.0 licence that prevents code reuse in most commercial products, an Electron runtime that contradicts the memory footprint goal of most Rust/Tauri agent GUIs, and a README that injects a promotional recommendation for an unrelated project — a pattern worth flagging when evaluating a repo's honesty.
Security considerations
A container desktop exposed over VNC is a wide surface, and a stalled container project does not receive container-runtime patches. Because the isolation comes from the underlying runtime rather than from EdgeBox itself, the practical outcome depends on how current your Docker/Podman is, not on anything the project maintains.
Interesting features
The UX idea is genuinely attractive: a visible desktop the agent operates, with the human able to watch and take over. That combination — computer-use with an observability surface — is the pattern worth taking from it, not the code.
Why this rating
It is a stalled Electron app with no releases, a licence that blocks reuse in most products, and a pattern of injecting unrelated recommendations into its own README. Even if the design is right, there is no maintenance, no release process, and no evidence that anyone is running it. The expected hassle of adopting it exceeds any benefit, and the good part (the desktop-with-observability UX) can be reproduced on a maintained base in a weekend.
Our take
Read the screenshots, skip the repo. If you want a sandboxed desktop, build it on a maintained container or microVM base with an existing VNC or streaming layer.

Not an isolation layer (a separate list, on purpose)

These are useful pieces of software that do not contain the agent. Including them here is not a criticism; it is a warning about how they get misremembered after you have read three comparison tables in a row.

CursorTouch/Windows-MCP

NOT AN ISOLATION LAYER

Gives an agent the whole Windows desktop. The inverse of a sandbox, and it should be labelled that way. → full assessment

Computer-use / desktop automationagent-specificwindows
★ 7k issues 26 pushed 2026-09-16 lic MIT GitHub ↗
The misreading to avoid

"The agent can control my desktop" and "the agent is contained on my desktop" are opposite claims, and they appear within a page of each other in several published lists. If a tool needs full UI control to work, it cannot be sandboxed by the same tool that gives it that control — the containment has to come from somewhere else, which in practice means a VM.

What to do instead

If you wanted a sandbox wrapper

You almost certainly want one of these instead: a rootless Podman container with a hardened flag set and a narrow mount; your agent's own built-in sandbox left on; or a VM managed by Lima, Incus, UTM or Multipass. Every item on this page is a wrapper around one of those, and the wrapper is the part that stops being maintained.

Containers → · Full VMs →

If you wanted the security, not the tool

The security people are looking for in abandoned wrappers is usually available from three changes that have nothing to do with which project you install: move credentials out of the agent's environment, put the egress policy in the kernel, and make the agent's workspace a copy rather than your original. That is a weekend of work with no dependency risk at all.

Secrets → · Network → · Filesystem →

A note of respect

Most of these repositories were written by one person who saw a real problem and shipped something for it in a weekend. Several of them are better thought through than projects with fifty times the stars. The judgement here is not about the quality of the work — it is about whether a stranger should build a production dependency on something that has not yet been maintained for long enough to be predictable. If one of these starts shipping releases again, revisit it.