Local AI Agent Sandboxes

Executive Summary

AI coding agents are most productive when you let them run without permission prompts — but one bad command and your home directory is gone. A new category of local sandboxing tools has emerged to solve this: run your agent in full-auto mode while keeping your machine safe.

This is distinct from cloud sandbox platforms (E2B, Daytona, Sprites) which provide remote isolated environments via API. Local sandboxes run on your machine, wrapping your existing agent CLI in a protective layer.

6 tools compared: yolobox, yolo-cage, shai, litterbox, landrun, and Codex's built-in sandbox.

Key findings:

• The market splits along a permissive vs restrictive axis — matching the broader autonomy vs oversight debate in AI agent design
• landrun has the most traction (2,156 stars) with the lightest approach — kernel-level Landlock, no containers
• yolobox leads the container-based tools (536 stars) with a batteries-included, "just works" philosophy
• yolo-cage is the most security-focused, with secret scanning, branch isolation, and PR merge prevention
• shai pioneers "cellular development" — agents get write access to one component, read-only to everything else
• Built-in agent sandboxes may eventually obsolete standalone tools, but they're not comprehensive enough yet

---

The Problem

Every major AI coding agent now ships with a "yolo mode":

Agent	Full-Auto Flag
Claude Code	--dangerously-skip-permissions
Codex	--ask-for-approval never
Gemini CLI	--yolo
Copilot	--yolo

These modes are where agents are most productive — no interruptions, no decision fatigue, no waiting. But they're also where agents are most dangerous. A misinterpreted prompt can rm -rf ~, overwrite your SSH keys, push to main, or exfiltrate secrets through a dependency install.

Local sandboxes exist to decouple agent autonomy from machine safety. Let the agent go wild inside the sandbox. Keep your actual system untouchable.

---

Comparison Matrix

Tool	Language	Stars	Isolation	Default Stance	macOS	Network Control	Agent-Specific
yolobox	Go	536	Docker/Podman	Permissive	✅	All-or-nothing	✅ (pre-aliases)
yolo-cage	Python	108	Vagrant/K8s	Restrictive	⚠️ Experimental	Egress proxy + scanning	✅ (Claude focus)
shai	Go	39	Docker	Restrictive	✅	Allowlist per resource set	✅ (supports all)
litterbox	Rust	66	Podman	Moderate	❌ Linux only	Limited	❌ General dev
landrun	Go	2,156	Landlock LSM	Restrictive	❌ Linux only	TCP bind/connect rules	❌ General purpose
Codex built-in	—	—	bubblewrap	Configurable	✅	Workspace-scoped	✅ (Codex only)

---

Philosophy Spectrum

These tools exist on a spectrum from "let it rip" to "trust nothing":

Permissive ◄──────────────────────────────────────────► Restrictive

yolobox          litterbox     Codex built-in     shai     yolo-cage     landrun
(full sudo,      (single dir,  (workspace scope,  (read-only,  (egress scan, (kernel-level
 network open)    SSH prompts)   approval policy)   allowlist)   branch lock)  filesystem ACLs)

Permissive tools (yolobox) optimize for agent productivity. The agent can do anything inside the container — install packages, modify system files, access the network. Protection comes from filesystem isolation: your home directory isn't mounted.

Restrictive tools (shai, yolo-cage, landrun) optimize for damage limitation. The agent gets only what it needs — specific directories, specific network destinations, specific capabilities. Everything else is denied by default.

Neither approach is wrong. The choice depends on your threat model:

• Worried about accidental destruction? → Permissive (yolobox)
• Worried about supply chain attacks? → Restrictive (shai, landrun)
• Worried about secret exfiltration? → Very restrictive (yolo-cage)

---

Product Profiles

yolobox

"Let your AI go full send. Your home directory stays home."

The most popular container-based local sandbox. One command (yolobox claude) drops you into a Docker container with your project mounted, all agent CLIs pre-installed and pre-aliased to skip permissions. Full sudo inside the container.

• Isolation: Docker/Podman/Apple Containers
• Project mount: Read-write at real path
• Home directory: Not mounted (protected)
• Network: Full access by default, no_network flag for air-gapped mode
• Customization: .yolobox.toml with cached derived images
• Best for: Developers who want maximum agent productivity with a simple safety net

Full profile →

---

yolo-cage

"AI coding agents that can't exfiltrate secrets or merge their own PRs."

The most security-focused option. Runs agents inside Vagrant VMs with MicroK8s, with an egress proxy that scans all HTTP traffic for secrets and a dispatcher that enforces branch isolation. Born from the pain of running many agents in parallel on a financial analysis tool.

• Isolation: Vagrant VM + Kubernetes pods
• Secret scanning: Egress proxy scans for API keys (sk-ant-, AKIA, ghp_*), SSH keys, credentials
• Branch isolation: One sandbox per git branch, agents can only push to their assigned branch
• Blocked actions: gh pr merge, gh repo delete, gh api mutations
• Pre-push scanning: TruffleHog checks before every push
• Domain blocklist: pastebin.com, file.io, transfer.sh, etc.
• Best for: Teams running multiple agents in parallel who need secret protection and branch discipline

Full profile →

---

shai

"Sandboxing shell for AI coding agents."

Pioneers "cellular software development" — agents get write access to one component at a time, with read-only access to everything else. The most granular access control of any tool here.

• Isolation: Docker containers
• Default: Read-only workspace mount as non-root user
• Write access: Opt-in per subdirectory via -rw flag
• Resource Sets: Named collections of allowed HTTP destinations, host mounts, ports, env vars
• Apply rules: Auto-select resource sets based on target paths (e.g., Rust agent gets different network access than deployment agent)
• Config: .shai/config.yaml committed to repo, shared across team
• Best for: Security-conscious teams who want per-component, per-context access control

Full profile →

---

litterbox

"Somewhat isolated development environments."

A Linux-only sandbox built on Podman with a unique feature: Wayland socket forwarding lets you run your entire IDE inside the container alongside your agent. Also has a custom SSH agent with per-key exposure and user confirmation prompts.

• Isolation: Podman containers (Linux only)
• Wayland forwarding: Run editors and GUI apps inside the sandbox
• SSH agent: Custom implementation — prompts user before every signing operation
• Scope: Single directory mounted, no access to parent directories
• Honest disclaimers: Explicitly documents limitations (shared kernel, clipboard access, audio recording risk)
• Best for: Linux developers who want their entire dev environment sandboxed, not just agents

Full profile →

---

landrun

"Sandbox any Linux process using Landlock. No root. No containers."

The lightest and most popular tool — uses Linux Landlock LSM for kernel-level filesystem and network access controls without any containers. Not agent-specific, but increasingly adopted for agent sandboxing.

• Isolation: Linux Landlock LSM (kernel-level, no containers)
• Filesystem: Fine-grained per-path read/write/execute controls
• Network: TCP bind/connect restrictions
• Requirements: Linux kernel 5.13+ (no root, no Docker, no configuration files)
• Overhead: Near-zero — just a kernel policy applied to the process
• Best for: Linux users who want the lightest possible sandboxing with kernel-level enforcement

Full profile →

---

Codex Built-in Sandbox

"OS-enforced sandbox that limits what Codex can touch."

OpenAI's Codex CLI ships with a built-in bubblewrap sandbox on Linux that restricts the agent to the current workspace. Not a standalone tool — it's part of the Codex experience.

• Isolation: bubblewrap (user namespace isolation) on Linux
• Scope: Current workspace only
• Approval policy: Configurable — suggest (ask always), auto-edit (auto-approve file edits), full-auto (approve everything)
• Network: Scoped to workspace
• Limitation: Codex only, not usable with Claude Code or other agents
• Note: Claude Code has its own permission system with allowlists/blocklists, but no OS-level sandbox

---

Isolation Technologies Compared

Technology	Used By	Container Required	Root Required	macOS	Kernel Sharing	Escape Risk
Docker	yolobox, shai	Yes	No (daemon does)	✅	Yes	Medium
Podman	litterbox	Yes	No (rootless)	❌	Yes	Lower
Vagrant/VM	yolo-cage	Yes (VM)	No	⚠️	No	Very Low
Landlock LSM	landrun	No	No	❌	Yes (same process)	Lowest overhead
bubblewrap	Codex	No	No	❌	Yes	Low

Docker/Podman share the host kernel — a kernel exploit could escape the container. Docker requires a privileged daemon; Podman runs rootless. Both are widely available and well-understood.

Vagrant VMs (yolo-cage) provide the strongest isolation — separate kernel, no shared attack surface. But heaviest setup (Vagrant + libvirt/QEMU).

Landlock LSM (landrun) is the lightest — kernel-level access controls applied to the process itself. No container overhead. But only controls filesystem and TCP; no memory isolation.

bubblewrap (Codex) uses Linux user namespaces for lightweight process isolation. Lighter than containers, stronger than Landlock for process isolation.

---

Feature Comparison

Feature	yolobox	yolo-cage	shai	litterbox	landrun	Codex
Pre-installed agent CLIs	✅ All 5	Claude only	❌	❌	❌	Codex only
Agent auto-aliases	✅	✅	❌	❌	❌	Built-in
Secret scanning	❌	✅ (egress proxy)	❌	❌	❌	❌
Branch isolation	❌	✅	❌	❌	❌	❌
Per-directory write control	❌	❌	✅	❌	✅	❌
Network allowlisting	❌ (all/none)	✅ (domain block)	✅ (allowlist)	Limited	✅ (TCP rules)	Workspace scope
GUI/IDE support	❌	❌	❌	✅ (Wayland)	N/A	❌
SSH agent protection	❌	❌	❌	✅ (prompts)	N/A	❌
Persistent volumes	✅	✅ (K8s)	❌	✅	N/A	❌
Project-level config	✅ (.yolobox.toml)	✅ (YAML)	✅ (.shai/)	✅	❌	❌
Team-sharable config	❌	❌	✅	✅	❌	❌
Custom image support	✅	❌	✅	✅	N/A	❌
Homebrew install	✅	❌	✅	❌	❌	npm

---

When to Use What

By Threat Model

Threat	Best Tool	Why
Agent runs rm -rf ~	yolobox	Home dir not mounted, simplest setup
Supply chain attack in npm install	shai	Read-only workspace + network allowlist
Agent exfiltrates API keys via HTTP	yolo-cage	Egress proxy scans all HTTP for secrets
Agent pushes to wrong branch	yolo-cage	Branch isolation, 1 sandbox per branch
Untrusted code needs filesystem limits	landrun	Kernel-level per-path access controls
Want entire IDE sandboxed	litterbox	Wayland forwarding for GUI apps

By Platform

Platform	Options
macOS	yolobox (Docker/Podman/Apple Containers), shai (Docker)
Linux	All 6 tools available
CI/CD	landrun (lightest), Codex built-in

By Team Size

Profile	Recommendation
Solo developer, wants simplicity	yolobox — one command, done
Solo developer, security-conscious	landrun (Linux) or shai (macOS)
Team running multiple agents	yolo-cage or shai (sharable configs)
Enterprise with compliance needs	yolo-cage (audit trail via branch isolation) + cloud sandbox (E2B)

---

The Built-in Sandbox Question

Both Codex and Claude Code are investing in built-in safety:

• Codex ships with bubblewrap sandbox on Linux, configurable approval policies, and workspace scoping
• Claude Code has a permission system with allowed/blocked tool lists and sandbox restrictions on Bash commands

Will these make standalone tools unnecessary? Not yet, for two reasons:

1. Agent-specific: Codex sandbox only works with Codex. Claude permissions only work with Claude. If you use multiple agents (most power users do), you need a tool that wraps all of them.

2. Process-level vs system-level: Built-in sandboxes protect against the agent itself. They don't protect against everything the agent runs — a malicious npm package, a compromised pip dependency, or a supply chain attack in a git submodule. External sandboxes add a second layer.

The likely endgame: built-in agent sandboxes get good enough for most users, and standalone tools survive for power users and security-conscious teams.

---

Market Context

An HN thread from early March 2026 cataloged over 20 sandbox solutions launched in the past year, calling it "the new wave of AI agent sandboxes." The space is exploding because the problem is real and growing — more developers running agents in full-auto mode means more potential for damage.

The local sandbox category is distinct from cloud sandboxes (E2B, Daytona, Sprites, Modal):

	Local Sandboxes	Cloud Sandboxes
Runs on	Your machine	Remote servers
Protects	Your filesystem	Multi-tenant isolation
Use case	Individual dev	Production agent infra
Billing	Free (open source)	Usage-based
Networking	Host network	Isolated network
Persistence	Your disk	Ephemeral or managed

Most developers will use both: local sandbox for development, cloud sandbox for production.

---

Bottom Line

Tool	Stars	Philosophy	Best For
yolobox	536	Let it rip, protect home dir	Simplest full-auto experience
yolo-cage	108	Prevent secret exfiltration	Multi-agent teams, security-first
shai	39	Cellular access control	Per-component write isolation
litterbox	66	Sandbox the whole IDE	Linux devs wanting GUI isolation
landrun	2,156	Kernel-level, no containers	Lightest possible Linux sandboxing
Codex built-in	—	Integrated approval + bubblewrap	Codex users on Linux

The local sandbox space is early, fragmented, and growing fast. These tools exist because AI coding agents are powerful enough to be dangerous but not yet smart enough to be trusted. The winner will be whichever approach — permissive containers, restrictive containers, or kernel-level enforcement — proves to be the right trade-off between developer experience and safety.

Or maybe the agents themselves will get safe enough that none of these tools are needed. But that's not today.