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. ^[1] The pitch is simple: let your agent run with full sudo and zero permission prompts, while your home directory stays completely untouchable. As of June 2026 the project also has a minimal official site at yolobox.dev. ^[2]

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: ^[1]

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: ^[1]

[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: ^[1]

• 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. ^[3]

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. ^[3] 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. ^[4]

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). ^[3]
• yolo-cage — focused on preventing secret exfiltration via network filtering. ^[4]
• 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. ^[5] 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. ^[5] 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

As of June 11, 2026:

• 603 stars and 45 forks on GitHub in five months (created January 9, 2026) — up from 536 stars and 38 forks at the March profile date ^[1]
• Show HN launch in January 2026 (122 points) with substantive discussion ^[3]
• v0.18.4 released June 9, 2026 — up from v0.10.4 in March, still shipping roughly weekly ^[1]
• 214 commits from Finbarr, with 10 other contributors (up from 4 in March) ^[1]
• 0 open issues — either very stable or very responsive (probably both) ^[1]
• Homebrew distribution via finbarr/tap/yolobox, plus a curl install script ^[2]

The growth is organic — no Product Hunt launch, no Twitter hype thread. The one marketing concession since March is the official site at yolobox.dev, which is essentially a styled README. ^[2]

What's Changed Since March 2026

Development pace held steady — eight minor versions (v0.11 through v0.18) shipped between mid-April and early June: ^[1]

• --no-project flag (v0.16.0) — skip the automatic project mount entirely
• OpenCode config sync (v0.15.0) — contributed by a community member
• RTK command-output compression and yolobox upgrade --check (v0.18.0, May 18)
• Clipboard bridge, runtime context manifest, fork isolation, and .localhost reverse-proxy integration — Finbarr's May 2026 blog post describes yolobox evolving from a simple sandbox into infrastructure for running parallel agents, each fork treated as "another developer's machine" ^[6]

That blog post is the clearest signal of direction: "The goal is not to make agents special. The goal is to make agents less special." ^[6] yolobox is drifting from "safety net" toward "local multi-agent workbench" — still free, still MIT, still no business attached.

What Developers Say

All substantive public commentary still traces to the January 2026 Show HN thread; no significant new practitioner discussion surfaced in searches as of June 11, 2026. From that thread: ^[3]

• akurilin: "I love that the community as a whole is exploring all these different methods of containing undesirable side effects from using coding agents. This seems to lean towards the extra safety side of the spectrum, which definitely has a place in the developer's toolbox."
• mtlynch: "I think it's worth noting that the trust boundary is a Docker container, so there's still a risk of container escape if the agent exploits (or is tricked into exploiting) a kernel vulnerability."
• m-hodges, on the category's durability: "I love all this stuff but it all feels like temporary workflow fixes until The Agent Companies just ship their opinionated good enough way to do it."
• Finbarr himself, on the philosophy: "I want the agents to have max power with a slightly smaller blast radius."

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-machine — fork isolation (added spring 2026) enables parallel local agents, but there's still no orchestration layer or cross-machine coordination ^[6]
• 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

Recommended for individual developers who want full-auto agents on local projects with a real safety net — yolobox remains the simplest option in the category, it's free, and the June 2026 check shows it healthier than ever: 603 stars, v0.18.4 shipped June 9, zero open issues, and a growing contributor base. ^[1] Not recommended for teams that need cloud-scale sandbox infrastructure, audit trails, or fine-grained network policy — that's E2B/Daytona territory, and yolobox isn't trying to compete there.

Outlook: the open question from March still stands — whether "local container sandbox" survives as agents ship better built-in sandboxing — but yolobox is hedging well by evolving into a local parallel-agent workbench (fork isolation, clipboard bridge, reverse-proxy integration). ^[6] It doesn't try to be a platform, a product, or a business, and as a personal project with one primary maintainer, continuity risk is the main caveat. As of June 2026, agents are still dangerous enough that the safety net is worth having.