OpenClaw 2026.4.24: Linux-VPS-Upgrade mit Gateway-Crashs, Bonjour-Loop und Recovery-Pfaden

Laut den Release Notes ist das kein kleines Patch-Release. Diese Version bringt neue Meet- und Voice-Pfade, greift also direkt in die Laufzeit ein. Genau deshalb ist sie für Linux-VPS nicht nur interessant, sondern auch risikoreich: In den Issue-Kommentaren tauchen nach dem Upgrade Gateway-Crashs, Bonjour-/mDNS-Schleifen und ausgefallene Messenger-Kanäle auf.

Die Release Notes belegen vor allem den Funktionssprung: Google Meet ist als gebündelter Participant-Pfad integriert, inklusive Authentifizierung, Transport über Chrome oder Twilio, Export-Funktionen und Recovery für offene Meet-Tabs. Dazu kommen neue Realtime-Voice-Wege für Talk, Voice Call und Google Meet. Das ist für Teams spannend, erhöht aber die Zahl der Stellen, an denen ein Linux-Host schiefgehen kann.

Parallel dazu meldete GitHub-Issue #71986 vom 26. April 2026 Stabilitätsprobleme nach dem Upgrade. Mehrere Kommentatoren berichten dort von Downgrades zurück auf die vorherige stabile Version, wiederholten Doctor-Läufen ohne Erfolg, Bonjour/CIAO-Crashloops und lokal gesunden, aber praktisch blockierten Gateways. Ein weiterer Kommentar nennt Telegram und WhatsApp als ausgefallene Kanäle während der Gateway-Instabilität.

Was sich geändert hat

Der deutlichste Schritt ist die Integration von Google Meet. OpenClaw behandelt Meet damit nicht mehr als externen Sonderfall, sondern als nativen Laufzeitpfad mit Authentifizierung, Transport, Recovery und Export-Workflows. Für Agenten, die an Meetings teilnehmen, Protokolle erstellen oder Konferenzdaten weiterverarbeiten sollen, ist das ein echter Betriebswechsel.

Auch abseits von Meet listen die Release Notes umfangreiche Änderungen auf. Dazu zählen DeepSeek V4 Flash und V4 Pro im Modellkatalog, wobei V4 Flash als neuer Standard für das Onboarding definiert wird. Im Bereich Browser-Automation wurden Koordinaten-Klicks, ein Standard-Aktionsbudget von 60 Sekunden sowie Headless-Overrides pro Profil eingeführt. Diese Anpassungen adressieren bekannte Schwachstellen bei langen Wartezeiten und fragilen Session-Wiederverwendungen, die in Agent-Setups häufig zu unerwarteten Abbrüchen führten.

Unter der Haube optimieren statische Kataloge die Modell-Listings, reduzieren breite Registry-Aufrufe und laden Provider-Abhängigkeiten verzögert nach. Diese Infrastrukturarbeit ist weniger sichtbar, aber entscheidend für die Stabilität: Schnellere Startvorgänge und eine leichtere Tool-Infrastruktur verringern die alltägliche Reibung oft nachhaltiger als neue Demo-Funktionen.

Diagnose: Was in der Praxis schiefging

Einzelne Bugreports sind nach größeren Updates üblich. Auffällig ist hier aber die Wiederholung desselben Musters. Aus den Issue-Kommentaren lassen sich drei praktische Failure-Modes ablesen:

1. Der Gateway startet scheinbar, kippt aber in Crashloops oder Restart-Schleifen.
2. Bonjour beziehungsweise mDNS hält den Startpfad fest, bis die Komponente deaktiviert wird.
3. Messenger-Kanäle wie Telegram oder WhatsApp reagieren nicht mehr, obwohl der Host selbst noch lebt.

Das ist für den Betrieb wichtiger als die Feature-Liste. Wer nur auf „Update erfolgreich“ schaut, übersieht genau die Stelle, an der OpenClaw auf Linux-VPS instabil werden kann.

Praktisch nützlich ist dabei der Abgleich von Symptom und Zustand. Wenn der Gateway-Status kippt, die lokalen Checks aber wechselhaft bleiben, ist das eher ein Start- oder Nebenkomponentenproblem als ein reiner Kanalfehler. Wenn Telegram und WhatsApp gleichzeitig still sind, lohnt sich zuerst der Blick auf den Gateway-Kern und dessen Startumgebung, nicht auf einzelne Messenger-Accounts.

Recovery: Was in den Berichten geholfen hat

Die Berichte im Issue zeigen keine magische Ein-Klick-Reparatur, aber sie zeigen sinnvolle Wege zurück in einen stabilen Zustand. Ein Teil der Betroffenen ging direkt auf die vorherige stabile Version zurück, weil die Störung produktiv zu teuer war. Ein anderer Kommentar beschreibt, dass sich der Gateway nach dem Deaktivieren von Bonjour wieder stabilisieren ließ. Das ist kein allgemeines Rezept, aber ein brauchbarer Hinweis für Hosts, auf denen die Bonjour-Schicht den Start blockiert.

Für produktive Linux-VPS heißt das: Upgrade nicht blind ausrollen, sondern zuerst die Rückfallroute klären. Wer die Installation von einem Backup oder einem Config-Drop zurücksetzen kann, ist im Zweifel schneller wieder online als jemand, der denselben Crashloop fünfmal erneut beobachtet.

Wenn du das Thema sauberer aufziehen willst, passt dazu auch der Guide zu Backup und Updates sowie der Artikel über Remote Nodes und Trust-Grenzen. Beide helfen, den Rollout nicht als Bauchgefühl, sondern als Betriebsentscheidung zu behandeln.

Reality Check

Das Release ist fachlich spannend, aber für produktive Linux-VPS nur mit Vorsicht zu genießen. Die Quellen tragen die Aussage, dass diese Version neue Fähigkeiten bringt und gleichzeitig reale Betreiber über Crashs, Bonjour-Probleme und Messenger-Ausfälle stolpern. Sie tragen nicht die Aussage, dass jeder Host betroffen ist oder dass es einen einzigen universellen Fix gibt.

Mein sauberer Schluss ist deshalb konservativ: Auf Testsystemen ist das Release interessant. Auf produktiven VPS mit laufenden Kanälen solltest du vor dem Rollout genau prüfen, ob du eine stabile Rückfallebene hast und ob dein Setup auf Bonjour oder ähnliche Nebenpfade angewiesen ist.