Du klappst den Laptop zu, um an einem Call teilzunehmen, kommst zurück, und der Hermes Desktop lädt ganz normal – dann sollst du dich neu anmelden. Niemand hat dein Konto rausgeworfen: dein eigener Client hat die Session ungültig gemacht. Am häufigsten passiert das, wenn du ein Remote-Gateway und den Desktop zusammen nutzt, und es trifft immer den Moment, in dem du am wenigsten Lust darauf hast.

v0.21.3 (Tag v2026.9.14, erschienen am 14. September 2026, Spitzname „The Sign-In Patch“) existiert für genau diesen Fehler. Es ist außerdem ein Update-Kanal für Cloud-Nutzer: Docker-Images und Hermes Cloud bauen aus dem neuesten Release-Tag, also muss ein Fix erst in ein stabiles Tag einfließen, bevor er Installationen erreicht, die hermes update nie von Hand ausführen.

Warum ein Wake-Burst eine ganze Session ungültig machen kann

Fangen wir bei den Bausteinen an. Für den Remote-Zugriff hält ein Client ein Token-Paar: ein Access-Token (kurzlebig, für Anfragen) und ein Refresh-Token (langlebig, um neue Access-Tokens zu holen). Um den Schaden eines Leaks zu begrenzen, rotiert der Authorization-Server das Refresh-Token bei jeder Nutzung – der alte Wert stirbt sofort, nur der neue zählt. Wird der alte Wert ein zweites Mal vorgelegt, liest der Server das als gestohlenes Token, und die schützende Reaktion ist der Widerruf der gesamten Session.

Das Problem: Es gibt zwei Refresh-Pfade – das Cookie-Gate des Gateways und die eigene native Bearer-Route des Desktops. Beide halten dasselbe rotierende Refresh-Token. Wenn der Desktop aus dem Schlaf aufwacht, feuert er mehrere Anfragen auf einmal – ein natürlicher Burst –, und beide Pfade refreshen fast gleichzeitig, sodass derselbe alte Wert zweimal vorgelegt wird und sich die Session selbst abmeldet (#110061, fixes #55712).

Der Fix legt diese Refreshes zusammen: Tragen gleichzeitige Anfragen dasselbe rotierende Token, führt eine die Rotation aus und der Rest übernimmt ihr Ergebnis, statt das Token erneut vorzulegen. Der Refresh ist außerdem vom Event-Loop weggezogen, sodass ein langsamer Identity-Provider /api/status nicht mehr blockiert, während er wartet.

Die Portal-Seite passt zu dieser Änderung (hermes-portal#1209): ein gleitender 30-Tage-Idle-Horizont plus eine 5-Minuten-Gnadenfrist für ein rotiertes Token, damit eine Anfrage, die mit dem gerade rotierten Wert wirklich noch unterwegs ist, nicht als Wiederverwendung gelesen wird.

Der leisere Fix: doppelte state.db-Writer-Handles

Dasselbe Fenster bringt einen weiteren Fix an der Session-Speicherung, dieser versteckt sich in den Logs. Wenn du bei der Diagnose je eine Warnung N live SessionDB handles gesehen hast, sollte sie „mehr als ein Prozess schreibt in diese Datenbank“ bedeuten – aber sie kam auch bei gesunden Topologien (#110934, fixes #100896 und #103339).

Das Gateway, das Dashboard-/Desktop-Backend, die ACP-Oberfläche und CLI-Reader hängten jeweils ein eigenes Writer-Handle an. Die Regel ist jetzt explizit: Reader hängen nur lesend an, und In-Process-Writer teilen sich das eine Registry-Handle. Weniger Handles bedeuten weniger Chancen, dass eine Komponente die Locks einer anderen aufhebt – genau die Fehlerklasse, die das v0.21.2-Patch mit sechs PRs geschlossen hat und die unser state.db-Troubleshooting-Beitrag beschreibt.

Was sonst noch in v0.21.3 steckt (richtig dokumentiert in v0.22.0)

v0.21.3 ist ein rollendes Tag: Die ~338 gemergten PRs, 1.036 Non-Merge-Commits und 2.642 geänderten Dateien seit v0.21.2 stecken alle in diesem Fenster. Das meiste bleibt bewusst den v0.22.0-Notes überlassen, deshalb hier die Form dessen, was kommt, nach Bereichen:

Bereich	Was ausgeliefert wurde
Gateway-Contract	Server→Client-JSON-RPC-Requests ersetzen die *.request / *.respond-Event-Paare (#110521); ein Pydantic-Wire-Contract-Registry generiert die TypeScript- und OpenRPC-Typen (#110522, #110523)
Modelle und Reasoning	Reasoning-Aufwand in jedem Model-Picker; eine Composer-Pille und Steuerung des Aufwands pro Auxiliary im Desktop; OpenRouter-OAuth-PKCE-Login
MCP	OAuth-Refresh-Tokens, gebunden an den Issuer, der sie ausgestellt hat; ein täglicher Re-Auth-Hinweis im Desktop
Medien	HEIF-/HEIC-/AVIF-Dekodierung
Provider	Wan 3.0, Kling 3.0 / Kling Image v3, MiniMax H3 Max Turbo, Gemini Omni Flash 1.1 und Meta Muse in den FAL-Katalogen; das Honcho-Peer-Model-Setup überarbeitet
Plattformen	eingefügte Tabellen in Slack und die Agent Sessions API
Storage und Profile	Isolation multiplexter Profile und Gateway-Liveness-Fixes; die Weigerung, den WAL-journal_mode auf Dateisystemen zu nutzen, die über VMs hinweg geteilt werden

Die Liste Block für Block steht auf der v0.21.3-Release-Seite, und der Diff des Fensters liegt unter v2026.9.11…v2026.9.14.

Was du jetzt tun solltest

Manuelle Installationen aktualisieren mit einem Befehl:

hermes update

Docker- und gehostete Umgebungen bauen aus dem neuen Tag neu:

docker pull nousresearch/hermes-agent:v2026.9.14

Wenn deine Sessions früher nach dem Aufwachen des Desktops gestorben sind, lohnt sich dieses Upgrade zuerst. Wenn nicht, hat dein Nutzungsmuster das gleichzeitige Fenster schlicht verpasst – das Upgrade ist genauso sicher.