OpenClaw kann auf macOS zwei Gateway-Dienste gegeneinander starten lassen

Ein offenes OpenClaw-Issue vom 27. Juni beschreibt einen Bug, den Betreiber von Headless-Macs nicht als bloße Installationsmacke abtun sollten. Wenn das Gateway bereits als systemweiter LaunchDaemon läuft, kann der reguläre Installationspfad trotzdem noch einen zweiten, GUI-gebundenen Dienst anlegen. Das Ergebnis ist kein kosmetischer Doppeleintrag, sondern ein Neustart-Sturm, der Clients trennt und den Host instabil macht.

Auf einem produktiven Mac-Host bleibt damit vor allem eine Entscheidung hängen: Ein erneuter Installationslauf ist in dieser Konstellation derzeit keine harmlose Reparaturoption. Er kann den Fehler erst auslösen.

Wo der Konflikt entsteht

Betroffen ist laut Ticket OpenClaw 2026.6.10 (aa69b12) auf macOS 26.5.1 mit arm64. Das Gateway läuft dabei bereits systemweit unter /Library/LaunchDaemons/ai.openclaw.gateway.plist, mit KeepAlive=true und Port 18789. Genau in dieser Lage schreibt der Installationspfad zusätzlich noch ~/Library/LaunchAgents/ai.openclaw.gateway.plist.

Damit existieren zwei launchd-Manager mit demselben Label und demselben Port. Der vorhandene Systemdienst wird in diesem Ablauf offenbar nicht als Konflikt erkannt. Für den Betrieb ist das der eigentliche Defekt: Nicht Routing, Modellwahl oder Transport wackeln zuerst, sondern das Service-Management selbst.

Warum das Fehlerbild leicht falsch gelesen wird

Die Symptome sehen zunächst wie gewöhnliches Netzwerkflattern aus. Jede neu gestartete Instanz protokolliert service-mode: cleared 1 stale gateway pid before bind on port 18789, bevor sie den jeweils anderen Prozess abschießt. Gleichzeitig werden Webchat-Clients mit code=1012 reason=service restart getrennt. Im Systemstatus steigt außerdem der runs=-Zähler von launchctl print system/ai.openclaw.gateway, weil beide KeepAlive-Manager den Dienst immer wieder hochziehen.

Genau darin steckt die operative Falle. Wer nur Verbindungsabbrüche, wechselnde PIDs oder einen hektisch neu startenden Prozess sieht, sucht schnell bei Netzwerk, Portbindung oder Runtime. Die Ursache liegt hier aber eine Schicht tiefer: Zwei Startmechanismen behandeln sich gegenseitig als verwaisten Prozess und räumen sich beim Binden auf denselben Port laufend aus dem Weg.

Der heiklere Teil ist die falsche Diagnose

Ein Live-Repro-Kommentar vom selben Tag verschärft den Fall. Beschrieben wird ein Headless-macOS-Host ohne GUI-Login, per SSH verwaltet und bereits sauber als System-LaunchDaemon eingerichtet. Die laufende Instanz hört auf Port 18789, ihr Prozess hängt mit PPID 1 direkt unter launchd und läuft damit genau dort, wo er auf so einem Host laufen soll.

Trotzdem meldet die Statusabfrage in diesem Szenario LaunchAgent (not loaded) und empfiehlt einen neuen Installationslauf. Das macht den Bug gefährlicher als einen fehlenden Guard im Installer. Die Diagnose lenkt den Betreiber aktiv auf den falschen Reparaturpfad. Wer dieser Meldung folgt, kann den zweiten Manager erst selbst erzeugen.

Damit verschiebt sich auch die Bewertung des Tickets: Es geht nicht nur um eine schwache Konfliktprüfung beim Schreiben eines LaunchAgent. Das Problem sitzt schon in der Erkennung einer legitimen Headless-Konfiguration, die offenbar nur aus der GUI-Perspektive bewertet wird und deshalb als defekt erscheint, obwohl der Systemdienst bereits korrekt läuft.

Die aktuelle Recovery hilft, ist aber keine Betriebsstrategie

Der unmittelbare Ausweg ist dokumentiert. Der Host stabilisiert sich, wenn der doppelte GUI-Dienst entfernt wird: zuerst launchctl bootout gui/<uid>/ai.openclaw.gateway, danach das Löschen von ~/Library/LaunchAgents/ai.openclaw.gateway.plist. Die systemweite Instanz bleibt bestehen und der Flatterzustand endet.

Für einen produktiven Host ist das trotzdem nur Recovery, keine Lösung. Wer ein Gateway auf einem Mac per SSH betreibt, will keinen Zustand, in dem eine irreführende Statusmeldung erst einen Crash-Loop auslöst und der stabile Zustand danach manuell wiederhergestellt werden muss. Naheliegend wäre deshalb ein enger Konflikt-Check vor dem Schreiben oder Bootstrappen eines neuen LaunchAgent sowie eine Statusdiagnose, die aktive Systemdienste mit demselben Label ausdrücklich mitprüft.

Warum das für OpenClaw mehr als ein Mac-Sonderfall ist

Die Einordnung im Ticket fällt deutlich aus. Der Fall ist unter anderem mit impact:crash-loop, impact:message-loss, maturity:stable und P2 markiert. Zusammen mit dem Live-Repro auf einem echten Headless-Host ist das kein rein theoretischer Randfall. Es ist ein Stabilitätstest dafür, ob OpenClaw Desktop- und Server-Betrieb auf macOS sauber auseinanderhalten kann.

Bis ein Fix vorliegt, ist die Konsequenz für Betreiber ziemlich klar: Wenn auf einem macOS-Host bereits ein System-LaunchDaemon für das Gateway läuft, sollte ein weiterer Installationslauf nicht als Routine-Reparatur behandelt werden. Meldet die Statusanzeige in so einer Lage, der Dienst sei nicht installiert, obwohl Port 18789 bereits lauscht und der Prozess unter launchd läuft, ist das im Moment eher ein Warnsignal als eine Handlungsaufforderung.

Die größere Lehre ist nüchtern: Runtime-Komponenten müssen nicht nur startbar sein, sondern ihren tatsächlichen Lebenszyklus korrekt erkennen. Genau daran entscheidet sich hier, ob OpenClaw auf einem Headless-Mac wie ein verlässliches Gateway wirkt oder wie ein Installationspfad mit eingebautem Selbstkonflikt. Für Teams, die solche Hosts aktiv für laufende Verbindungen nutzen, ist das kein Detailfehler, sondern ein klarer Betriebsrisiko-Hinweis bis zur Korrektur im Installer und in der Statusdiagnose.