Du siehst, dass Hermes Agent wieder ausgeliefert wurde — v0.21.6. Du öffnest die Release-Seite, und der erste Absatz sagt es dir: Das ist ein Patch-Release, das das Fenster in einen stabilen Tag zusammenfasst, und die vollständigen kuratierten Notizen erscheinen mit v0.22.0. Du führst hermes update aus, das Terminal meldet Erfolg, und dann bleibt eine Frage, die du nicht wirklich beantworten kannst: Was habe ich eigentlich installiert, und sollte ich mich beeilen? Diesmal ist das nagende Gefühl schlimmer als sonst, denn neu ist nicht nur der Inhalt — auch die Art, wie das Release erstellt wurde, hat sich geändert. Dieser Beitrag macht zwei Dinge: Er erklärt, was sich am Release-Prozess geändert hat, und er gibt dir drei Befehle, mit denen du deine Version selbst bestätigst.

Was neu ist: Der erste Tag aus der neuen Stable-Release-Pipeline

Der offizielle Text ist da unverblümt: v0.21.6 ist das erste Release, das von der neuen Stable-Release-Pipeline geschnitten wurde, und seine Form ist „ein Versuchs-Ref, ein getestetes Docker-Image und ein Beleg-Tag beim Veröffentlichen“.

Das klingt abstrakt, also hier in klaren Worten. Früher war ein Tag der Startschuss: Das Image, die gehosteten Deployments und die Nix-Pakete bauten sich danach jeweils selbst daraus. Jetzt ist es umgekehrt — zuerst gibt es einen Release-Versuch, der Versuch selbst trägt den Build und die Tests, das Docker-Image wird erst veröffentlicht, wenn er besteht, und der Beleg für das Veröffentlichte wird am Tag festgehalten. Für dich als Nutzer ist der praktische Unterschied dieser: Der Tag wird von einem Image gestützt, das getestet wurde, statt von einem Tag, aus dem du danach baust.

Der Text zieht auch die Grenze: Dieses Release liefert den Tag, das GitHub-Release und das Docker-Image. Die Desktop-App, die Termux-Pakete und der Microsoft Store bleiben auf ihrem aktuellen Build und ziehen mit dem nächsten gebündelten Release um.

Wie viel tatsächlich in das Fenster geflossen ist

Zuerst die Größe. Diese Zahlen sind die offiziellen, gemessen am Commit 818c13be1dc4fd28987e1e881a9408224afd4535:

Metrik	Wert
Nicht-Merge-Commits	8.867
Geänderte Dateien	8.342 (+772.490 / −225.600)
Gemergte PRs	2.106
Geschlossene Issues	3.027

Wenn du die Dateianzahl selbst prüfen willst, erledigt das ein Befehl (du brauchst die vollständige Git-History lokal):

cd ~/.hermes/hermes-agent
git fetch origin main --tags
git diff --shortstat v2026.9.24 818c13be1dc4fd28987e1e881a9408224afd4535
# 8342 files changed, 772490 insertions(+), 225600 deletions(-)

v2026.9.24 ist der vorherige Tag — das ist die semantische Version v0.21.5. „Ein Patch-Release ohne Notizen“ heißt nicht „nichts drin“; es heißt, dass diese 2.106 PRs nie einzeln benannt und sortiert wurden. Sie werden mit v0.22.0 dokumentiert, und der Text verspricht, dass nichts in dem Fenster übersprungen wird.

Drei Befehle, um zu bestätigen, welche Version du fährst

Geh nicht nach Gefühl, und geh nicht nach dem Wort „success“ in der Update-Ausgabe. Geh nach Installationstyp:

# 1. Versionsnummer (Git-Installationen zeigen auch den Abstand zum Tag + kurzen Commit)
hermes version

# 2. was dein letztes Upgrade tatsächlich getan hat
hermes update

# 3. Docker / hosted: schau dir den Image-Tag selbst an
docker pull nousresearch/hermes-agent:stable

Der dritte Fall verdient eine Warnung. Docker- und Hermes-Cloud-Nutzer bekommen keinen Git-Working-Tree, sie bekommen ein Image. Das Keyword für nachgelagerte Konsumenten in diesem Release ist nousresearch/hermes-agent:stable (oder :latest). Für Image-Nutzer gibt es genau eine vertrauenswürdige Antwort auf die Frage „Habe ich aktualisiert?“ — den Image-Digest, nicht die Pull-Zeit, an die du dich erinnerst.

Es gibt noch einen leicht zu übersehenden Hinweis. Git-Installationen halten in einem Install-Stamp (install-stamp.json, gelesen von hermes version) fest, wie sie aktualisiert wurden. Wenn also zwei Maschinen dieselbe Version melden, sich aber unterschiedlich verhalten, vergleiche diesen Stamp, bevor du den Code verdächtigst — wahrscheinlich siehst du gerade den Unterschied zwischen einer „light“-Installation und einer vollständigen Git-Installation.

Die Security-Fixes in diesem Fenster, an einer Stelle

Dieses Release dokumentiert seine Features bewusst nicht, aber die Security-Fixes werden separat hervorgehoben — drei Gruppen, und bei jeder lohnt es sich zu prüfen, auf welcher Seite du stehst.

1. Dashboard-Authentifizierung gehärtet (PRs #133367, #133369, #133370, plus Session-Takeover #130685). Ein einzelner Bericht von Tenable Research (TRA-725 … TRA-728) deckt vier Probleme ab: Ein gefälschtes X-Forwarded-For konnte das Rate-Limit für die Passwort-Anmeldung zurücksetzen und die Pro-IP-Grenze umgehen; unauthentifizierte Anmeldeanfragen konnten unbegrenzte Werte ins Audit-Log schreiben; die öffentlichen /auth/-Routen hatten keine Größenbegrenzung für den Request-Body; und die native Anmeldung konnte Login-Codes an ein Nicht-Loopback-Redirect senden, was Session-Takeover ermöglichte. Die ersten drei haben wir schon ausführlich in dem Beitrag zur Härtung des Dashboard-Logins aufgeschlüsselt — dort stehen die Ursache jedes einzelnen und ob dein Deployment eine Config-Änderung braucht. Der vierte (das Redirect) wird nur in diesem Release-Text explizit genannt, also lies beide zusammen für die vollständige Runde.

2. Git-Filter von Repositories gehärtet (#130661). Automatische Git-Aufrufe — Session-Workspace-Snapshots, Subagent-Worktrees, Kanban, Worktree-Cleanup, hermes -w — konnten von clean- / smudge- / process-Filterprogrammen gekapert werden, die in der eigenen Config eines nicht vertrauenswürdigen Repositories definiert sind, und das geschah, bevor du deinen ersten Prompt getippt hast. Diesen Fall haben wir ebenfalls für sich behandelt: wenn die Git-Config zu einem RCE-Einfallstor wird. Wenn du routinemäßig unbekannte Repos klonst und darin eine Session öffnest, ist das dein Grund zum Upgrade.

3. E-Mail-Gateway-Absender gehärtet (#125212, #124322). Ein in Anführungszeichen gesetzter Anzeigename im From-Header konnte so gestaltet werden, dass er wie ein allowlisteter Absender aussah, wodurch die Nachricht eines Angreifers die E-Mail-Allowlist passieren konnte. Auch das haben wir analysiert, in dem Beitrag zum Spoofing der Absenderidentität.

In einer Zeile: Alle drei Gruppen sind dieselbe Fehlerklasse: Eingabe ohne Obergrenze, vertraut, weil sie ankam. Keine davon ist ein Feature.

Solltest du jetzt aktualisieren?

Das ist nicht schwer zu entscheiden:

• Du exponierst ein Dashboard, oder du fährst das Gateway auf mehreren Maschinen oder Profilen → aktualisieren. Zwei der drei Security-Gruppen landen direkt auf deiner Angriffsfläche.
• Du klonst die Repositories anderer Leute und lässt den Agenten darin arbeiten (besonders in Team-eigenen) → aktualisieren. Das Git-Filter-Problem zündet, bevor du irgendetwas sagst.
• Du bist eine einzelne lokale Maschine ohne exponierte Ports → nichts geht so oder so kaputt, aber da die neue Pipeline ein getestetes Image als Artefakt ausliefert, ist frühes Umziehen billiger als spätes.

Das Upgrade ist weiterhin derselbe Einzeiler: hermes update; Docker-Nutzer ziehen :stable; die Desktop-App braucht diesmal nichts und folgt dem nächsten gebündelten Release.

Die Kurzfassung

• Die größte Änderung in v0.21.6 ist kein Feature — es ist, wie das Release erstellt wird: Versuchs-Ref → getestetes Docker-Image → Beleg beim Veröffentlichen festgehalten.
• Größe des Fensters: 8.342 geänderte Dateien, 2.106 gemergte PRs. Die vollständigen kuratierten Notizen erscheinen mit v0.22.0.
• Vertraue dem Wort „success“ des Updaters nicht. Bestätige mit hermes version und dem Image-Digest.
• Drei Security-Gruppen: Dashboard-Auth, Git-Filter, E-Mail-Absender. Die ersten beiden lohnen sich, heute zu handeln.

Für die Änderungen aus dem vorherigen Fenster, die „schon funktionieren, aber niemand hat sie aufgeschrieben“, sieh dir unseren Selbstcheck-Guide für das Patch-Fenster an. Und wenn du genau wissen willst, was einen Neustart übersteht, wenn du YOLO einschaltest, lies als Nächstes die YOLO-Persistenz.