Du startest hermes update am Mittwochmorgen wie immer und erwartest, dass es die paar Dutzend Commits holt, die auf main gelandet sind. Stattdessen gibt es eine einzige Zeile aus: ✓ No newer release: stable v0.21.6; this checkout is newer and waits for the next release… — und erwähnt, dass du ein paar Hundert Commits hinter main liegst. Du hast keine einzige Einstellung angefasst.

Nichts ist kaputt. Geändert hat sich der Standard: Bei einer offiziellen Quell-Installation folgt hermes update jetzt dem stable-Kanal — dem neuesten veröffentlichten Release auf GitHub — statt jedem Commit auf main. Das sind die neuen Regeln, inklusive der einen, die viele überrascht: Der Standard bewegt sich nur vorwärts.

Worauf „stable“ tatsächlich zeigt

Stable ist das neueste veröffentlichte GitHub-Release im offiziellen Repository, und es muss drei Dinge gleichzeitig erfüllen:

• es ist kein Draft und kein Prerelease;
• sein Tag ist eine strikte semantische Version, vX.Y.Z — drei Zahlen, kein Suffix.

Wenn das passt, ist das Update-Ziel der exakte Commit, auf den dieser Tag zeigt, nicht die aktuelle Spitze irgendeines Branches, auf dem der Tag zufällig sitzt. So driftest du zwischen zwei Updates nie seitwärts in halbfertigen Code ab.

Ein Stück Geschichte ist hier erwähnenswert: Früher veröffentlichte das Projekt datumsbasierte Tags (v2026.9.24 und ähnliche). Für den stable-Feed sind nur semantische Versionen zugelassen, ein CalVer-Tag kann also nie für ein Release gehalten werden.

Wo der Kanal lebt: pro Installation, nicht global

Der Kanal-Datensatz wird in config.yaml geschrieben, aber bewusst nicht als globales update.channel:

update:
  installs:
    a4f3b2c1d0e9f8a7:                      # Install-ID (sha16 des Installations-Root-Pfads)
      path: /home/u/.hermes/hermes-agent
      channel: stable

Warum der Umweg? Weil ein ~/.hermes routinemäßig von mehreren Installationen gemeinsam genutzt wird — Hermes auf dem Host, ein Gateway in Docker und die Desktop-App können alle dieselbe Konfiguration bind-mounten. Mit einem einzigen globalen Schalter würde das Umstellen deines Entwicklungs-Checkouts auf canary auch den Update-Feed der Desktop-App umstellen.

So siehst du Identität und Pfad dieser Installation:

hermes update --install-id

Drei Befehle, nicht verwechseln

Befehl	Was er tut
hermes update	Wendet auf dem Kanal dieser Installation ein Update an
hermes update --check	Vergleicht mit dem Ziel, ohne zu pullen, zu installieren oder neu zu starten
hermes update --plan	Gibt den Plan aus: Installationsart (git/Docker/Nix/apt) und jeden laufenden Dienst mit seinem Supervisor
hermes update --set-channel stable	Persistiert den Kanal für diese Installation; updatet selbst nichts
hermes update --channel main	Wirkt nur für diesen Lauf; nichts wird gespeichert
hermes update --install-id	Gibt Identität und Pfad dieser Installation aus

Verwechselt wird das Paar --set-channel und --channel: Das erste schreibt die Konfiguration, das zweite verflüchtigt sich, sobald der Befehl endet. Willst du nur kurz schauen, was main hat, reicht --channel main und es ändert nichts am künftigen Verhalten.

Die Regel, die viele überrascht: Der Standard bewegt sich nur vorwärts

Die Umstellung des Standards erfolgte konservativ, und die Regel lautet: Eine Installation, die nie einen Kanal gewählt hat, bewegt sich nur vorwärts:

• Enthält dein Checkout bereits das neueste Release — du hast etwa main verfolgt und warst voraus —, dann bleibt es, wo es ist, bis ein neueres Release erscheint;
• Nur ein ausdrückliches --set-channel stable gilt als Zustimmung, auf dem exakten Release-Commit zu landen, selbst wenn das eine Rückwärtsbewegung bedeutet.

Diese Regel gilt für --check, den Apply-Pfad und den passiven Check, den die Desktop-App und das Update-Banner nutzen. Ein versehentliches Update stuft dich nicht still zurück, und für immer auf alten Code festgenagelt wirst du auch nicht.

Zwei Arten von Installation bleiben unberührt:

• Forks und Mirrors behalten main. Sie haben keine offiziellen Releases, es gibt also kein stable zum Folgen;
• Paketierte Installationen (MSIX, Store, gebündelt, electron-updater, extern verwaltet) haben ihren Kanal zur Build-Zeit eingebacken und können ihn nicht ändern.

Desktop: ein neuer Schalter unter Einstellungen → Über

Bei einer Quell-Installation zeigt die Desktop-App jetzt eine Update channel-Zeile unter Einstellungen → Über → Updates, mit der du zwischen Stable releases und Every commit umschalten kannst. Sie erscheint nur bei Quell-Installationen (posix-handoff / windows-handoff); paketierte Installationen sehen sie nie, weil ihr Kanal fest ist.

Das Verhalten ist gut durchdacht:

• main → stable fragt erst nach, weil dieser Schritt dich auf älteren Code bewegen kann;
• stable → main schaltet sofort um, weil es dich nie rückwärts bewegen kann.

GUI und CLI schreiben denselben Datensatz, eine in der App vorgenommene Änderung ist also sofort für hermes update --check sichtbar.

Drei Fixes, die damit kamen

Ein paar begleitende Fixes kamen mit, und alle drei lohnen sich zu kennen:

1. Die stable-Abfrage lief früher unauthentifiziert hinaus und traf das anonyme Rate-Limit. Der alte Code las releases/latest mit einem nackten HTTP-Aufruf ohne Credential und verbrauchte GitHubs anonymes Budget von 60 Anfragen pro Stunde, selbst wenn GH_TOKEN gesetzt war oder gh eingeloggt war. Hinter einer gemeinsamen Büro-, CI- oder Docker-Ausgangs-IP ist dieses Budget schnell aufgebraucht, und das resultierende 403 wurde als ✗ Could not resolve the stable source channel: No published stable release could be verified ausgegeben — was sich liest wie „es gibt gar kein Release“. Die Abfrage geht jetzt die Token-Leiter durch (Umgebung, dann gh auth token, dann anonym) und meldet ein Rate-Limit als Rate-Limit, mit seiner Reset-Zeit und, für anonyme Aufrufer, einem Hinweis, GITHUB_TOKEN zu setzen. Eine fehlgeschlagene Abfrage hält trotzdem an ihrer Stelle an und fasst das Checkout nie an.

2. Shallow- oder Offline-Checkouts werden nie zurückgezogen. Ist ein Shallow-Clone oder eine Offline-Kopie bereits neuer als das neueste Release, „korrigiert“ ein Update sie nicht mehr auf dieses Release.

3. Ein reiner Desktop-Node-Abhängigkeitsfehler reißt nicht mehr die TUI und das Web-UI mit. Dieser Punkt zählt auf Headless-Hosts. npm ci installiert ui-tui, web und apps/desktop als eine Union, und nur die Desktop-App zieht native Addons (node-pty, electron), die einen Compiler brauchen. Ein Ubuntu-Server mit g++ 9 — der -std=gnu++20 ablehnt — ließ also die gesamte Abhängigkeitsinstallation scheitern, TUI und Web-UI wurden nie gebaut, und jeder Start gab a source update could not be finished automatically (6 attempts) aus. Jetzt versucht die Installation es einmal ohne die Desktop-App erneut, baut TUI und Web-UI wie gewohnt und vermerkt den Desktop-Build als offen: Desktop app build owed: desktop dependencies failed. Außerdem gibt sie einen wirklich nützlichen Ausweg aus: Läuft die Desktop-App auf diesem Host nie, entfernt hermes uninstall --gui sie aus dem Checkout, sodass künftige Updates ihre nativen Abhängigkeiten gar nicht mehr bauen.

Welchen solltest du wählen?

• Du willst Stabilität (der Standard und das, was die meisten wollen): Nichts tun, hermes update weiterlaufen lassen.
• Du willst die allerneueste Entwicklung: hermes update --set-channel main stellt das alte Commit-für-Commit-Verhalten wieder her.
• Du willst nur schauen: hermes update --channel main --check ändert langfristig nichts.
• Du weißt nicht, auf welchem Kanal du bist: Die erste Zeile von hermes update --check sagt es dir.

Ein Hinweis, falls du auf deinem eigenen Fork entwickelst: Offizielle Releases sind nicht deine, dein Standard bleibt also main. Das ist die richtige Entscheidung — die Update-Quelle eines Forks sollte dessen eigene Entscheidung sein.

Das Fazit

Diese Änderung verwandelt das Updaten von einem kontinuierlichen Strom in eine Treppe mit Versionsgrenzen: nur zwischen veröffentlichten Releases bewegen, standardmäßig nicht zurückrollen, die Wahl pro Installation behalten und die Abfrage als du selbst authentifizieren. Wenn du hermes update täglich laufen lässt, gibt es nur drei Dinge zu merken — stable ist der Standard, nur --set-channel persistiert, und main muss man explizit verlangen.

Für den größeren Zusammenhang beginne mit unserer hermes update-Befehlsreferenz, dem älteren Artikel über graceful Upgrades und dem, was zu tun ist, wenn ein Update deine Festplatte sprengt. Aktuell ist v0.21.6; wenn du Hermes noch nicht installiert hast, ist die Installationsanleitung der richtige Einstieg.