OpenClaw Remote-Nodes: ein Gateway, mehrere Geräte

OpenClaw wird interessanter, sobald es nicht mehr nur auf einem einzelnen Rechner lebt. Ein Agent, der Nachrichten empfängt, Browser steuert, lokale Geräte anspricht und vielleicht noch Kameras oder Benachrichtigungen nutzt, stößt auf dem Laptop schnell an eine banale Grenze: Der Laptop schläft, liegt im Rucksack oder ist gerade nicht das Gerät mit der passenden Peripherie.

Die Remote- und Node-Dokumentation von OpenClaw beschreibt dafür eine klare Architektur. Es gibt einen zentralen Gateway, der Sessions, Auth-Profile, Channels und Zustand besitzt. Andere Geräte hängen sich als Nodes daran und stellen lokale Fähigkeiten bereit. Das klingt nach Infrastruktur, ist aber vor allem eine Produktentscheidung: OpenClaw behandelt zusätzliche Geräte nicht als zweite Agenten-Zentrale, sondern als angebundene Werkzeuge.

Gateway bleibt Chef, Nodes bleiben Peripherie

Ein Node ist laut OpenClaw-Dokumentation ein Companion-Gerät, das sich über den Gateway-WebSocket verbindet und dabei die Rolle node nutzt. Solche Nodes können eine Befehlsoberfläche bereitstellen, etwa für Canvas-, Kamera-, Geräte-, Benachrichtigungs- oder Systemfunktionen. Die Aufrufe laufen anschließend über node.invoke.

Wichtig ist die Grenze: Nodes sind keine Gateways. Telegram-, WhatsApp- oder andere Channel-Nachrichten landen beim Gateway, nicht direkt auf den Nodes. Der Gateway ist also der Ort, an dem der Agent lebt und Zustand hält. Ein Node ist das Gerät, das vor Ort etwas kann: ein Bildschirm, eine Kamera, ein lokales Systemkommando oder eine Benachrichtigung.

Für Setups mit mehreren Macs, einem Desktop und mobilen Geräten ist diese Trennung sauberer als ein wildes „überall läuft ein bisschen Agent“. Ein Mac mini kann zum Beispiel dauerhaft den Gateway betreiben, während ein MacBook nur dann als Node auftaucht, wenn es online ist. Das reduziert die Frage „wo ist mein Agent gerade?“ auf eine Antwort: beim Gateway.

Remote-Zugriff ohne Gateway-Wanderung

Die Remote-Dokumentation beschreibt das Grundmodell als „remote over SSH“: Ein einzelner Gateway läuft auf einem dedizierten Host, Clients verbinden sich dorthin. Der Gateway-WebSocket bindet dabei standardmäßig an Loopback auf Port 18789. Für entfernten Zugriff wird dieser Loopback-Port per SSH weitergeleitet oder über ein Tailnet erreichbar gemacht.

Daraus ergeben sich drei typische Varianten. In der stabilsten Variante läuft der Gateway auf einem Always-on-Host, etwa einem Server oder Desktop im Tailnet. Laptop und andere Geräte verbinden sich nur noch remote. In einer zweiten Variante läuft der Gateway auf einem Heim-Desktop, während das MacBook über den Remote-over-SSH-Modus der macOS-App darauf zugreift. In einer dritten Variante bleibt der Gateway lokal auf dem Laptop, wird aber für andere Geräte über SSH-Tunnel oder Tailscale Serve erreichbar gemacht.

Die Konsequenz ist unspektakulär, aber wichtig: Remote heißt bei OpenClaw nicht, dass jedes Gerät seinen eigenen Agenten startet. Remote heißt, dass der Agent an einem Ort bleibt und andere Geräte Zugriff bekommen. Das ist für Automationen deutlich robuster, weil Cronjobs, Channel-Zustand und laufende Sessions nicht an das Gerät gebunden sind, auf dem du gerade tippst.

Diese Trennung ergänzt die Monitoring-Perspektive aus dem Beitrag zum OpenClaw-Dashboard für Überwachung: Sobald Gateway, Nodes und Sessions verteilt laufen, wird Sichtbarkeit über Zustand, Kosten und Erreichbarkeit noch wichtiger. Auch die Mission-Control-Perspektive auf Operations und Governance passt dazu, weil verteilte Agenten-Setups ohne klare Kontrollflächen schnell unübersichtlich werden.

Tailscale als sichere Abkürzung

Tailscale spielt in der Dokumentation eine besondere Rolle, weil OpenClaw Serve und Funnel automatisiert konfigurieren kann. Im Serve-Modus bleibt der Gateway lokal an 127.0.0.1 gebunden, während Tailscale HTTPS, Routing und Identitäts-Header bereitstellt. Funnel ist die öffentliche HTTPS-Variante und verlangt laut Dokumentation ein gemeinsames Passwort. off bedeutet nur, dass OpenClaw Serve oder Funnel nicht verwaltet; es sagt nichts darüber aus, ob der lokale Tailscale-Daemon läuft.

Für private Multi-Geräte-Setups ist Serve die spannendere Variante. Wenn tailscale.mode = "serve" gesetzt ist und gateway.auth.allowTailscale aktiviert wurde, kann die Control-UI/WebSocket-Authentifizierung Tailscale-Identitäts-Header nutzen. OpenClaw prüft dabei die Identität über den lokalen Tailscale-Daemon und akzeptiert den Pfad nur, wenn die passenden weitergeleiteten Header von Loopback kommen.

Das ist keine pauschale Hintertür. Die Dokumentation grenzt ausdrücklich ab, dass API-Endpunkte wie /v1/*, /tools/invoke und /api/channels/* nicht über diese Tailscale-Identity-Header authentifiziert werden. Sie folgen weiter der normalen Gateway-Authentifizierung. Für Agenten-Setups ist genau diese Trennung vernünftig: Komfort für die Control UI, aber keine magische Freigabe für alle HTTP-Flächen.

Pairing ist der Sicherheitsanker

Nodes nutzen laut Dokumentation Device Pairing. Ein Node stellt beim Verbinden eine Geräteidentität vor, der Gateway erzeugt daraus eine Pairing-Anfrage für die Rolle node, und diese Anfrage muss über CLI oder UI genehmigt werden. Die Dokumentation nennt dafür unter anderem openclaw devices list, openclaw devices approve <requestId>, openclaw devices reject <requestId>, openclaw nodes status und openclaw nodes describe --node <idOrNameOrIp>.

Auch hier steckt die relevante Designentscheidung im Detail. Der Pairing-Eintrag ist der dauerhafte Vertrag über die erlaubte Rolle. Token-Rotation darf innerhalb dieses Vertrags passieren, aber sie kann einen bereits gepairten Node nicht heimlich in eine andere Rolle hochstufen, die nie genehmigt wurde. Wenn ein Node mit geänderten Auth-Details erneut versucht, sich zu verbinden, wird eine alte offene Anfrage ersetzt und eine neue requestId erzeugt.

Für die Praxis heißt das: Multi-Geräte-Komfort entsteht nicht durch blindes Vertrauen im Tailnet. Geräte müssen als Nodes genehmigt werden, und die Rolle bleibt Teil dieses Vertrauensmodells. Das ist besonders relevant, wenn ein Node Zugriff auf lokale Kameras, Canvas oder Systemfunktionen bereitstellt.

Der praktische Zuschnitt

Für ein OpenClaw-Setup mit mehreren Geräten wirkt die sinnvollste Struktur ziemlich klar: Ein Always-on-Gateway hält die eigentliche Agenten-Instanz. Laptops, Desktops und mobile Geräte melden sich als Operatoren oder Nodes an, je nachdem, ob sie steuern oder lokale Fähigkeiten bereitstellen sollen. Tailscale Serve kann den Zugang zur Control UI angenehmer machen, SSH bleibt der universelle Fallback.

Die Grenze liegt dort, wo die Dokumentation bewusst nüchtern bleibt. Nodes lösen nicht automatisch Fragen wie Gerätemanagement, Namenskonventionen oder Ausfallverhalten. Ein Node, der offline ist, ist offline. Ein Gateway, der falsch exponiert wird, bleibt ein Risiko. Und wer API-Endpunkte nutzen will, muss weiterhin die normale Gateway-Authentifizierung sauber setzen.

Zusammenfassung

OpenClaw baut nicht einfach „mehr Remote-Zugriff“ ein, sondern zieht eine brauchbare Linie zwischen Agenten-Zentrale und Geräte-Peripherie. Genau diese Linie braucht ein Agentensystem, wenn es vom Demo-Laptop in ein echtes, verteiltes Arbeitssetup wachsen soll.

Der praktische Kern ist einfach: Der Gateway bleibt der stabile Ort für Sessions, Channels, Cronjobs und Zustand. Nodes liefern lokale Fähigkeiten, ohne selbst zur zweiten Agenten-Zentrale zu werden. Tailscale und SSH erleichtern den Zugriff, ersetzen aber nicht Pairing, Rollenmodell und saubere Gateway-Authentifizierung. Wer OpenClaw über mehrere Geräte betreibt, sollte deshalb zuerst den Gateway-Standort festlegen, dann Nodes gezielt pairen und erst danach Remote-Komfort wie Serve oder SSH-Tunnel ergänzen.