OpenClaw-Gateway: Wenn „ready“ noch nicht stabil bedeutet

Der Gateway meldet „ready“, die Control UI verbindet sich, eine Modellanfrage endet mit HTTP 200. Kurz darauf beendet sich der Prozess. Ready war zu früh.

Ein am 7. September 2026 veröffentlichter und inzwischen als behoben markierter OpenClaw-Fehlerbericht dokumentiert diesen Ablauf unter Windows 11. Nach Angaben des Melders brach der Prozess mit PreparedModelRuntimeOwnerNotPublishedError ab. Laut Bericht trat der Absturz wiederholt in der stabilen Version 2026.9.2 auf und ebenso nach einem frischen Build aus dem damaligen Stand des Hauptzweigs. Ein allgemeines Windows-Problem belegt das nicht. Ein brauchbares Fehlerbild für die Betriebsdiagnose schon.

Der Status täuschte Stabilität vor

Laut dem Windows-Bericht erreichte das Gateway seinen normalen Ready-Status und startete den Heartbeat. In einzelnen Läufen blieb genug Zeit, dass die Control UI WebSocket-Anfragen verarbeitete und MiniMax-Anfragen erfolgreich beantwortet wurden. Das Prozessende kam danach.

Diese Reihenfolge verschiebt die Diagnose. Ein erreichbarer Provider und eine gelungene Anfrage schließen einen späteren internen Laufzeitfehler nicht aus, wenn zwischen Vorbereitung, Veröffentlichung und Austausch einer Modell-Runtime ein inkonsistenter Zustand entsteht. Das Signal ist die Kombination: sauberer Start, dann Abbruch.

Ein Wechsel mitten im Turn

Ein zweiter OpenClaw-Issue vom 6. September beschreibt dieselbe Fehlerklasse in anderer Lage. Nach Angaben dieses Berichts traf ein Wechsel der Plugin-Generation einen laufenden System-Agent-Turn, ausgelöst etwa durch einen Hot Reload der MCP-Konfiguration. Turn und Planner-Fallback scheiterten nahezu gleichzeitig.

Zugeordnet wird der Fehler dort einem Retry-Pfad der vorbereiteten Modell-Runtime: PreparedModelRuntimeOwnerNotPublishedError verließ die Schleife, während benachbarte Fälle eines überholten Zustands weiterliefen. In rund drei Tagen auf einer stark genutzten Instanz wurde das Verhalten demnach zweimal beobachtet, einmal sichtbar für den Nutzer. Selten heißt hier: schwer zu greifen.

Die Fehlermeldung führte in die falsche Richtung

Heikel wurde es laut diesem Bericht danach. Die Meldung erklärte die Inference-Route für unerreichbar und empfahl openclaw onboard, obwohl erfolgreiche Turns den Ausfall im Abstand weniger Sekunden einrahmten. Der Autor warnte, dass dieser Schritt eine funktionierende Route umschreiben könne, während die Ursache im vorübergehenden Generationswechsel lag.

Auch die üblichen Reparaturversuche halfen im Windows-Bericht nicht: Neustarts, Doctor, Registry-Reparatur, das Bereinigen entbehrlicher Hilfsdateien, Neuinstallation, Source-Build. Beide Meldungen stützen dieselbe Einordnung. Blindes Neuaufsetzen der Provider-Konfiguration passt schlecht zu einem Fehler, der zeitlich mit dem Austausch interner Runtime-Eigentümer zusammenfällt.

Was in der Diagnose erhalten bleiben muss

Der als behoben markierte Bericht nennt in der abgerufenen Fassung weder eine belastbare Fix-Version noch einen allgemein gültigen Workaround. Als Betriebslektion bleibt ein Prüfpfad: Ready-Meldung, letzte erfolgreiche Requests, Zeitpunkt eines Konfigurations- oder Plugin-Reloads und der nachfolgende Runtime-Fehler gehören in dieselbe Zeitleiste. Wer nur den letzten Fehlertext liest, macht eine gesunde Inference-Route zum Reparaturziel.

Der Fall reiht sich in die OpenClaw-Betriebsthemen ein, bei denen Statusmeldung und tatsächlicher Zustand auseinanderfallen. Ready plus HTTP 200 ist bei diesem Muster kein Stabilitätsnachweis. Daraus folgt eine Mindestregel vor jeder Änderung an Onboarding oder Provider-Konfiguration: prüfen, ob unmittelbar vor dem Ausfall eine neue Plugin-Generation oder Runtime veröffentlicht wurde und ob parallele Anfragen zur selben Zeit noch durchliefen. So bleibt die Diagnose am beobachteten Zustandswechsel statt an der falschen Stelle.