OpenClaw mit Crabbox: Tools remote, Gateway lokal

Modellgenerierte Befehle müssen nicht auf demselben Rechner laufen wie das persönliche OpenClaw-Gateway. Die aktuelle OpenClaw-Dokumentation beschreibt mit Crabbox ein Backend, das isolierte Tool-Aufrufe auf eine gemietete Maschine verlagert, während der steuernde Teil der Laufzeit auf dem eigenen Host bleibt.

Die Grenze ist klar: Crabbox übernimmt Providerzugriff, Ausführung und Bereinigung der gemieteten Maschine; OpenClaw verwaltet den entfernten Workspace und die Dateisystembrücke. Das eignet sich für Betreiber, die generierten Code vom Gateway-Host fernhalten wollen und dort Docker nicht einsetzen können oder möchten.

Die Distanz hat einen Preis.

Die Sitzung bleibt zu Hause

Gateway, Agentenschleife, Kanäle und Modellzugangsdaten verbleiben laut OpenClaw-Dokumentation auf dem Host. Auf der gemieteten Maschine laufen die isolierten Tools sowie Datei- und Medienzugriffe innerhalb des vorgesehenen Sandbox-Scopes. Wer die komplette Sitzung auslagern möchte, braucht einen anderen Betriebsweg: Crabbox trennt gezielt die Ausführung vom lokalen Steuerungsprozess.

Darin liegt die Stärke des Ansatzes. Der sensible Kontrollpfad wandert nicht pauschal zu einem Cloud-Anbieter, zugleich muss der Host modellgenerierte Kommandos nicht selbst ausführen. OpenClaw exportiert oder speichert dabei keine SSH-Zugangsdaten der Lease zwischen.

Eine feste Identität pro Sandbox-Scope

Vor der Provisionierung reserviert die Sandbox-Registry nach Angaben der Dokumentation eine feste Crabbox-Lease-ID je Scope. Gleichzeitige erste Zugriffe teilen diese Reservierung; schlägt die Provisionierung fehl oder startet das Gateway neu, verwendet OpenClaw dieselbe ID erneut, statt eine weitere Maschine anzulegen.

Die Remote-Maschine ist damit kein beliebig austauschbares Nebenprodukt einzelner Tool-Aufrufe. Die feste Zuordnung schafft einen nachvollziehbaren Lebenszyklus und verhindert, dass parallele Starts unkontrolliert neue Leases erzeugen. Im Gegenzug wird die Bereinigung zu einem Teil des Betriebszustands, den Plattformteams beobachten müssen.

Cleanup kann den nächsten Start blockieren

Scheitert das Entfernen einer Lease, bleibt der Vorgang laut OpenClaw-Dokumentation für einen weiteren Versuch vermerkt. Eine neue Provisionierung wartet, bis die Bereinigung abgeschlossen ist.

Der Fehlerpfad zählt.

Ein hängender Neustart ist deshalb nicht automatisch ein gewöhnliches Verbindungsproblem. Bevor ein Plattformteam weitere Starts anstößt, sollte es den Zustand der vorherigen Lease prüfen, denn eine offene Bereinigung kann den gesamten Scope anhalten. Das verhindert zwar, dass OpenClaw mit möglicherweise verwaisten Maschinen still weiterarbeitet, macht das Cleanup aber zu einer echten Betriebsgrenze.

Isolation kostet Zeit

Jeder Tool-Aufruf überquert bei diesem Backend das Netzwerk. Die OpenClaw-Dokumentation weist deshalb auf eine höhere Latenz als bei Docker hin. Bei wenigen langen Aufgaben kann dieser Preis vertretbar sein. Viele kurze Datei- oder Shell-Operationen machen ihn dagegen unmittelbar im Ablauf sichtbar.

Die anfängliche Unterstützung gilt für direkte Daytona-Leases. Vor der Provider-Zuweisung prüft OpenClaw dieselben Fähigkeiten wie der dokumentierte Offline-Check: crabbox exec --check --provider daytona muss execution: true und currentRepoStop: true melden. Eine feste Lease-ID allein genügt nicht.

Crabbox passt damit zu einem klaren Risikoprofil: Das Gateway soll lokal und unter eigener Kontrolle bleiben, darf modellgenerierte Tool-Ausführung aber nicht auf dem Host tragen. Die Mindestregel für den Einsatz lautet, höhere Latenz und blockierendes Cleanup von Anfang an als normale Betriebszustände einzuplanen. Wer nur den Isolationsgewinn bewertet, übersieht die Hälfte des Entwurfs.