Dein Cron-Job ist um 3 Uhr nachts gestorben. Kein Fehler, keine Benachrichtigung – das Scheduler-Panel zeigte überall „gesund“ an, und herausgefunden hast du es erst um 9 Uhr, als die Daten längst veraltet waren. Das ist kein hypothetisches Szenario: Am 14. August 2026 verpasste Hermes’ eigene gehostete Flotte vier nächtliche Läufe in Folge – die einzige Spur war eine einzelne unscheinbare WARNING, vergraben in einer Logdatei. v0.20.3 (Tag v2026.8.16.2) ist der Patch für genau diese Klasse von Problemen: Er bringt Hermes bei, eigene Fehler selbst zu bemerken und zu beheben – statt dir das Chaos zu hinterlassen.

In diesem Fenster wurden rund 125 PRs und rund 250 Commits gemergt. Die offiziellen Notizen versprechen vollständige, kuratierte Dokumentation mit v0.21.0 – doch die wertvollsten Teile dieses Patches lassen sich schon jetzt in wenigen Worten erklären.

Cron: von „stirbt im Stillen“ zu „heilt sich selbst“

Fangen wir mit dem Teil an, der am wehsten tut. Hermes’ Scheduler kannte früher mehrere Arten, „gesund“ zu sterben – jede einzelne konnte Jobs für Stunden oder Tage lahmlegen, während das System völlig normal aussah:

• Dateideskriptor-Erschöpfung (EMFILE): Der Ticker behandelte jeden Lock-Fehler als „jemand anderes hält den Lock“ – eine fd-Erschöpfung an der Lock-Datei wurde dadurch als erfolgreicher Tick verbucht, und kein Job lief je wieder;
• Festhängende Jobs: Ein Job, der einmal einen Fehler warf, parkte sein next_run_at in der Zukunft – unsichtbar für jede Bereinigung und unempfindlich gegen Gateway-Neustarts;
• Verpasste Auslösungen durch externe Provider: Lieferte ein gehosteter Cron wie Chronos eine Auslösung nie aus, blieb der Job für immer in der Vergangenheit geparkt.

v0.20.3 behebt alle drei. EMFILE wird jetzt ehrlich gemeldet, und der Ticker versucht im Best-Effort-Verfahren, Dateideskriptoren wiederzubekommen (exponentieller Backoff, gedeckelt auf 15 Minuten); festhängende Jobs rüsten sich beim nächsten Tick automatisch wieder scharf – unter Beachtung des Cron-Ausdrucks, sodass ein Nur-Werktage-Plan nie an einem Samstag feuert; und von externen Providern verpasste Auslösungen holt das Gateway nach einer Gnadenfrist lokal nach.

Das Nachholfenster ist konfigurierbar:

cron:
  misfire_grace_minutes: 10   # Standard 10; 0 oder negativ deaktiviert das Nachholen

Genauso wichtig: Verpasste Läufe sind endlich sichtbar. Jede fehlgeschlagene Auslösung drückt dem Job-Record einen last_fire_error-Stempel auf – angezeigt als rote Zeile ⚠ Missed scheduled fire: in hermes cron list, außerdem im Dashboard und in der Ausgabe des cronjob list-Tools des Agents; der nächste erfolgreiche Lauf entfernt den Stempel wieder. Statt in den Logs zu wühlen, um herauszufinden, ob ein Job gelaufen ist, genügt ein einziger Befehl:

hermes cron list

Wenn du einen externen Cron-Provider nutzt (Chronos / gehostetes Managed Cron), führe den Befehl nach dem Upgrade einmal aus, um sicherzugehen, dass nichts aussteht. Das komplette Bild zu Scheduling, Monitoring und Preflight-Checks gibt es in unserem vollständigen Cron-Automatisierungs-Guide.

MCP: Das zustandslose Protokoll von 2026-07-28

In diesem Fenster sind außerdem die MCP-2.x-SDK-Migration und die durchgängige Unterstützung für das am 28. Juli 2026 veröffentlichte zustandslose Protokoll gelandet – einfach ausgedrückt: Die neue Generation von MCP-Servern verlangt keinen initialize-Handshake mehr, und Hermes verbindet sich out of the box mit ihnen.

Jeder MCP-Server kann einen protocol-Schlüssel deklarieren:

mcp:
  servers:
    my-server:
      url: https://example.com/mcp
      protocol: auto   # auto (Standard): alten Handshake versuchen, sonst auf server/discover zurückfallen

auto kostet die bestehende Flotte keine einzige zusätzliche Round-Trip, stateless probiert zuerst discover, und legacy schaltet den Fallback komplett ab. Auch zwei Spezifikationsdetails sind mit abgedeckt: Die Cache-Hinweise ttlMs/cacheScope aus tools/list fließen in einen Schema-Cache mit TTL, und die OAuth-Registrierung folgt der neuen Spezifikation (natives application_type + iss-Validierung nach RFC 9207). Mehr Tiefe bei der MCP-Konfiguration findest du in unserem Guide zu MCP-Kontextvariablen.

Neue Provider: CommandCode und Muse Spark

In diesem Fenster kamen zwei neue Provider dazu:

CommandCode (commandcode.ai) ist jetzt ein First-Class-Provider – ein einziger Schlüssel deckt 30+ offene und geschlossene Modelle über die Pläne GOAT/Pro/Max/Provider ab:

hermes setup   # oder manuell setzen
export COMMANDCODE_API_KEY="your-key"
hermes --provider commandcode

Lieber die Messages API von Anthropic? Das Profil commandcode-anthropic spricht sie mit demselben Schlüssel. Und auf main (noch in keinem Release-Tag enthalten) kommt die Meta Model API (Muse Spark) als eingebautes Plugin dazu – --provider meta-ai funktioniert out of the box mit MODEL_API_KEY-Authentifizierung (auch das Alias META_API_KEY funktioniert) und bietet muse-spark-1.2 und muse-spark-1.2-contributor.

Undo-Buttons für Agent-Änderungen: /worktree und /rollback

Zwei von Copilot CLI inspirierte Befehle sollen die „Der Agent hat mein Repo zerlegt“-Sorge beruhigen.

/worktree new öffnet mitten in der Session ein isoliertes Git-Worktree – ganz ohne Neustart:

/worktree new my-experiment

Hermes legt .worktrees/my-experiment/ im Repo an (Branch auf Basis eines frisch gefetchten Remote-Tips) und leitet die Terminal- und Dateioperationen der Session dorthin um. Bist du fertig, bleibt das Worktree nur erhalten, wenn es ungepushte Commits enthält – genau wie bei hermes -w. /worktree allein zeigt das aktive Worktree, /worktree list listet alle auf.

/rollback stellt jetzt standardmäßig auf sichere Wiederherstellung um: Hermes führt pro Projekt Buch über jede Datei, die es geschrieben hat (SHA-256-Hash jedes tatsächlich gelandeten Schreibvorgangs). So macht ein Rollback nur vom Agent stammende Änderungen rückgängig, löscht vom Agent erstellte Dateien und lässt deine Hand-Edits unangetastet. Mit --all oder --force stellst du alles wieder her; übersprungene Dateien werden mit einem Hinweis gemeldet. Wenn der Agent eine Datei zerlegt hat, an der du selbst Hand angelegt hattest, macht das den Unterschied zwischen Rettung und Desaster.

Upgrade

hermes update

Danach hermes doctor ausführen, um die Installation zu prüfen, und das Gateway neu starten (hermes gateway). Wenn du einen externen Cron-Provider nutzt, wirf einmal einen Blick auf hermes cron list – und vergewissere dich, dass kein Rückstand besteht.

Die vollständige Änderungsliste findest du in den v0.20.3-Release-Notes; die Highlights des vorherigen Patches zu Connection-Registry und MCP-Deep-Links gibt es in unserer v0.20.2-Analyse.