Comparisons

Spens is not the strongest sandbox available, and it does not try to be. It is a local runtime for coding agents that puts observability first: you can see every request an agent made, keep your secrets out of the container, and undo its file changes.

The tools below are stronger in isolation, or better suited to other jobs. This section explains where each one fits, so you can pick the right tool for the job.

One thing to be clear about up front: spens uses Docker, and containers share the host kernel. Spens is secure enough for most agent workloads, but it is not a hard security boundary against hostile code. If you need one, use a microVM, or run spens with gVisor to harden the Docker instance.

Comparison summary

Which should you pick

• You run agents on your own projects and want to see and control what they did: spens.
• You are building a product that runs untrusted user code at scale: a managed cloud sandbox such as E2B, or microVMs.
• You need the strongest possible boundary against hostile code: microVMs (Firecracker, Kata), or gVisor — which can also be used to harden spens.
• You are on Linux, want no Docker dependency, and only need filesystem containment: bubble wrap.
• You use one agent on one machine and are happy with its own permission system: the agent's built-in sandbox may be enough.

Spens vs a plain Docker sandbox

By "a Docker sandbox" we mean running an agent in a container yourself, with docker run, perhaps with extra hardening such as dropped capabilities, a seccomp profile, or AppArmor rules.

What plain Docker gives you: The agent runs as a non-root user, in its own filesystem, with resource limits. It cannot see your home directory unless you mount it in.

What plain Docker does not give you:

• Network control. A container either has internet access or it does not. There is no way to say "allow GET to pypi.org and block everything else" without building and wiring up a proxy yourself.
• Observability. Docker captures stdout. It does not record HTTP requests, decode LLM API calls, or show file diffs.
• Secret handling. The usual way to give an agent an API key is to pass it in as an environment variable. The agent now holds your real key and can send it anywhere.
• Undo. If the agent breaks files, your rollback is git — if the changes were committed, and if it touched nothing outside the repo.

What spens adds: Spens is built on Docker and keeps all of the benefits above, then adds the missing pieces: a two-container setup where all traffic, including DNS, is forced through an interceptor; fail-closed domain rules; placeholder secret injection so the real key never enters the container; decoded LLM traces; an audit ledger with an integrity chain; and per-session rollback of file changes.

The honest trade-off: Plain Docker is simpler to start with and needs no extra tooling. If you only need rough containment, docker run may be enough. Spens is for when you also need to know what the agent did, and be able to undo it.

Spens vs microVMs

MicroVMs give each workload its own kernel, instead of sharing the host kernel the way containers do.

• Firecracker is a small virtual machine monitor. It boots a VM in about 125 ms and adds under 5 MiB of memory overhead per VM. It is the technology under AWS Lambda.
• Kata Containers wraps microVMs behind a standard container interface, so they drop into Kubernetes. Cold starts take a few seconds.
• gVisor is not a VM. It is a user-space kernel that intercepts the sandbox's system calls. It is used by Google Cloud Run and GKE Sandbox, and by OpenAI and Anthropic for code execution.

Why they are stronger: Containers share the host kernel. If agent-generated code finds a kernel bug, it can escape to the host. A microVM puts a hardware boundary in the way: an escape now needs two breaks, the guest kernel and the hypervisor. For truly hostile code, this is the right answer, and it is what large platforms use for multi-tenant workloads.

Why spens does not use them by default: MicroVMs are isolation primitives. They answer "can this code touch my machine?" but not which domains did the agent call, where did my API key go, which files did it change, or what did this session cost. Running an agent in a microVM still means wiring up a proxy, traffic capture, audit, and rollback yourself. Spens gives you all of that on day one, on a container boundary that is secure enough for most agent workloads. And if you want the harder boundary, spens can be run with gVisor to harden the Docker instance.

When to pick which: A multi-tenant service running untrusted user code at scale: microVMs, usually through a managed platform. Your own machine, your own agents, your own codebases: spens.

Spens vs E2B

E2B is a cloud service for running agent code in sandboxes. Each sandbox is a Firecracker microVM, started through an SDK (Python or JavaScript) and billed per second. Cold starts are around 150 ms.

Pricing, checked September 2026 and subject to change: a free tier with one-time credits and one-hour session limits; a Pro tier around $150 per month with 24-hour sessions and up to 100 concurrent sandboxes; compute billed per vCPU-hour and GiB-hour on top. Verify current numbers on E2B's pricing page before publishing.

What E2B is good at: Managed infrastructure, fast cold starts, scaling to many sandboxes at once, and running code as part of a product you ship. If you are building an app that executes untrusted code for your users, E2B or a similar platform is the right shape.

Where spens differs:

• Local vs cloud. Spens runs on your machine. Your code, your keys, and your traces never leave it. E2B sessions run on E2B's servers.
• CLI workflow vs SDK. Spens wraps the agents you already use — codex, claude, opencode, pi — in one runtime. E2B is an API you build your own product against.
• Observability included. Spens decodes LLM traffic, logs every request and DNS query, estimates the cost of each session, and ships a log viewer to review it all.
• Secrets stay out. Placeholder injection means the agent only ever sees a placeholder, and the real key is swapped in only for requests to domains you approved.
• Undo. At the end of a session you accept the agent's file changes or roll the workspace back.
• Cost. Spens is free and open source. You pay only for the compute you already own.

The honest trade-off: Spens does not scale out. It runs sessions on your machine, and it is not a service you can put behind your product's API. For production code-execution platforms, use a cloud sandbox. For running agents on your own projects, spens.

Spens vs bubble wrap

Bubble wrap (bwrap) is a Linux sandbox that needs no root and no Docker daemon. It builds the sandbox from Linux namespaces: the process gets its own view of the filesystem through bind mounts, its own PID space, and optionally no network at all. It is the sandbox behind Flatpak, and it appears in CI runners and agent harnesses that need to run untrusted code locally without Docker.

What it does well: It is small, fast, unprivileged, and precise. You describe the filesystem view and it enforces exactly that.

Where it falls short for agents:

• Linux only. No macOS, no Windows.
• Filesystem only. Network isolation is all-or-nothing: either the agent has your network or it has none. There are no per-domain rules and no traffic logging.
• No capture, audit, or rollback. You get isolation, not observability.
• Fragile defaults. Distributions are tightening unprivileged user namespaces — Ubuntu 24.04 restricts them with AppArmor by default — and bwrap's old setuid fallback has been removed. On some systems bwrap simply will not run.

How spens compares: Spens uses nono.sh for the same job bwrap does — filesystem access control for an unprivileged user — but wraps it in a full runtime: Docker for cross-platform support, the interceptor for network policy and capture, and the session layer for audit and rollback.

When to pick which: If you are on Linux, want no Docker dependency, and only need filesystem containment, bwrap is a fine, minimal tool. If you run agents across machines and projects and need to see and control what they do, spens.

Spens vs the agents' built-in sandboxes

Most coding agents now ship their own sandboxing:

• Codex CLI uses OS-level sandboxing: Seatbelt on macOS, Landlock plus seccomp on Linux. It blocks system calls below the application layer.
• Claude Code uses an application-layer system of permission prompts and hooks.

These are good features. Keep them on. But they are per-agent: each agent has its own config format, its own permission model, and its own coverage gaps. If you run several agents, you are maintaining several security setups.

Spens is agent-agnostic. One runtime, one config, one network policy, one audit log, one review flow — for every agent, including agents you add yourself with a JSON template.

And because spens contains the whole container, the agents' internal permission systems can be relaxed inside it without giving the agent access to your machine. That is why spens's built-in yolo commands run codex with its internal sandbox set to full access and claude with its permission prompts skipped: the container, not the agent, is the boundary.