OpenClaw dokumentiert einen optionalen Worker-Modus ohne OCE oder Kubernetes

Wer die Arbeit eines KI-Agenten auf eine andere Maschine auslagern will, muss klären, wer danach das Sagen hat. Ohne diese Klärung drohen zwei Verwechslungen: Man legt einen Worker an und hält ihn schon für betriebsbereit, oder man bindet Dateien und hält das für eine Synchronisation. Die offizielle OpenClaw-Dokumentation beschreibt für diesen Fall einen optionalen Worker-Modus auf Basis von OpenShell. OpenShell stellt die Sandbox und vermittelt die Zugangsdaten für Modellanbieter. Der Modus setzt ausdrücklich weder OCE noch Kubernetes voraus.

OpenClaw organisiert Agenten-Sessions über ein zentrales Gateway. Im Worker-Modus laufen der Agenten-Loop und die Coding-Werkzeuge innerhalb von OpenShell. Das Gateway behält die Session-Autorität, die Transkripte und das Placement, also die Entscheidung, wo Arbeit läuft. Der Worker führt die Arbeit aus, die Hoheit über die Sessions bleibt beim Gateway. Ebenfalls lesenswert: OpenClaw-Teamserver: Ein Gateway ist eine gemeinsame Vertrauensgrenze.

Registrieren heißt noch nicht starten

Die wichtigste Grenze steckt in einem unscheinbaren Detail. Die OpenClaw-Dokumentation nennt die neue Kommandozeile additiv: Das Registrieren der neuen Befehle erstellt keine Sandbox, startet keinen Node und wählt kein Worker-Profil aus. Auch Worker-Einstellungen allein setzen nichts in Gang.

Der Modus ist opt-in, das bestehende Sandbox-Verhalten bleibt unverändert. Wer heute mit Sandboxes arbeitet, muss also nicht befürchten, dass eine neue Konfigurationszeile still den Ausführungsort verschiebt. Eine Datenbankmigration oder ein neues Wire-Protokoll für Worker bringt das Plugin ebenfalls nicht mit.

Für Betriebsteams heißt das: Verfügbare Befehle sind noch keine Inbetriebnahme. Jeder weitere Zustand braucht einen eigenen Schritt.

Bei den Plattformen ist die Linie hart. Native Worker-lokale Inferenz unter Windows wird nicht unterstützt. Verlangt wird ein Linux-Sandbox-Workload auf einem Host, dessen Kernel die vollständige OpenShell-Durchsetzung einschließlich Landlock beherrscht. Docker oder Podman allein liefern diese Kernel-Fähigkeiten nicht, und die Wahl einer Container-Engine garantiert keine Plattformkompatibilität. Eine funktionierende Container-Umgebung auf einem Windows-Rechner löst das Problem also nicht.

Drei Befehle, drei Zustandswechsel

OpenClaw verteilt die Inbetriebnahme auf drei getrennte Befehle. Ein Beispiel mit dem Worker-Namen native-worker:

1. Sandbox anlegen. worker create erstellt eine eigene Sandbox, die dauerhaft erhalten bleibt. Ein Node läuft danach noch nicht.

openclaw openshell worker create native-worker

2. Node starten. Erst worker run startet den Node, und zwar im Vordergrund in einem eigenen Terminal. Beim ersten Lauf braucht er ein Join-Ziel zur einmaligen Verwendung. Es stammt von der Geräteseite des Gateways oder aus openclaw devices join-code und wird in einer privaten Datei abgelegt. Scheitert das Anbinden der Provider, startet kein Node. Wichtig für den Betrieb: Wird der Befehl beendet, stoppt die gesamte Sandbox mit.

openclaw openshell worker run native-worker --target-file /private/path/join-target

3. Profil schreiben. worker configure leitet in einem zweiten Terminal die Node-Identität aus der Sandbox ab und zeigt das Gateway-Profil zunächst als Vorschau. Ohne --apply wird keine Konfiguration geschrieben.

openclaw openshell worker configure native-worker --worker-profile openshell-native --required --apply

Die Option --required wirkt auf jede Session dieses Gateways: Ist der Worker nicht verfügbar, werden Turns blockiert. Für eine optionale Zuweisung, die der Administrator wählt, lässt man sie weg. Scheitert die Inferenz auf dem Worker, weicht OpenClaw für diesen Turn zudem nie auf Inferenz im Gateway aus.

Daraus folgt eine vorsichtige Reihenfolge: zuerst die Vorschau ohne --apply prüfen und --required erst ergänzen, wenn der Node verlässlich läuft.

Remote-Bindung ist kein Mount

Die zweite leicht missverständliche Stelle betrifft die Agentendateien. Sie lassen sich optional remote-kanonisch an einen Node binden. Die maßgebliche Fassung liegt dann auf der entfernten Seite. OpenClaw stellt klar, dass diese Bindung weder ein Mount noch eine Synchronisationsregel ist.

Im Alltag hat das zwei Folgen. Gewöhnliche Operationen wie read, write, edit und Shell-Befehle arbeiten weiterhin im Aufgaben-Workspace der Session. Für die kanonischen Dokumente erhält der Agent einen Hinweis auf die Werkzeuge file_fetch und file_write. Außerdem muss der gebundene Node erreichbar bleiben. Ist er getrennt oder gestoppt, schlägt der Zugriff fehl, und OpenClaw greift nicht auf lokale Dateien zurück. Einen Zwei-Wege-Abgleich zwischen Hosts gibt es ebenfalls nicht.

Ein konkretes Risiko ergibt sich aus Schritt 2: Wer das Terminal mit worker run schließt, stoppt die Sandbox und damit auch den Zugriff auf die gebundenen Agentendateien. Zum Weiterlesen: OpenClaw mit Crabbox: Tools remote, Gateway lokal.

Ausführung, Autorität und Speicherort bleiben getrennt

Wo Arbeit läuft, wer Sessions verwaltet und wo die maßgeblichen Dateien liegen, sind in diesem Modus drei getrennte Entscheidungen. Keine folgt automatisch aus einer Konfigurationszeile. Der Node läuft erst nach worker run, und das Profil steht erst nach --apply. Die Dateibindung legt nur den kanonischen Speicherort fest. Ein gemeinsames Dateisystem entsteht dadurch nicht.

Ich halte diese Kleinteiligkeit für die Stärke des Modus, weil sich jeder Zustand einzeln prüfen und zuordnen lässt.