Berry Wiki

yoloAI

Properties2
tagsai, sandboxing
aliasesYoloai

8 min read

yoloAI

Project Summary

yoloAI is an open-source command-line runner for AI coding agents. It lets an agent work unattended inside a disposable sandbox while keeping the original project, most host credentials, and optional network access outside the agent’s reach.

  • License: MIT.
  • Implementation: A single Go binary plus the selected sandbox backend.
  • Core review gate: Create a sandbox, let the agent work on a copy, inspect the diff, apply selected work, then destroy the sandbox.

Problem Solved

Coding agents often pause for repeated permission prompts. Turning those prompts off on a normal workstation gives a mistaken or prompt-injected agent broad access to source files, credentials, and the network.

yoloAI moves the safety check from many small approvals to one review boundary: the agent can act freely inside the sandbox, but its edits do not reach the real project until the developer approves them.

How It Works

  1. yoloai new creates a sandbox and, by default, an isolated copy of the project.
  2. The chosen coding agent runs inside that sandbox, interactively or from a supplied prompt.
  3. yoloai diff shows the agent’s changes.
  4. yoloai apply replays commits or applies a patch to the original project.
  5. yoloai destroy removes the sandbox.

Longer sessions can be stopped, restarted, attached to, cloned, or reset. A headless run mode supports scripts and continuous integration jobs. Git runs inside the sandbox for diff and commit handling, which preserves repository filters and behavior without sharing the host repository’s Git object store.

Security And Isolation Boundary

  • Project files: Safe-by-default :copy mode gives the agent a separate copy. Git-ignored files are excluded. The original directory changes only through apply.
  • Host data: The sandbox gets a minimal environment. Host environment variables and directories are absent unless explicitly passed or mounted.
  • Extra directories: Read-only by default; writable mounting is an explicit choice.
  • Process isolation: Available strength ranges from normal containers to gVisor, Kata/QEMU virtual machines, and Kata/Firecracker micro-virtual machines. macOS can use Apple Container, Seatbelt, or Tart.
  • User identity: Containers run as a non-root user matching the host user’s user and group IDs.
  • Dangerous choices: :rw exposes the real work directory. container-privileged gives near-full host-kernel access and does not protect against a deliberate escape.
  • Review integrity: The diff/apply gate limits filesystem damage, but the developer still has to review generated code for backdoors, bad logic, or unsafe dependencies.

Supported Platforms And Agents

Hosts And Backends

  • Linux: Docker, Podman, and containerd with Kata; optional gVisor, QEMU, or Firecracker isolation.
  • macOS: Docker Desktop or OrbStack, Podman, Apple Container on supported Apple Silicon systems, Tart, or built-in Seatbelt.
  • Windows: Docker through WSL2, the Windows Subsystem for Linux.

Built-In Agent Modes

  • Claude Code
  • Codex
  • Gemini CLI
  • Aider
  • OpenCode
  • Shell mode for other tools
  • Idle mode for proxying Model Context Protocol (MCP) servers

VS Code attachment and Remote Tunnels are supported. yoloAI can also expose sandboxes as MCP tools or proxy an MCP server inside a sandbox.

Workflow And Setup

  • Install a signed release binary, use Homebrew, install with Go, or build from source.
  • Choose or accept a detected backend. The only runtime dependency is that backend.
  • On first use, yoloAI builds a base image and stores state under ~/.yoloai/ by default; --data-dir can relocate it.
  • Create a sandbox from a project, run or attach to the agent, review with diff, apply accepted work, and destroy the sandbox.
  • Profiles can define a per-project image, setup steps, resources, ports, network rules, and agent defaults.

Network And Credential Handling

  • Network default: Network isolation is available but is not the documented global default; configuration lists network.isolated as false unless enabled.
  • Restricted mode: --network-isolated uses a default-deny allowlist containing required agent service endpoints plus explicitly allowed domains.
  • Offline mode: --network-none removes network access.
  • Host environment: No ambient host environment is copied into the sandbox. Values passed with --env are explicit exceptions.
  • Claude brokering: On supported backends, Claude API or long-lived subscription credentials remain on the host. A host-side proxy replaces a harmless sandbox token with the real credential.
  • Other credentials: Unsupported agents, authentication forms, or backends fall back to read-only credential files inside the sandbox. This means not every supported agent keeps its credential fully outside the sandbox.
  • Important limit: Brokering prevents credential theft, but an agent can still misuse the allowed provider access while the session is active.

Strengths

  • Strong review boundary: The normal workflow never gives the agent write access to the original project.
  • Broad backend choice: Supports simple containers and stronger virtual-machine boundaries under one interface.
  • Broad agent choice: Five major coding agents plus generic shell operation.
  • Practical lifecycle: Interactive, headless, resumable, cloneable, scriptable, and MCP-aware.
  • Secret reduction: Minimal ambient data, Git-ignore filtering, read-only secret files, and host-side Claude credential brokering.
  • Developer-controlled egress: Allowlist and no-network modes reduce data-exfiltration paths.
  • Supply-chain signals: Release archives are signed and include GitHub build provenance.

Limits And Risks

  • Public beta: Version 0.x interfaces may change.
  • Network isolation is opt-in: A default installation may allow normal outbound access unless the user changes configuration or passes the isolation flag.
  • Credential protection varies: Full host-side brokering currently applies mainly to Claude and supported backends; other paths place credentials in read-only files that a compromised agent may still read.
  • Container boundary varies: Standard containers share the host kernel. Stronger gVisor or virtual-machine modes need extra host support.
  • Privileged mode is high risk: It can permit deliberate container escape.
  • Writable mounts bypass the main promise: :rw changes real files immediately.
  • Ignored inputs may be missing: Safe copy mode excludes Git-ignored files and common build artifacts, so dependencies may need rebuilding or deliberate provisioning.
  • Single tracked work directory: Extra directories can be mounted, but diff/apply applies only to the main work directory. The HN author of clawk specifically noted multi-repository worktrees as a need yoloAI does not address in the same way.
  • Code quality remains a human concern: Isolation contains runtime actions; it cannot prove that applied code is correct or harmless.
  • Independent security audit: No completed third-party audit was found in the checked official material. Automated tests and a nightly audit badge exist, but their coverage is not equivalent to an independent security review.

Project Activity And Current Maturity

Checked 2026-07-14.

  • The repository labels the project public beta and says the core workflow is stable and used daily.
  • Latest visible release: v0.7.0, published 2026-07-06.
  • GitHub showed roughly 2,141 commits, 152 stars, 7 forks, 6 open issues, and 6 open pull requests during review. These counts change over time.
  • The latest release was eight days old when checked, which indicates active development.

Best Fit

  • Developers who want coding agents to run unattended without direct access to their real working tree.
  • People who want one local tool across Claude Code, Codex, Gemini CLI, Aider, or OpenCode.
  • Teams willing to review diffs before accepting agent work.
  • Security-conscious users who can enable network isolation and select a stronger backend when the threat calls for it.

It is less suitable when an agent must directly coordinate edits across several repositories in one reviewed unit, when setup dependencies for stronger isolation are unacceptable, or when policy requires a completed independent security audit.

Comparison-Relevant Facts

  • Isolation unit: Disposable copy of one main work directory.
  • Change transfer: Git diff, commit replay, squash patch, exported patch, or selected commits.
  • Backends: Six named backend families with selectable isolation strength.
  • Network: Open, allowlist, or none; restricted networking must be enabled.
  • Credentials: Claude can use a host-side broker; other cases may receive read-only mounted files.
  • Agent breadth: Claude Code, Codex, Gemini CLI, Aider, OpenCode, and generic shell.
  • Remote editing: VS Code container attachment or Remote Tunnel.
  • Automation: Headless runs, structured JSON output, public Go API, and MCP integration.
  • Multi-repository workflow: Auxiliary directories are supported, but only the main work directory participates in diff/apply.
  • Cost and hosting: Free and open source; runs locally with no yoloAI account, but agent providers and chosen infrastructure may have their own costs.

HN Comment Context

In the clawk discussion, a commenter linked yoloAI because both projects follow a similar local sandbox approach. yoloAI’s author then summarized its backends, network restrictions, secret controls, lack of ambient host data, copy/diff/apply workflow, supported agents, VS Code tunnels, lifecycle commands, MCP support, Go API, single-binary packaging, and free/open-source license.

The clawk author replied that the projects have substantial overlap and specifically liked yoloAI’s new / diff / apply / destroy workflow. The stated distinction was clawk’s focus on one controlled, network-restricted virtual-machine path and a sandbox spanning multiple repository worktrees, versus yoloAI’s many backends and one primary diff/apply work directory.

Sources

Graph View