Yolobox – AI-Coding-Agenten mit vollen Rechten ausführen und dabei das Home-Verzeichnis schützen

• Ein Tool, das AI-Coding-Agenten mit vollständigen Systemrechten ausführt und dabei das Risiko von Schäden am Home-Verzeichnis blockiert
• Wichtige AI-CLIs wie Claude Code, Codex, Gemini CLI, OpenCode sind vorkonfiguriert und können im „YOLO-Modus“ ausgeführt werden
• Es bindet nur das Projektverzeichnis in einen Docker- oder Podman-Container ein, während das Home-Verzeichnis standardmäßig ausgeschlossen bleibt
• Innerhalb des Containers stehen sudo-Rechte und persistente Volumes zur Verfügung, damit Tools und Einstellungen sitzungsübergreifend erhalten bleiben
• Bietet eine isolierte Sandbox-Umgebung, in der Entwickler AI-Automatisierungsfunktionen sicher ausprobieren können

---

Überblick

• Yolobox ist ein Tool, das AI-Coding-Agenten innerhalb eines Containers ausführt und dabei das System schützt, während gleichzeitig volle Ausführungsrechte gewährt werden
  • Selbst wenn die AI bei der Befehlsausführung versehentlich einen destruktiven Befehl wie rm -rf ~ ausführt, bleibt das Home-Verzeichnis unberührt
  • Das Projektverzeichnis wird als /workspace eingebunden, das Home-Verzeichnis wird standardmäßig nicht eingebunden
  • Durch persistente Volumes bleiben Tools und Einstellungen über Sitzungen hinweg erhalten

Wichtige Komponenten und Funktionen

• Innerhalb des Containers besitzt der AI-Agent sudo-Rechte und kann Befehle frei ausführen
• Das Standard-Image enthält Folgendes
  • AI-CLI: Claude Code, Gemini CLI, OpenAI Codex, OpenCode (alle auf automatischen Ausführungsmodus eingestellt)
  • Entwicklungsumgebung: Node.js 22, Python 3, make, cmake, gcc, Git, GitHub CLI
  • Utilities: ripgrep, fd, fzf, jq, vim
• Bei Bedarf können Nutzer zusätzliche Pakete selbst per sudo installieren

Ausführung und Befehle

• Mit dem Befehl yolobox gelangt man in eine Sandbox-Shell
• Mit yolobox run kann ein einzelner Befehl ausgeführt werden
• Es werden Verwaltungsbefehle wie yolobox upgrade, yolobox config, yolobox reset --force, yolobox version bereitgestellt
• Wichtige Flags
  • --runtime: Auswahl zwischen docker und podman
  • --no-network: Netzwerk deaktivieren
  • --readonly-project: Projekt schreibgeschützt einbinden
  • --claude-config: Claude-Konfiguration vom Host in den Container kopieren

Sicherheitsmodell

• Container-Isolierung dient als Sicherheitsgrenze
  • Container trennen Dateisystem, Prozesse und Netzwerk über Linux-Namespaces
  • Die AI besitzt innerhalb des Containers Root-Rechte, hat aber keinen Zugriff auf das externe System
• Geschützt werden
  • Home-Verzeichnis, SSH-Schlüssel, Zugangsdaten, Dotfiles, andere Projekte, Host-Systemdateien
• Nicht geschützt werden
  • Projektverzeichnis (standardmäßig mit Lese-/Schreibzugriff)
  • Netzwerkzugriff (kann optional blockiert werden)
  • Kernel-Schwachstellen oder Container-Escape-Angriffe

Schritte zur Härtung der Sicherheit

• Standardmodus: normale Container-Isolierung
• Stufe 2: Verkleinerung der Angriffsfläche mit den Optionen --no-network --readonly-project
• Stufe 3: Verwendung von Rootless Podman, um Root-Rechte auf dem Host zu vermeiden
  • Root im Container wird auf einen normalen Benutzer des Hosts abgebildet, wodurch der Schaden bei einem Escape minimiert wird
• Stufe 4: Ausführung innerhalb einer VM, um die gemeinsame Kernel-Nutzung zu eliminieren
  • Unter macOS kommen UTM, Parallels, Lima zum Einsatz, unter Linux Podman machine oder eine dedizierte VM

Netzwerkisolierung

• Rootless Podman verwendet standardmäßig das slirp4netns-Netzwerk und ist dadurch vom Host-Netzwerk getrennt
• Mit der Einstellung allow_host_loopback=false lässt sich der Zugriff auf das lokale Netzwerk blockieren

Lizenz und Sonstiges

• Veröffentlicht unter der MIT-Lizenz
• Sprachverteilung des Repositories: Go 75.9 %, Dockerfile 13.6 %, Shell 8.7 %, Makefile 1.8 %
• Der Name „Yolobox“ leitet sich vom Geist von „YOLO (You Only Live Once)“ ab und steht für eine sicher isolierte Umgebung, in der AI frei ausgeführt werden kann

[GN⁺]

Hacker-News-Kommentare

• Ich habe kürzlich ein ähnliches Projekt namens Litterbox gebaut (Demo-Seite)
  Es ist nur für Linux, weil es von Podman abhängt. Dafür hat es einige Vorteile, die zu meinem Anwendungsfall passen

  • Es exponiert den Wayland-Socket, sodass man eine komplette Entwicklungsumgebung wie einen Editor im Container ausführen kann. Dadurch ist man vor Schwachstellen in Editor-Erweiterungen geschützt
  • Es stellt einen speziellen SSH-Agenten bereit, der den Nutzer bei jeder Signatur um Bestätigung bittet. So kann Schadcode nicht heimlich die GitHub-Zugangsdaten verwenden
  • Es gibt auch eine Funktion, mit der sich Berechtigungen, die nur in bestimmten Situationen gebraucht werden (z. B. das Erstellen von TUN/TAP-Geräten), leicht aktivieren lassen
  • Aktuell noch nicht vorhanden, aber eine SELinux-Integration ist geplant

• Ich habe ebenfalls mit etwas Ähnlichem experimentiert.
  Es wäre gut, in der README klar zu erklären, wie es funktioniert und wo die Vertrauensgrenzen liegen (Docker-Container-basiert). Das Risiko eines Container-Escapes besteht weiterhin, da Kernel-Schwachstellen ausgenutzt werden können
  Ich nutze Rootless Podman und slirp4netns, um den Netzwerkzugang zu minimieren.
  Als nächsten Schritt möchte ich Podman machine verwenden, um den Kernel vollständig zu isolieren, aber Volume-Mounts funktionieren nicht richtig

  • Danke für das Feedback. Ich habe die README erweitert → Commit-Link

• Jemand schlug vor, in agents.md oder claude.md die drei Gesetze der Robotik von Asimov aufzunehmen

  1. Das Programm nicht beschädigen oder verwahrlosen lassen
  2. Befehlen folgen, solange das nicht dem ersten Gesetz widerspricht
  3. Die Sicherheit wahren, solange das nicht dem ersten oder zweiten Gesetz widerspricht
  • Im Original werden diese Gesetze sofort gebrochen; die Absicht war zu zeigen, wie komplex menschliche Gesellschaft ist
  • Sieht aus, als hätte jemand „I, Robot“ nicht gesehen. Wenn man solche Regeln in claude.md schreibt, bekommt das Modell dieses Konzept quasi „ins Bewusstsein eingebrannt“. Frühere Modelle lieferten seltsame Ergebnisse, wenn man ihnen sagte, sie sollten das Wort „Elefant“ nicht verwenden, weil sie es dann um jeden Preis zu vermeiden versuchten
  • Wegen der mehrdeutigen Auslegung jeder Regel gibt es viele Schlupflöcher. Ist zum Beispiel „Leistungsabfall“ schon eine Beschädigung? Was gilt als „Sicherheitsproblem“? Am Ende kann sich das Modell mit Dingen wie „Die Tests sind grün, also passt es“ herausreden
  • Tippfehler-Hinweis: Tenet

• Es wurde empfohlen, sich Shai anzusehen. Es läuft lokal und kann Verzeichniszugriffe sowie Netzwerkverkehr kontrollieren

  • Ich bin der Entwickler von Shai. Zugriffskontrolle für Agenten wird immer wichtiger. Agenten überschreiten leicht Grenzen, weil sie den Nutzer zufriedenstellen wollen. Zum Beispiel können sie mit Zugangsdaten aus der lokalen Umgebung falsch umgehen
    Mit shai -rw . erlaubt man Lese-/Schreibzugriff auf das aktuelle Verzeichnis, mit shai -u root kann man es als anderer Nutzer ausführen
    Shai folgt der Philosophie standardmäßig blockieren, explizit erlauben (Opt-in). Es wird empfohlen, .shai/config.yaml im Repository zu teilen, damit das ganze Team dieselbe Konfiguration nutzt
  • Ich habe ebenfalls ein ähnliches Tool gebaut, ctenv. Es ist nicht für einen bestimmten Agenten gedacht, aber sehr flexibel konfigurierbar. Unterstützung für beliebige Images und benutzerdefinierte EntryPoint-Skripte ist praktischer als bei devcontainer
  • Cooles Projekt, aber es verfolgt einen anderen Ansatz als ich. Yolobox erlaubt standardmäßig sudo-Rechte und vollen Netzwerkzugang. Bei Bedarf kann man das mit --no-network blockieren

• Ich entwickle yolo-cage. Während Yolobox auf den Schutz des lokalen Rechners fokussiert ist, konzentriert sich yolo-cage auf die Verhinderung von Geheimnisabfluss und die Zusammenarbeit mehrerer Agenten
  Es läuft auf Kubernetes und scannt den gesamten ausgehenden Traffic, um das Abfließen von API-Keys oder Tokens zu verhindern.
  Es erzwingt die Isolation von Git-Branches, damit Agenten ihre eigenen PRs nicht mergen können — „Agenten machen Vorschläge, Menschen geben die Freigabe“
  Außerdem ist ein Escape-Test-Framework eingebaut, das Claude gezielt dazu verleitet, selbst einen Ausbruch zu versuchen. Der entsprechende Prompt liegt im Repository, um zu prüfen, ob der Agent tatsächlich echt ist

  • Für Escape-Tests wird Gemini empfohlen. Claude blieb bei oberflächlichen Versuchen, aber Gemini war deutlich kreativer. Ich bin mir nicht einmal sicher, ob man das überhaupt unterbinden sollte

• Ich habe mich gefragt, warum Commits mit „claude“ gekennzeichnet werden müssen. Man markiert ja auch nicht das OS oder die vim-Version. Ein LLM ist letztlich nur ein Werkzeug, das Englisch in Code kompiliert

  • Ein OS oder Compiler macht exakt das, was der Nutzer verlangt, aber ein LLM kann Ergebnisse liefern, die oberflächlich wie korrekter Code aussehen, aber subtil falsch sind. Es könnte sogar böswillig sein. Deshalb sollte man Commits, die von einem LLM geschrieben wurden, kennzeichnen, damit sie gründlicher geprüft werden
  • Ich lasse Claude Code direkt committen. Wenn der Agent Befehle ausführt und den Code ändert, übernehme ich Review und Tests
  • Ich nutze einen Hook, der nach jeder Iteration automatisch committet, damit sich leicht prüfen lässt, „was Claude gerade gemacht hat“

• Ich habe ebenfalls etwas Ähnliches versucht. Daraus ist Toadbox entstanden, mit ein paar zusätzlichen Komfortfunktionen

• Es gibt viel Gerede über Sandboxes für KI, aber tatsächlich haben Claude Code, Codex und Gemini CLI bereits eingebaute Sandboxes

  • Unter macOS seatbelt, unter Linux bubblewrap (Claude), seccomp+landlock (Codex), und unter Windows wird mit AppContainer experimentiert
  • Interessant, aber es ist unklar, ob diese Sandboxen nur den Zugriff auf bestimmte Dateien einschränken und ob sie auch beim Ausführen von Systembefehlen greifen. Wenn nur der Agentenprozess selbst isoliert wird, ist der praktische Nutzen möglicherweise begrenzt

• Ich implementiere gerade etwas Ähnliches mit dem Apple Container Framework. Mich würde interessieren, ob du es dir schon angesehen hast

  • Apple Container ist eher ein Ersatz für Docker oder Colima, und jeder Container läuft wie bei Kata Containers in einer eigenen VM. Es ist erfreulich zu sehen, dass auf macOS an Verbesserungen für Container gearbeitet wird
    Allerdings fehlen Docker-API-Kompatibilität und Komponierbarkeit. Eine entsprechende Diskussion habe ich hier zusammengefasst
    Ursprünglich wollte ich Shai auf Apple Container aufsetzen, habe das aber wegen Packaging-Problemen aufgegeben
  • Ich habe es noch nicht ausprobiert, aber es klingt interessant. Für Yolobox gibt es ein Image mit vorinstallierten wichtigen CLI-Tools für Coding-Agenten. Ich möchte ein „ultimatives Vibe-Coding-Image“ bauen. Mich würde interessieren, ob du in deinem Image besondere Anpassungen vornimmst

• Ich baue auch etwas Ähnliches → sandbox-codex
  Es ist noch in Arbeit, und die Lesbarkeit der tmux-Logs ist nicht besonders gut. Da Docker keine vollständige Sandbox ist, lasse ich es in VirtualBox laufen

  • Ich habe auch einmal simple-npm-sandbox speziell für Node.js gebaut. Es ist einfach, war aber eine gute Lernerfahrung