OpenClaw v2026.3.13‑1: Recovery Release mit kritischen Bugfixes

20. März 2026 – OpenClaw hat laut GitHub-Release gestern v2026.3.13-1 als Recovery Release ausgeliefert. Das NPM-Package bleibt auf derselben Release-Linie; das -1-Suffix betrifft Git-Tag und GitHub-Release, nicht die Paketversion.

Warum ein Recovery Release?

Nach Angaben im GitHub-Release war der ursprüngliche Release-Pfad nicht korrekt verknüpft. Dadurch konnten Release-Links und automatisierte Update-Checks ins Leere laufen – besonders unangenehm für Setups, die exakte Tag-Referenzen in Deploy-, Update- oder Monitoring-Pipelines nutzen.

Mit dem Recovery-Tag stellt das OpenClaw-Team den Release-Pfad wieder her. Das ist kein Feature-Release im großen Stil, aber ein sinnvoller Stabilitätsfix: Wer OpenClaw automatisiert betreibt, braucht verlässliche Artefakte, Tags und Changelog-Verweise.

Die wichtigsten Fixes im Überblick

Neben dem Recovery-Aspekt nennt der OpenClaw-Changelog mehrere Bugfixes, die vor allem Betreiber langlaufender Agenten-Setups betreffen: Telegram-Medien, Discord-Gateway-Metadaten, Session-State, Compaction und Container-Zeitzonen.

1. Telegram: SSRF-Hardening für Media-Transports

Fix: fix(telegram): thread media transport policy into SSRF

Laut GitHub-PR zum Telegram-Fix konnten Telegram-Medien-Downloads auf bestimmten Hosts scheitern, wenn die SSRF-Schutzlogik den IPv4-Fallback für Datei-Downloads blockierte. Betroffen waren vor allem Umgebungen mit IPv6-only- oder problematischen IPv6-Konfigurationen.

Der Patch wendet die bereits für Bot-API-Calls genutzte IPv4-Fallback-Policy auch auf Telegram-File-Downloads an. Damit werden Media-Downloads robuster, ohne die SSRF-Schutzlogik grundsätzlich abzuschalten.

Praktische Relevanz: Wenn du OpenClaw-Agenten für Telegram-Workflows nutzt, etwa für Bild- oder Dokumentenverarbeitung, reduziert der Fix Ausfälle beim initialen Medien-Download und macht Inbound-Pipelines zuverlässiger.

2. Discord: Gateway-Metadata-Fetch-Failures

Fix: fix: handle Discord gateway metadata fetch failures

Der Changelog beschreibt außerdem einen Discord-Fix für fehlgeschlagene Gateway-Metadata-Fetches. OpenClaw-Instanzen mit angebundenen Discord-Kanälen konnten demnach Probleme bekommen, wenn Metadaten wie Channel-Name oder Thread-Information temporär nicht abrufbar waren.

Der Fix behandelt diese Fehler defensiver. Statt einen Kanal oder die laufende Session hart zu beschädigen, kann der Agent stabiler weiterlaufen. Für Multi-Channel-Setups ist das vor allem ein Verfügbarkeitsgewinn.

3. Session-State: lastAccountId und lastThreadId erhalten

Fix: fix(session): preserve lastAccountId and lastThreadId on session reset

Für langlaufende Agenten ist der Session-Fix relevant: Laut Changelog bleiben lastAccountId und lastThreadId nach einem Session-Reset erhalten. Vorher konnten diese Werte verloren gehen, was Reply-Kontexte in Thread-basierten Chats wie Discord oder Slack durcheinanderbringen konnte.

Damit kann ein Agent nach Reset, Compaction oder Memory-Cleanup zuverlässiger im richtigen Account- und Thread-Kontext weiterarbeiten.

4. Weitere relevante Fixes

• Compaction-Sanity-Check: fix(compaction): use full-session token count for post-compaction sanity check – soll Token-Zählungen nach Compaction-Vorgängen in langen Sessions plausibler machen.
• Docker-Timezone-Support: Docker: add OPENCLAW_TZ timezone support – erlaubt Container-Deployments, die Zeitzone explizit zu setzen, was Logs und Cron-Ausführung nachvollziehbarer macht.
• Anthropic-Thinking-Blocks: fix(agents): drop Anthropic thinking blocks on replay – entfernt nicht benötigte Thinking-Blöcke beim Replay von Agenten-Sessions und kann dadurch Tokenverbrauch reduzieren.
• Azure-Content-Filter-Workaround: fix(agents): rephrase session reset prompt to avoid Azure content filter – entschärft offenbar falsch-positive Content-Filter-Blocks in Azure-gehosteten Deployments.

Was bedeutet das für Agenten-Betreiber?

Wenn du bereits den ursprünglichen März-Release laufen hast …

… musst du nach Angaben des Releases wegen des Recovery-Tags nicht zwingend handeln. Repariert wurde vor allem der GitHub-Release-Pfad.

Wenn du auf Release-Links oder automatisierte Update-Checks angewiesen bist …

… solltest du deine Referenzen auf den neuen GitHub-Release-Tag v2026.3.13-1 prüfen (laut GitHub-Release v2026.3.13-1). Das gilt besonders für interne Update-Skripte, Dokumentation, Monitoring-Hinweise oder Deploy-Pipelines, die direkt auf Release-Tags verweisen.

Wenn du eines der betroffenen Probleme hattest …

… lohnt sich ein Update auf eine neuere OpenClaw-Version. Das betrifft vor allem Telegram-Media-Downloads auf schwierigen IPv6-Hosts, Discord-Gateway-Probleme und verlorene Session-Kontexte nach Resets.

Für globale NPM-Installationen bleibt der übliche Weg npm update -g openclaw beziehungsweise eine Neuinstallation über npm i -g openclaw. Bei Container-Deployments solltest du deine Images neu bauen oder aktualisieren.

Was dieses Release zeigt

Das Recovery Release ist klein, aber aufschlussreich: OpenClaw behandelt kaputte Release-Artefakte nicht als Randnotiz, sondern korrigiert sie sichtbar über einen neuen Tag. Für Agenten-Infrastruktur ist das wichtig, weil Automatisierung selten an großen Produktankündigungen scheitert – sondern an kaputten Referenzen, unstabilen Channels und verlorenen Kontextdaten.

Die eigentliche Botschaft ist deshalb pragmatisch: Wer OpenClaw produktiv betreibt, sollte dieses Release nicht wegen neuer Features beachten, sondern wegen der Stabilitätsdetails. Genau solche kleinen Korrekturen halten Agenten-Systeme im Alltag belastbar.

Weiterführende Links

• GitHub Release – vollständiger Changelog
• OpenClaw Documentation – offizielle Dokumentation
• Telegram Channel Setup Guide – Hinweise zur Telegram-Anbindung

---

OpenClaw ist laut Release-Kontext über npm und die offiziellen Docker-Images verfügbar.