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

20. März 2026 – OpenClaw hat gestern v2026.3.13‑1 als Recovery Release ausgeliefert – eine kleine, aber wichtige Aktualisierung, die den gebrochenen v2026.3.13 Tag/Release‑Pfad auf GitHub wiederherstellt. Das NPM‑Package bleibt unter der Version 2026.3.13; das ‑1‑Suffix existiert nur für Git‑Tag und GitHub‑Release.

Warum ein Recovery Release?

OpenClaw v2026.3.13 war ursprünglich bereits veröffentlicht worden, allerdings wurde der Release‑Pfad auf GitHub gebrochen, sodass die automatisierten Update‑Checks und Release‑Links nicht mehr funktionierten, wie im Release Notes dokumentiert. Solche „gebrochenen“ Releases können in DevOps‑ und Agent‑Pipelines Probleme verursachen, wenn man auf exakte Tag‑Referenzen angewiesen ist.

Um die Kontinuität wiederherzustellen, hat das Team eine Recovery‑Release (v2026.3.13‑1) bereitgestellt – ein Praxis‑Beispiel für transparentes, zeitnahes Issue‑Handling im Open‑Source‑Agenten‑Ecosystem.

Die wichtigsten Fixes im Überblick

Neben dem reiner Recovery‑Aspekt enthält das Release eine Reihe an Bugfixes, die die tägliche Stabilität und Sicherheit für Agenten‑Betreiber verbessern.

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

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

Das Problem: Auf einigen Hosts (insbesondere IPv6‑only oder fehlerhaft konfigurierten IPv6‑Stacks) scheiterten frische OpenClaw‑Installs beim Download von Telegram‑Medien (Bilder, Dokumente), weil die SSRF‑(Server‑Side‑Request‑Forgery)‑Schutzregeln den IPv4‑Fallback für Datei‑Downloads blockierten.

Die Lösung: Der Patch wendet dieselbe IPv4‑Fallback‑Policy auf Telegram‑File‑Downloads an, die bereits für Bot‑API‑Calls genutzt wird. Dadurch läuft der Media‑Transport auch auf problematischen Hosts stabil – ohne die SSRF‑Schutzfunktionen zu schwächen.

Praktische Relevanz: Wenn du OpenClaw‑Agenten für Telegram‑Workflows nutzt (z.B. für automatisierte Bild‑ oder Dokumentenverarbeitung), verhindert dieser Fix Abstürze beim ersten Medien‑Download und sorgt für zuverlässigere Inbound‑Pipelines, wie GitHub Issue #45327 dokumentiert.

2. Discord: Gateway‑Metadata‑Fetch‑Failures

Fix: fix: handle Discord gateway metadata fetch failures

OpenClaw‑Instances, die Discord‑Channels anbinden, konnten sporadisch Abstürze erleben, wenn das Gateway beim Abruf von Metadata (Channel‑Name, Thread‑Info) temporär nicht erreichbar war oder Timeouts produzierte.

Der Fix fängt diese Fehler ab und lässt den Agenten stabil weiterlaufen, anstatt den gesamten Discord‑Kanal zu deaktivieren. Das reduziert ungeplante Downtimes in Multi‑Channel‑Setups.

3. Session‑State: lastAccountId und lastThreadId erhalten

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

Ein kritischer Fix für Agenten, die langlaufende Sessions mit regelmäßigen Resets (z.B. durch Compaction‑ oder Memory‑Cleanup‑Routinen) nutzen. Vor dem Patch gingen die lastAccountId und lastThreadId‑Werte beim Session‑Reset verloren, was zu inkonsistenten Reply‑Contexts führen konnte – besonders ärgerlich in Thread‑basierten Chats wie Discord oder Slack.

Jetzt bleiben diese IDs erhalten, sodass der Agent nach einem Reset nahtlos dort weiterarbeiten kann, wo er aufgehört hat.

4. Weitere relevante Fixes

• Compaction‑Sanity‑Check: fix(compaction): use full‑session token count for post‑compaction sanity check – verhindert falsche Token‑Zählungen nach Compaction‑Vorgängen in langen Sessions.
• Docker Timezone‑Support: Docker: add OPENCLAW_TZ timezone support – erlaubt Container‑Deployments, die System‑Timezone explizit zu setzen (hilfreich für Log‑Alignment und Cron‑Jobs).
• Anthropic‑Thinking‑Blocks: fix(agents): drop Anthropic thinking blocks on replay – entfernt überflüssige Thinking‑Blocks beim Replay von Agenten‑Sessions, reduziert Token‑Verbrauch.
• Azure‑Content‑Filter‑Workaround: fix(agents): rephrase session reset prompt to avoid Azure content filter – umgeht falsch‑positive Content‑Filter‑Blocks bei Azure‑Hosted‑Deployments.

Was bedeutet das für Agenten‑Betreiber?

Wenn du bereits OpenClaw v2026.3.13 laufen hast…

…musst du nichts tun. Das NPM‑Package (Version 2026.3.13) ist unverändert; nur der GitHub‑Release‑Pfad wurde repariert. Deine Installation bleibt stabil.

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

…solltest du deine Referenzen von v2026.3.13 auf v2026.3.13‑1 aktualisieren, um gebrochene Links zu vermeiden.

Wenn du eines der betroffenen Probleme hattest…

…(Telegram‑Media‑Downloads auf IPv6‑Hosts, Discord‑Gateway‑Crashes, Session‑State‑Verlust nach Reset) lohnt sich ein Update auf die neueste Version – entweder via npm update -g openclaw oder durch Neubuild deiner Container‑Images.

OpenClaw’s Release‑Philosophie: Transparenz & Stabilität

Das Recovery‑Release illustriert zwei wichtige Prinzipien des OpenClaw‑Projekts:

1. Transparenz bei Issues: Statt einen gebrochenen Release stillschweigend zu ignorieren, stellt das Team eine explizite Recovery‑Version bereit – inklusive detaillierter Changelog‑Einträge.

2. Pragmatische Stabilität: Auch ein „nur“ Recovery‑Release wird genutzt, um akkumulierte Bugfixes mit auszuliefern – so profitieren Nutzer sofort von verbesserter Zuverlässigkeit, ohne auf den nächsten Major‑Release warten zu müssen.

Für Agenten‑Entwickler, die auf stabile, langlaufende Infrastruktur angewiesen sind, sind solche inkrementellen, fokussierten Releases wertvoller als spektakuläre Feature‑Drops: Sie reduzieren ungeplante Ausfallzeiten und halten die tägliche Arbeit reibungslos am Laufen.

Weiterführende Links

• GitHub Release v2026.3.13‑1 – vollständiger Changelog
• OpenClaw Documentation – offizielle Docs
• Telegram Channel Setup Guide – wie du Telegram stabil einbindest

---

OpenClaw v2026.3.13‑1 ist ab sofort über npm (npm i -g openclaw) und die offiziellen Docker‑Images verfügbar.