OpenClaw 2026.7.2 Beta: Zustellung, Sessions und Cron werden robuster

OpenClaw hat am 28. Juli 2026 eine neue Beta veröffentlicht. Sie soll bereits angenommene Nachrichten besser über Neustarts und Abstürze retten, Sessions an einzelnen Nachrichten verzweigen und typische Ausfälle geplanter Jobs beheben.

Für Betreiber hängt daran eine einfache, aber unangenehme Frage: Kann eine Aufgabe zwischen Messenger und Agent unbemerkt verschwinden? Genau an dieser Übergabe setzt die Beta an. Für ein blindes Produktions-Upgrade reicht das Versprechen allerdings nicht.

Angenommene Nachrichten sollen Neustarts überstehen

Eine gemeinsame Wiederherstellung soll eingehende Nachrichten nach Gateway-Neustarts und lokalen Abstürzen weiterverarbeiten. Das gilt laut Release Notes unter anderem für Telegram, Signal und Slack. Fälle, die nicht regulär verarbeitet werden können, landen in einem Dead-Letter-Mechanismus.

Das adressiert ein konkretes Fehlerbild: Der Messenger bestätigt die Übergabe, doch der Agentenprozess fällt vor Abschluss der Aufgabe aus. Für den Nutzer wirkt die Nachricht zugestellt. Tatsächlich bleibt der Lauf irgendwo zwischen Annahme und Verarbeitung liegen. Ohne dauerhaften Übergabestatus beginnt danach die Suche in mehreren Logs.

Ein getrennter Quarantänespeicher und wiederherstellbare SQLite-Snapshots sollen die Wiederherstellung zusätzlich absichern. Schutzmaßnahmen bei Schema-Upgrades zielen auf den besonders hässlichen Fall, dass ein Crash den laufenden Zustand und gleich noch den Rückweg beschädigt.

Session-Zweige machen Fehlentscheidungen korrigierbar

Unterhaltungen lassen sich künftig ab einzelnen Nachrichten zurückspulen oder verzweigen. Die Zweige sollen in Web- und nativen Apps verfügbar sein; auch vorgelagerte Codex-Sessions werden einbezogen. Sendewarteschlangen sollen den gewählten Zweig respektieren, während veraltete Ansichten nicht mehr in einen inzwischen gewechselten Verlauf schreiben dürfen.

Der Nutzen wird bei langen Agentenläufen sichtbar. Beruht Nachricht zwölf auf einer falschen Annahme, muss niemand den gesamten Kontext von Hand rekonstruieren. Stattdessen beginnt an der problematischen Stelle ein neuer Pfad, während der ursprüngliche Verlauf zum Vergleich erhalten bleibt.

Der kritische Test ist nicht das Anlegen des Zweigs. Spannend wird es, wenn anschließend noch ein altes Browserfenster geöffnet ist. Landet dessen nächste Nachricht im aktiven Zweig, ist die Zustandsisolation gescheitert.

Cron-Fixes betreffen typische Ausfälle

Einmalige Jobs und beim Start nachzuholende Ausführungen sollen wieder zuverlässiger laufen. Geplanter Zustand und Ausführungsberechtigung sollen Neustarts überstehen. Abgeschlossene Jobs sollen außerdem nicht länger hinter langsameren Batches festhängen.

Damit sind keine exotischen Randfälle gemeint. Ein Backup oder eine Benachrichtigung kann korrekt geplant sein und trotzdem ausfallen, wenn ein Neustart den maßgeblichen Zustand abschneidet. Bei Catch-up-Jobs muss das System nach dem Neustart außerdem noch erkennen, dass eine verpasste Ausführung fällig ist.

Ein Aktivitätsprotokoll für Hintergrundarbeit soll die Diagnose erleichtern. Es erfasst unter anderem ACP-Läufe, Subagenten und Cron-Ausführungen. Zustände wie queued und running lassen sich von terminalen Ergebnissen wie succeeded, failed oder timed_out unterscheiden.

Das Protokoll startet selbst keine Arbeit. Cron und Heartbeat bestimmen den Zeitpunkt; die Task-Ansicht zeigt den tatsächlichen Verlauf. Diese Trennung ist im Fehlerfall nützlich: Ein vorhandener Zeitplan sagt noch nichts darüber aus, ob der Job gestartet oder erfolgreich beendet wurde.

Memory und Freigaben brauchen eigene Tests

Die Beta erweitert auch den Memory-Bereich. Schnellerer aktiver Abruf und unterhaltungsübergreifende Erinnerung sollen persönliche Installationen komfortabler machen. Geführte Importe aus Claude Code, Codex und Hermes kommen hinzu.

Mehr Komfort bedeutet hier auch mehr Prüfbedarf. Vor dem produktiven Einsatz würde ich gezielt kontrollieren, welche Erinnerungen importiert werden und in welcher späteren Unterhaltung sie wieder auftauchen. Unerwartet geteilter Kontext ist kein Schönheitsfehler, sondern kann private oder projektbezogene Grenzen verletzen.

Strukturierte Fragen mit Optionskarten sollen über mehrere Oberflächen funktionieren. Push-Benachrichtigungen und eine Warteschlange für Freigaben können festhängende Läufe entlasten. Voraussetzung ist, dass jede Antwort eindeutig beim wartenden Lauf und in der richtigen Session ankommt.

MCP Apps erhalten ebenfalls mehr Ausdauer im Arbeitsfluss: Gebundene Tools und Ressourcen sowie anheftbare Dashboard-Widgets sollen interaktive Oberflächen über eine einzelne Antwort hinaus nutzbar machen.

Drei Tests vor dem produktiven Upgrade

Für mich entscheidet sich der Wert dieser Beta unter Störung: Beherrscht sie die bekannten Fehlerklassen dann noch? Ein erfolgreicher Start sagt darüber fast nichts aus.

Vor einem produktiven Upgrade würde ich drei Szenarien reproduzieren:

1. Eine Nachricht annehmen lassen und das Gateway vor Abschluss der Verarbeitung neu starten. Erwartung: Die Aufgabe wird fortgesetzt oder eindeutig als nicht verarbeitbar markiert; sie darf nicht still verschwinden.
2. Einen einmaligen oder nachzuholenden Job über einen Neustart hinweg beobachten. Erwartung: Fälligkeit und Ergebnis bleiben in der Task-Ansicht nachvollziehbar.
3. Eine Session verzweigen und danach aus einer veralteten Ansicht senden. Erwartung: Die Nachricht beschädigt nicht den aktiven Zweig und landet nicht unbemerkt im falschen Verlauf.

Erst wenn diese Eingriffe Zustellung, Jobstatus und Zielzweig nicht aus dem Tritt bringen, entsteht ein belastbarer Betriebsgewinn. Wer die drei Pfade nicht beobachten kann, sollte mit dem Produktions-Upgrade warten. Neue Funktionen sind nett; bei Zustellung und Zeitplanung zählt der nachweisbare Fehlerfall.