Sandboxed runner for AI coding agents. No more permission fatigue. Your files stay untouched until you say otherwise.
AI coding agents want to edit your files and run commands, so you must choose between them constantly asking your permission, or bypassing permissions and risking a catastrophe.
Until now.
Let your agent live dangerously in a sandbox, then review the changes and decide what to keep.
You Sandbox Your project
│ │ │
├─ yoloai new fix-bug . ├─ sandbox copy of project │
│ │ │
├─ << your prompt(s) >> ├─ agent works freely │
│ │ (no permission prompts) │
│ │ │
├─ yoloai diff fix-bug ├─ shows what changed │
│ │ │
├─ yoloai apply fix-bug │ ├─ patches applied
│ (you choose which ones) │ │
│ │ │
├─ yoloai destroy fix-bug ├─ destroys sandbox │
Permission fatigue is real. After a hundred approve/deny prompts you stop reading and just hit "yes" — or you reach for --dangerously-skip-permissions and hope for the best. Neither is great.
yoloAI takes a different approach: let the agent do whatever it wants inside a disposable container. Your originals are never modified. When the agent is done, review the diff and choose what to keep.
- Your files are untouchable. The agent works on an isolated copy. Originals never change until you say so.
- Git-powered review.
diffshows exactly what changed.applypatches your project cleanly, preserving individual commits. - No permission prompts. The container is disposable — agents run with full access inside the sandbox.
- Persistent agent state. Session history and config survive stops and restarts.
- Easy retry.
yoloai resetre-copies your original for a fresh attempt.
- Not an orchestrator. The orchestrator space is crowded (60+ tools) and rapidly evolving. yoloAI's value is the sandbox layer — it provides composable primitives (
new,diff,apply) that orchestrators can build on top of, not a coordination framework. - Not an autonomous agent platform. yoloAI runs one agent in one sandbox — it doesn't decompose tasks, coordinate multiple agents, or manage autonomous workflows. You drive the loop.
- Not a permission system. Instead of asking you to approve every file write and shell command, yoloAI eliminates the question entirely: the agent does whatever it wants in a disposable sandbox, and you review the result.
- Not a hosted service. yoloAI is a local CLI tool. No accounts, no cloud, no vendor lock-in. Just a Go binary and your chosen sandbox backend.
- Not a live-sync tool. Your originals are protected by default. The agent works on an isolated copy and changes only land when you say so. (Live mounts are available via
:rwmode for those who want them.)
# Latest release
go install github.com/kstenerud/yoloai/cmd/yoloai@latest
# Latest development version (beta)
go install github.com/kstenerud/yoloai/cmd/yoloai@mainRequires Go 1.24+. The binary is placed in $GOPATH/bin (typically ~/go/bin).
git clone https://github.com/kstenerud/yoloai.git
cd yoloai
make build
sudo mv yoloai /usr/local/bin/ # or add to PATHSingle Go binary, no runtime dependencies beyond your chosen backend. On first run, yoloAI builds its base image (~2 min) and creates ~/.yoloai/.
# Authenticate (yoloAI picks up existing credentials automatically)
export ANTHROPIC_API_KEY=sk-ant-... # Claude Code
export GEMINI_API_KEY=... # Gemini CLI
# Or just let it pick up your already authenticated session
# 1. Spin up a sandbox. Agent starts working immediately when you supply a prompt here
yoloai new fix-bug ./my-project --prompt "fix the failing tests"
# 2. See what the agent changed
yoloai diff fix-bug
# 3. Apply the good parts to your real project
yoloai apply fix-bug
# 4. Toss the container
yoloai destroy fix-bugyoloai new exploration ./my-project -a
# You're inside the agent, running in tmux in the sandbox.
# Ctrl-B, D to detach.
# yoloai attach exploration to reconnect.For longer tasks, work in a commit-by-commit loop. Keep two terminals open — one for yoloAI, one for your normal shell.
┌─ YOLO shell ──────────────────────┬─ Outer shell ─────────────────────┐
│ │ │
│ yoloai new myproject . -a │ │
│ │ │
│ # Tell the agent what to do, │ │
│ # have it commit when done. │ │
│ │ yoloai apply myproject │
│ │ # Review and accept the commits. │
│ │ │
│ # ... next task, next commit ... │ │
│ │ yoloai apply myproject │
│ │ │
│ │ # When you have a good set of │
│ │ # commits, push: │
│ │ git push │
│ │ │
│ │ # Done? Tear it down: │
│ │ yoloai destroy myproject │
└───────────────────────────────────┴───────────────────────────────────┘
The agent works on an isolated copy, so you can keep iterating without risk. Each apply patches the real project with only the new commits since the last apply.
| Backend | Supported Hosts | Dependencies |
|---|---|---|
| docker | Linux, macOS, Windows (WSL2) | Docker Engine or Docker Desktop |
| podman | Linux, macOS | Podman (brew install podman on macOS) |
| tart | macOS (Apple Silicon) | Tart (brew install cirruslabs/cli/tart) |
| seatbelt | macOS (any) | None (uses built-in sandbox-exec) |
Optionally upgrade the OCI runtime for stronger isolation on container backends:
| Mode | Description |
|---|---|
standard |
Default runc — standard Linux namespaces and cgroups |
gvisor |
Userspace kernel (gVisor/runsc) — syscall interception, no KVM needed |
kata |
Kata Containers (VM-based) — hardware VM isolation (experimental) |
kata-firecracker |
Kata + Firecracker microVM — lightweight VM isolation (experimental) |
# Use gVisor for all new sandboxes
yoloai config set security gvisor
# Or per sandbox
yoloai new task . --security gvisorkata and kata-firecracker are experimental and require Kata Containers to be installed.
| Mode | Description |
|---|---|
claude |
Runs Claude Code via API key or subscription credentials (default) |
codex |
Runs Codex via API key or subscription credentials |
gemini |
Runs Gemini via API key or subscription credentials |
aider |
Runs Aider (your config is copied in) |
opencode |
Runs OpenCode (your config is copied in) |
shell |
Runs a tmux shell with all agents credentials seeded |
idle |
Runs an idle process to allow MCP proxying |
Use yoloai system agents to list available agents.
- Usage Guide — commands, flags, workdir modes, configuration, security
- Roadmap — upcoming features
- Architecture — code navigation for contributors
Early access. Core workflow works, rough edges expected. Feedback welcome.