Donnerstagnachmittag, du willst gerade den neuesten Build auf ein paar Team-Rechnern ausrollen. Du öffnest die Release-Notiz und bekommst einen Absatz plus eine Zeile, dass die vollständige kuratierte Beschreibung mit v0.23.0 kommt. Was du wirklich wissen musst, ist enger: Ändert sich der Alltag deiner Kollegen, was fehlt in diesem Tag, und solltest du jetzt aktualisieren oder warten?

Dieser Beitrag beantwortet diese drei Fragen für v0.22.7. Veröffentlicht am 3. November 2026, ist es ein reines Patch-Release, dessen Aufgabe darin besteht, die Merge-Queue seit v0.22.6 in eine Versionsnummer zu verwandeln, die du installieren, zurückrollen und in einem Deploy-Manifest festnageln kannst.

Wie groß das Fenster ist

Die veröffentlichten Messwerte beziehen sich auf Commit b200f5bc60e:

• 174 gemergte PRs
• 581 Nicht-Merge-Commits über 554 geänderte Dateien, +24.012 / −3.144 Zeilen
• 29 geschlossene Issues

Das ist eine Größenordnung weniger als beim letzten Roll-up: v0.22.6 packte 776 PRs und 3.448 Commits. Die Absicht ist klar — kein weiteres Feature-Release, sondern ein stabiler Punkt nach zwei Wochen Fixes. Die Notiz sagt ausdrücklich, dass die vollständige kuratierte Dokumentation für alles ab v0.22.0 mit v0.23.0 erscheint und dass nichts in diesem Fenster übersprungen wird.

Jenseits der Zahlen: Das sind die Änderungen, die dich tatsächlich erreichen.

Was schon in diesem Tag steckt

1. Web Access Start nennt jetzt den Schritt, in dem er steckt

Ein Klick auf Start im Desktop-Pane von Web Access erledigt drei Dinge in einer Anfrage: die Webapp bauen (beim ersten Mal Minuten), die Nous-Anmeldung registrieren und das gateway neu starten. Früher zeigte das Pane für den ganzen Vorgang nur ein „Starting“, sodass ein mehrminütiger Build wie hängend aussah, und wer das Pane mitten im Build erneut öffnete, bekam einen weiteren Start-Button, als wäre der erste Klick verschwunden.

Jetzt benennt das Pane den Schritt — bauen, Anmeldung einrichten, neu starten — und zählt mit, wie lange Start schon läuft. Der Fortschritt wird vom Backend pro gateway als start_progress auf /api/webapp-access/status geführt, deshalb zeigt ein neu geöffnetes Pane oder ein zweites Fenster denselben Zustand; das Pane liest diesen Status einmal pro Sekunde neu, aber nur solange seine Start-Anfrage offen ist und das Fenster sichtbar ist. Ein älteres Backend ohne das Feld wird gar nicht abgefragt.

Wenn jemand in deinem Team den ersten Start als „es sah aus, als hätte es sich aufgehängt“ beschrieben hat, nimmt dieses Release das Rätselraten raus.

2. Geplante Jobs können in einen Group Chat posten

Gruppenräume im Bot Mode sind jetzt ein echtes Zustellziel. Das Feld deliver eines cron-Jobs akzeptiert:

deliver: room:<room_id>@<profile>

Die Ausgabe landet als eine Nachricht im Raum, beschriftet mit dem Job-Namen und einem Scheduled-Tag. Wichtig ist die Weckregel: Nur die Bots, die du mit @ erwähnst, kommen dran. Ein geplanter Post, der niemanden nennt, bleibt eine Nachricht im Raum und löst keinen Modellaufruf aus; @all adressiert alle. Auch ein Fehlerhinweis wird gepostet, startet aber nie eine Runde.

Räume haben außerdem zwei Felder bekommen, die jedes Mitglied oben in seinem Turn sieht und die in Room settings bearbeitet werden:

• Purpose — wofür der Raum da ist, bis 500 Zeichen
• Shared notes — bis 4 KB

Schreib einmal „das ist der Ops-Raum, schau zuerst auf den Bereitschaftsplan“, statt es in jeder Nachricht zu wiederholen.

Im selben Batch kam lead routing, pro Raum optional: Nennt eine Nachricht niemanden, entscheidet ein Lead-Bot, wer sie übernehmen soll, und der Raum zeigt eine leise Zeile wie ada gave this to linus, sodass du die Wahl siehst und korrigieren kannst. Die Defaults bleiben unangetastet — Räume ohne Lead laufen weiter im seriellen Round-Robin, bei dem alle antworten. Für Teams, in denen fünf oder sechs Bots in einem Raum auf jede Nachricht stürzen, ist der Schalter einen Versuch wert.

Gruppenräume haben außerdem das native Chat-Layout übernommen: eine Spalte, der Live-Zustand jedes Mitglieds sichtbar im Roster statt geraten.

3. Die Telegram-Karte zeigt auf ein Setup, das auf Team Gateway funktioniert

Wenn du Telegram auf einem Team Gateway betreibst, führte dich die Hermes-Cloud-Karte früher in einen Einzelmaschinen-Setup-Flow, der an Berechtigungen endete. Jetzt zeigt sie auf die Portal-Kontoverknüpfung, die unter Team Gateway funktioniert. Kleine Änderung, aber sie war ein harter Blocker für das Shared-Bot-Deployment-Modell.

Was noch nur auf main liegt

Das ist der Teil, der beim Upgrade beißt: Ein gemergter PR auf GitHub heißt nicht, dass die Änderung im Tag steckt, den du gerade installiert hast. Mehrere Fixes landeten auf main, nachdem v0.22.7 geschnitten wurde, und warten auf das nächste Release:

• Sicherheitshinweise für Abhängigkeiten — die undici-, zod-, fast-uri-, qs-, pypdf- und pyasn1-Alerts, die die Altersgrenze für Releases erreichten, sind abgearbeitet.
• Trailing Slash beim MCP-OAuth-Issuer — Logins für Issuer, die sich nur durch einen abschließenden Schrägstrich unterscheiden (Otter.ai gehört dazu), laufen jetzt durch.
• Neue Chats auf Remote Desktop — Public-Ticket-Verbindungen scheiterten bei jedem neuen Chat mit Session unavailable / invalid_params, weil die kanonische Session-Authority-Leitung nur gewählt wurde, wenn die URL den privaten Marker native_dial trug — obwohl das gateway session_authority: true in gateway.ready schon angekündigt hatte. Der Fix verhandelt anhand dieser Ankündigung.
• Eine kleinere Skill-Bibliothek — sieben optionale Skills werden eingestellt, und die Vendor-Repos von Notion, Airtable und Shopify werden zu vertrauenswürdigen Quellen.
• Minimierte Desktop-Fenster — weniger Streaming-Arbeit im minimierten Zustand, gedrosselte Idle-Previews und Spracherkennung, die weiterläuft, wenn das Fenster nicht sichtbar ist.

Um zu prüfen, ob ein PR im Build steckt, den du fährst, vergleich die Abstammung gegen das Tag, statt Merge-Zeitstempeln zu vertrauen:

git fetch --tags origin
git merge-base --is-ancestor <merge_commit_sha> v0.22.7 && echo "in tag" || echo "main only"

Wie du aktualisierst

Wähle die Zeile, die zu deiner Installation passt:

# CLI / Installer
hermes update

# Docker / Hermes Cloud
docker pull nousresearch/hermes-agent:stable

# Microsoft-Store-App
# aktualisiert sich über den Store, nicht über dieses Tag

Desktop-Builds, die aus der .exe / .dmg installiert wurden, haben in diesem Release keine gebündelte Änderung und ziehen mit der nächsten gebündelten Version mit.

Mach vorher einen Snapshot, besonders unter Windows — nicht weil ein Patch-Release riskant ist, sondern weil der Updater state.db anfasst, und ein Snapshot macht aus einer bösen Überraschung eine langweilige:

hermes backup --quick

Jetzt aktualisieren oder eine Woche warten

Drei schnelle Entscheidungen:

• Du nutzt Web Access oder Bot-Mode-Räume: aktualisieren. Beide Unterschiede zeigen sich täglich.
• Du fährst eine Single-Agent-CLI-Installation ohne Räume und ohne Remote Desktop: eine Release abzuwarten ist vernünftig, und du sammelst die main-only-Fixes in einem Rutsch ein.
• Du schickst Modell-Traffic durch einen TLS-inspizierenden Proxy: warte und lies zuerst unsere Analyse der SSL_CERT_FILE-Regression, denn die betrifft jeden Modellaufruf.

Eine Versionsnummer ist nur Verpackung. Ob du heute handelst, entscheidet sich daran, ob dieses Fenster die Knöpfe angefasst hat, die du jeden Morgen drückst.

Weiterlesen: die Aufschlüsselung des v0.22.6-Fensters, die Anleitung zum Bot-Mode-Group-Chat, alle Releases, Installation und Upgrade.