AgentBox: Parallele KI-Agenten in sandboxed VMs per Einzelbefehl

agentbox claude: eine Box, ein Befehl, ein Agent

Das README von madarco/agentbox beschreibt das Ziel knapp: mehrere Agenten parallel, per einzelnem Befehl, auf dem eigenen Rechner, selbst gehostet oder in der Cloud. Der Einstieg beginnt mit der Installation über npm und `agentbox install`. Danach startet `agentbox claude` die erste Box: Das Kommando erzeugt eine Docker-basierte VM, überträgt Einstellungen und Arbeitsbereich und öffnet Claude Code in einer trennbaren tmux-Sitzung.

Der Assistent fragt optional ab, ob Projektbibliotheken installiert und der Entwicklungsserver gestartet werden sollen. Für weitere Agenten ist kein neuer Konfigurationsaufwand nötig: Ein zweites `agentbox claude` legt eine weitere Box an, die `agentbox attach` mit ihrem Index oder Namen wieder aufnimmt. Auf diese Weise entstehen parallele Sitzungen, ohne dass jede Umgebung von Hand eingerichtet wird.

Zugriff auf die Boxen: shell, url, screen und code

Das README stellt für den Betrieb mehrere Zugriffsbefehle bereit. `agentbox shell` öffnet eine bash-Sitzung in der Box, `agentbox logs` zeigt die letzten Zeilen eines Box-Dienstes, `agentbox dashboard` listet Boxen und die aktive Agenten-Sitzung. `agentbox url` erreicht eine Webanwendung auch ohne `expose:`-Dienst, `agentbox screen` öffnet den noVNC-Betrachter, `agentbox code` bindet die Box über die Dev-Containers-Erweiterung in VS Code oder Cursor ein.

Der Workspace liegt unter `/workspace`. `agentbox open` zeigt ihn im Finder, `agentbox download` holt ihn gitignore-bewusst zurück in den Host-Arbeitsbereich, `agentbox cp` kopiert Dateien in beide Richtungen; die Richtung entscheidet ein `name:`-Präfix. Wer die Sitzung trennen und später fortsetzen will, verlässt die tmux-Sitzung mit control-a d und kehrt über `agentbox attach <index>` zurück.

Checkpoints und pause: Zustand einfrieren statt neu aufbauen

Zustand ist bei AgentBox ein dokumentiertes Thema. `agentbox checkpoint` listet bestehende Checkpoints, `agentbox checkpoint create` erfasst den warmen Zustand einer Box; daraus soll der Start neuer Boxen laut README unter einer Sekunde dauern. `agentbox pause` friert eine laufende Box ein, `agentbox unpause` holt sie zurück, auch dieser Wechsel gilt laut Doku als weitgehend verzögerungsfrei. So koexistieren mehrere Projektzustände, ohne dass Ressourcen dauerhaft gebunden bleiben.

Die Persistenz liegt in der FUSE-Überlagerung der Box. `agentbox stop` beendet eine Box und erhält ihre obere Ebene samt `node_modules`, `agentbox start` hängt sie wieder ein. `agentbox destroy` beziehungsweise `rm` löscht dagegen Box und obere Ebene zusammen. Wer Speicher freigeben will, prüft zuerst `agentbox list` auf offene Zustände und nutzt `agentbox prune` nur für verwaiste Einträge.

Cloud-Betrieb: hetzner, vercel, daytona und e2b

Die lokale Docker-Ausführung ist nur ein Betriebsmodell. Das README listet remote Docker, Hetzner, Vercel, Daytona und E2B als Ziele, Daytona mit der Einschränkung Partial. `agentbox hetzner claude` startet Claude Code auf einer Hetzner-Instanz. Für die Anmeldung gibt es eigene Login-Kommandos: `agentbox vercel login`, `agentbox hetzner login`, `agentbox daytona login`, `agentbox e2b login` und `agentbox digitalocean login`. Die Tokens liegen laut README in `~/.agentbox/secrets.env`.

`agentbox remote-docker doctor <host>` prüft einen per SSH eingebundenen Rechner und verbindet sich als der eigene Benutzer über die bestehende `~/.ssh/config`, ohne Token. Danach startet `agentbox docker:<host> claude` eine Box auf ihm. `agentbox prepare --provider daytona` baut vorab das Image und das erste Snapshot, bei E2B geschieht das über ein Dockerfile und `Template.build()`. Welche Anbieter eingerichtet werden, steuert der Assistent von `agentbox install`.

Sicherheitsdesign: Git-Zugangsdaten bleiben auf dem Host

Einen Punkt benennt das README ausdrücklich: Die Git-Zugangsdaten bleiben auf dem lokalen Rechner. Ein Push in das entfernte Repository wird über eine Berechtigungsanfrage freigegeben. Boxen dürfen so bearbeiten und testen, das Wegschreiben veranlassen sie nicht eigenmächtig; wer diese Freigabe in den Arbeitsablauf einplant, behält die Kontrolle über veröffentlichte Änderungen.

Die Cloud-Tokens liegen gesondert in `~/.agentbox/secrets.env`. Die Basisimages entstehen aus dem Dockerfile beziehungsweise dem Setup-Skript des Anbieters, bei Hetzner etwa aus einem Ubuntu-Skript. Der README-Text verspricht keine vollständige Isolierung der VM-Grenzen; wer sensible Daten verarbeitet, prüft die Container- und Netzfreigaben der eigenen Umgebung nach. Lokale Berechtigungen gehören zur Checkliste vor produktivem Betrieb.

Voraussetzungen und das Basisimage von rund einem Gigabyte

Die Systemvoraussetzungen nennt das README präzise: macOS auf arm64 oder Intel beziehungsweise Linux, dazu Docker über Docker Desktop oder OrbStack sowie Node ab Version 20.10. Der erste Aufruf von `agentbox create` oder `agentbox claude` erzeugt das Image `agentbox/box:dev`, das laut README rund 1 GB groß ist und einmalig gebaut wird.

Für Webanwendungen in den Boxen nutzt AgentBox `portless`, damit eine URL von innen und vom Host dieselbe Adresse zeigt. Wer auf einem Mac mit Intel-Chip arbeitet, prüft die Docker-Umgebung, denn das README nennt arm64 und Intel beide ausdrücklich. Eine fehlgeschlagene erste Image-Erstellung bricht früh ab und zeigt sich vor der eigentlichen Agenten-Sitzung. Nach erfolgreichem Bau starten weitere Boxen meist aus Checkpoints.

Update-Kanäle: nightly-Builds neben der stabilen Version

AgentBox pflegt laut README zwei Verteilungskanäle. Die stabile Version erreicht Nutzer über npm, daneben gibt es nightly-Builds. `npm -g install @madarco/agentbox@nightly` wechselt auf den Vorab-Kanal, wobei stabile Versionen laut Doku automatisch nachgeliefert werden; `agentbox self-update --channel stable` kehrt zurück. Wer neue Funktionen früh sehen will, findet dort prä-release Stände, wer Stabilität braucht, bleibt auf dem Standardpfad.

Der Release-Stand ist am Tag der Analyse schmal: Unter den jüngsten Tags finden sich `tray-latest` mit AgentBox 0.1.15 und der Stand 0.1.15-nightly. Die Versionsnummer ist niedrig, das Projekt steht entsprechend früh. `agentbox self-update` aktualisiert die Installation, setzt das Box-Image zurück, sodass es neu gebaut wird, und lädt das Relay neu. Ein Update zwischen produktiven Wochen gehört deshalb auf ein Test-Setup.

Einordnung unter MIT-Lizenz

Die Repository-Metadaten weisen die MIT-Lizenz aus. Für AgentBox bedeutet das freie Nutzung, Änderung und Verteilung mit Nennung des Copyright-Vermerks, ohne Copyleft-Pflichten. Wer AgentBox in ein eigenes Produkt einbindet oder die Skripte anpasst, liest den LICENSE-Text im Repository separat, denn eine Metadatenangabe ersetzt keine Lektüre der Bedingungen. Kommerzieller Einsatz ist unter MIT möglich, solange der Lizenzhinweis erhalten bleibt.

Was die Dokumentation nicht hergibt, bleibt offen. Eine feste Kompatibilitätsmatrix über alle Anbieter, Leistungszahlen oder Servicezusagen nennt das README nicht; die Anbieter-Tabelle ist eine Momentaufnahme. Wer die parallele Agenten-Verwaltung einführen will, spielt zuerst `agentbox claude` auf einem lokalen Rechner durch, liest dabei die `--help`-Ausgabe und `docs/development.md` und baut die Box mit `agentbox destroy` wieder ab. Genau für diesen Kreislauf sind die Befehle gedacht.

Redaktionelles Fazit

AgentBox passt für Teams, die mehrere KI-Agenten isoliert parallel laufen lassen wollen und Docker-Erfahrung mitbringen. Als Einzelrechner-Werkzeug bleibt der Einstieg überschaubar, für Cloud-Betrieb kommen Hetzner, Vercel, Daytona, E2B und DigitalOcean als dokumentierte Ziele hinzu. Vor produktivem Einsatz sollten Sie in einer isolierten Umgebung `agentbox install`, `agentbox claude` und das Basisimage `agentbox/box:dev` durchspielen und die Box anschließend mit `agentbox destroy` wieder abbauen.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes