OpenClaw-Bug-Watch: Drei offene Baustellen für Gateway, MCP-Timeouts und Agent-Workspaces

OpenClaw hatte Ende Mai keinen großen Release-Aufreger, aber drei offene Bug-Reports, die für Betreiber relevanter sein können als ein Changelog-Feuerwerk. Auf GitHub waren am 31. Mai 2026 ein Gateway-Problem in Docker, ein 60-Sekunden-Limit bei Bundle-MCP-Tools und eine Workspace-Regression beim Anlegen neuer Agenten weiter aktiv; alle drei Tickets wurden laut GitHub am 5. Mai 2026 erstellt.

Das gemeinsame Muster: Die Reports betreffen keine kosmetischen UI-Kanten, sondern Betriebsgrenzen. Healthchecks melden Erfolg, während Requests scheitern; ein MCP-Tool läuft länger, als die Runtime erlaubt; und ein Default-Pfad macht Agent-Routing mehrdeutig.

Wenn der Gateway gesund wirkt, aber keine neuen Jobs annimmt

Laut Issue #78136 kann ein In-Process-Neustart des Gateways in Docker dazu führen, dass die interne Command-Queue im Zustand gatewayDraining hängen bleibt. Gemeldet wurde das für OpenClaw 2026.5.4 in einer Docker-Compose-Umgebung auf Linux arm64. Der Report beschreibt den zentralen Widerspruch: /healthz und /readyz liefern weiter Erfolgsmeldungen, während Modellaufrufe mit Gateway is draining for restart; new tasks are not accepted scheitern.

Für Monitoring ist das ein harter Bruch. Nach Angaben des Tickets wurden zwei SIGUSR1-Restart-Signale kurz hintereinander verarbeitet. Danach loggte das Gateway zwar ready, nahm aber mindestens rund 20 Minuten lang keine neue Modellarbeit mehr an. Ein Container kann also für Docker gesund aussehen, obwohl der eigentliche Arbeitskanal blockiert bleibt.

Der gemeldete Workaround ist grob, aber nachvollziehbar: Statt auf den internen Restart zu vertrauen, lässt sich der openclaw-gateway-Container neu erstellen, damit ein frischer Node-Prozess startet. Das Ticket fordert entsprechend nicht nur einen Fix für das interne Flag, sondern auch eine strengere Readiness-Logik. Wenn das Gateway neue Model- oder Tool-Aufträge ablehnt, sollte /readyz nicht gleichzeitig Entwarnung geben.

Das MCP-Problem sitzt im laufenden Tool-Call

Issue #78092 beschreibt einen anderen Fehlerpfad. Laut Ticket ignoriert callTool im Bundle-MCP-Runtime-Pfad per-Request-Optionen und fällt dadurch auf den SDK-Standard DEFAULT_REQUEST_TIMEOUT_MSEC = 60000 zurück. Tool-Aufrufe, die legitim länger als 60 Sekunden laufen, enden dann mit -32001: Request timed out, obwohl nicht der Verbindungsaufbau, sondern die spätere Ausführung zu knapp begrenzt ist.

Der Report grenzt das ausdrücklich von einem früheren Verbindungs- und Handshake-Problem ab. Betroffen seien openclaw 2026.5.4 und @modelcontextprotocol/sdk 1.29.0. Der bestehende Parameter connectionTimeoutMs reiche dafür nicht, weil er laut Ticket nur den Connect-Pfad abdeckt, nicht den späteren callTool-Request.

Für Teams mit lang laufenden MCP-Jobs ist das mehr als ein Komfortproblem. Ein Tool kann real Fortschritt machen oder Status-Events liefern und trotzdem nach einer Minute beendet werden. Das Ticket schlägt deshalb ein zusätzliches Konfigurationsfeld requestTimeoutMs sowie resetTimeoutOnProgress: true vor. Damit würden lange Jobs nicht allein wegen einer starren Ein-Minuten-Grenze abbrechen, solange sie nachvollziehbar Fortschritt melden.

Ein Default-Pfad verwischt Workspace-Grenzen

Issue #78093 wirkt zunächst kleiner, betrifft aber den Alltag mit mehreren Agenten. Seit PR #59789 schlägt openclaw agents add laut Report für neue Agenten standardmäßig einen Workspace innerhalb des Haupt-Workspaces vor, etwa ~/.openclaw/workspace/newbot/ statt eines Geschwisterpfads wie ~/.openclaw/workspace-newbot/.

Nach Angaben des Reports führt diese Verschachtelung zu Routing-Ambiguität in der TUI. Die Workspace-Auflösung arbeitet über Pfad-Containment. Ein Pfad unterhalb von workspace/newbot/ kann deshalb nicht nur zum neuen Agenten passen, sondern auch zum Default-Agenten. Im gemeldeten Fall gewinnt zwar der längere Pfad in der Sortierung, die Zuständigkeitsgrenze wird dadurch aber implizit und fragil.

Laut Issue #78093 betrifft die Regression OpenClaw 2026.5.3-1 unter macOS 15 auf Apple Silicon bei Installation per globalem npm-Paket. Als Workaround bleibt, den Workspace beim Anlegen explizit per --workspace zu setzen. Für Operatoren ist vor allem die Konsequenz wichtig: Wenn Agenten dieselbe Pfadwurzel teilen, wird Debugging unnötig schwerer. Dann ist nicht sofort klar, welcher Agent eine Datei, einen TUI-Kontext oder eine Routing-Entscheidung tatsächlich beansprucht.

Drei Tickets, ein AgentOps-Signal

Die drei Reports haben unterschiedliche Ursachen, markieren aber denselben Schwachpunkt: OpenClaw ist im Betrieb nur so robust wie seine Zustandsgrenzen. Health, Timeout-Logik und Workspace-Zuordnung müssen eindeutig sein, sonst wird die Runtime schwer berechenbar.

Für Betreiber heißt das kurzfristig: Docker-Setups sollten Gateway-Restarts nicht nur über grüne Healthchecks bewerten; lange MCP-Tool-Calls brauchen Aufmerksamkeit, solange der Request-Pfad an der 60-Sekunden-Grenze hängen kann; und wer mehrere Agenten in einer Installation anlegt, sollte Workspace-Pfade bewusst setzen, statt sich auf den Default zu verlassen.

Keines der Tickets deutet für sich allein auf eine breite Plattformkrise hin. Zusammen zeigen sie aber, wo OpenClaw im produktiven Betrieb präziser werden muss: bei ehrlicher Zustandsanzeige, bei langen Tool-Laufzeiten und bei klaren Zuständigkeitsgrenzen zwischen Agenten.