yolobox

Overview

yolobox is an open-source CLI tool written in Go that wraps AI coding agents — Claude Code, OpenAI Codex, Gemini CLI, OpenCode, and GitHub Copilot — inside Docker or Podman containers. The pitch is simple: let your agent run with full sudo and zero permission prompts, while your home directory stays completely untouchable.

The name captures the philosophy. "YOLO mode" (running agents without confirmation prompts) is where these tools are most productive, but also most dangerous. yolobox gives you the upside without the rm -rf ~ risk.

How It Works

When you run yolobox claude from a project directory, yolobox:

1. Mounts your project directory at its real path inside the container (e.g., /Users/you/project) — read-write by default
2. Does NOT mount your home directory — your ~/.ssh, ~/.aws, dotfiles, and everything else stays on the host
3. Gives the container user full sudo — the agent can install packages, modify system files, run anything
4. Pre-aliases agent CLIs to skip all permission prompts — claude expands to claude --dangerously-skip-permissions, codex to codex --ask-for-approval never --sandbox danger-full-access, etc.
5. Persists tool state across sessions via Docker volumes, so installed packages and configs survive restarts

The trust boundary is the container. Your project files are read-write (the agent needs to edit code), but everything outside the project is isolated.

Base Image

The yolobox Docker image is batteries-included, built on Ubuntu 24.04:

AI CLIs: Claude Code, Gemini CLI, OpenAI Codex, OpenCode, GitHub Copilot — all pre-configured for full-auto mode.

Runtimes: Node.js 22, Python 3, Go 1.25, Bun 1.3.

Build tools: make, cmake, gcc, pkg-config.

Utilities: git, GitHub CLI, ripgrep, fd, fzf, jq, bat, eza, vim, nano, htop.

If something's missing, the agent has sudo — it can apt-get install whatever it needs.

Project Customization

For project-specific dependencies, yolobox supports .yolobox.toml configuration files:

[customize]
packages = ["default-jdk", "maven"]

For more advanced setups, you can provide a Dockerfile fragment:

[customize]
dockerfile = ".yolobox.Dockerfile"

yolobox builds and caches a derived image. Subsequent runs reuse it until the base image or customization inputs change. This keeps environments reproducible without bloating the base image.

Configuration

Settings live in ~/.config/yolobox/config.toml (global) and .yolobox.toml (per-project):

• Git config forwarding — share your git identity with the container
• GitHub token — extracted from the macOS Keychain for gh CLI
• SSH agent — forward your SSH agent for git operations
• Network isolation — no_network = true for air-gapped sandboxing
• Resource limits — CPU and memory caps
• Extra mounts — mount shared libraries or datasets
• File filtering — --exclude and --copy-as for read-only project views with sensitive files redacted

Priority order: CLI flags > project config > global config > defaults.

API keys (ANTHROPIC_API_KEY, OPENAI_API_KEY, GEMINI_API_KEY, etc.) are automatically forwarded into the container when set on the host.

Container Runtimes

yolobox supports three container runtimes:

• Docker — the default on most setups (Docker Desktop, OrbStack, Colima)
• Podman — rootless option for better security isolation
• Apple Containers — native macOS option on Tahoe+ (cannot build custom images)

Runtime is auto-detected, or explicitly set with --runtime docker|podman|container.

One gotcha: Claude Code needs 4GB+ RAM allocated to Docker. Colima defaults to 2GB, which causes OOM kills.

Security Model

The security model is straightforward: Docker container isolation.

What's protected:

• Home directory (not mounted)
• System files outside the project
• Other projects on the machine
• Network resources (if no_network = true)

What's NOT protected:

• Project files (read-write by default, or read-only with --readonly-project)
• Container escape via kernel vulnerabilities (Docker containers share the host kernel)
• Network access (enabled by default)

The Hacker News discussion raised valid concerns about the container trust boundary. Docker containers are not VMs — a kernel exploit could escape the sandbox. For stronger isolation, rootless Podman with slirp4netns was suggested. yolobox supports Podman as a runtime, giving users the option.

This is pragmatic security, not paranoid security. It protects against the 99% case: an agent that misinterprets a prompt and runs destructive commands. It does not protect against a sophisticated adversary exploiting container escape vulnerabilities.

The Competitive Landscape

yolobox occupies a specific niche in the rapidly growing AI agent sandbox space. An HN thread from early March 2026 cataloged over 20 sandbox tools launched in the past year alone — E2B, Daytona, Sprites, Modal, yolo-cage, shai, litterbox, ctenv, and many more.

The key distinction is local vs. cloud:

Local sandboxes (yolobox, yolo-cage, shai, litterbox): Run on your machine, protect your filesystem, no cloud dependency. Best for individual developers running agents on their own code.

Cloud sandboxes (E2B, Daytona, Sprites, Modal, Northflank): API-driven remote environments for production agent infrastructure. Best for companies building agent products that need scalable, isolated compute.

Within local sandboxes, the differentiation is philosophy:

• yolobox — permissive by default (full sudo, network, read-write). Opt into restrictions.
• shai — restrictive by default. Opt into access (shai -rw . for read-write).
• yolo-cage — focused on preventing secret exfiltration via network filtering.
• litterbox — Linux-only, Podman-based, with Wayland socket forwarding and SSH agent confirmation prompts.

yolobox's "let it rip" philosophy matches the current moment — developers want agents to be maximally productive, and they're willing to accept container-level isolation as "good enough."

Founder

Finbarr Taylor is a Scottish software engineer based in Silicon Valley. He co-founded Shogun, an e-commerce page builder, and led it as CEO to 8-figure ARR with over $100M in venture capital raised. He previously worked at Y Combinator as a software engineer.

He's an active angel investor with a portfolio that includes Deel, CrewAI, Fathom Video, DexScreener, and Bland.ai. The CrewAI investment is notable — it shows he was paying attention to the AI agent ecosystem before building yolobox.

yolobox appears to be a personal project born from real frustration, not a startup. There's no company, no funding, no pricing page. It's an MIT-licensed tool that solves a problem Finbarr had while using AI coding agents.

Traction

• 536 stars and 38 forks on GitHub in ~2.5 months (created January 9, 2026)
• Show HN launch in January 2026 with substantive discussion
• v0.10.4 as of March 2026 — rapid iteration with 10 minor versions
• 161 commits from Finbarr, with 4 other contributors
• 0 open issues — either very stable or very responsive (probably both)
• Homebrew distribution via finbarr/tap/yolobox

The star growth is organic — no Product Hunt launch, no marketing site, no Twitter hype thread. Just a good README and word-of-mouth.

Strengths

• Zero friction — brew install, cd project, yolobox claude. That's it.
• Agent-agnostic — works with every major coding agent CLI
• Well-engineered defaults — the alias table (claude -> --dangerously-skip-permissions, etc.) is a great UX touch
• Project customization — .yolobox.toml with cached derived images is thoughtful
• Active development — shipping features weekly, responsive to feedback

Weaknesses

• Local only — no path to cloud/CI agent sandboxing
• Single-player — no multi-agent coordination, no orchestration
• Container-level isolation — not VM-level. Shared kernel means theoretical escape vectors
• Docker dependency — requires Docker, Podman, or Apple Containers installed and running
• No network filtering — it's all-or-nothing (no_network). No fine-grained allowlists for specific domains
• No telemetry or observability — no way to audit what the agent did inside the container after the fact

Who Should Use This

Good fit: Individual developers who use Claude Code, Codex, or Gemini CLI on local projects and want to run in full-auto mode without risking their home directory. Especially useful for trying "yolo mode" for the first time with a safety net.

Not a fit: Teams building agent products that need scalable sandbox infrastructure (use E2B, Daytona, or Sprites). Enterprises needing audit trails and compliance. Developers who need fine-grained network policies or secret management.

Bottom Line

yolobox is the "just enough safety" solution for local AI agent development. It doesn't try to be a platform, a product, or a business — it's a well-crafted open-source tool that solves a specific, painful problem. The fact that it has 536 stars with zero marketing suggests developers are actively searching for this exact solution.

The interesting question is whether "local container sandbox" remains a viable category as agent platforms mature. Codex already has built-in sandboxing. Claude Code's permission system is getting more granular. If the agents themselves solve the safety problem, yolobox becomes unnecessary. But right now, in March 2026, agents are still dangerous enough that a safety net is worth having — and yolobox is the simplest one available.