Du fährst drei Profile desselben Bots auf einer Maschine: eines beobachtet einen Support-Kanal, eines postet täglich eine Zusammenfassung, eines patrouilliert im Hintergrund. Am Montag legst du ein viertes an — und es taucht einfach nicht in der Bot-Liste des Desktops auf. Daneben steht der Gateway-Status auf „gestoppt“, also startest du den ganzen Gateway neu und reißt dabei die zwei Instanzen ab, die tatsächlich gerade arbeiteten. Was dich aber mehr beunruhigt, ist die andere Frage: Sehen diese Profile auf derselben Maschine stillschweigend die Zugangsdaten, das Gedächtnis und die Sitzungen der jeweils anderen?

v0.21.2 beantwortet beides. Eine große neue Funktion gibt es nicht — die zwei Ziele sind denkbar schlicht: Jedes Profil auf einer Maschine soll sein eigenes Zeug behalten, und der Desktop soll nicht länger für jedes Profil ein Backend öffnen.

Ein Gateway-Prozess, drei Sätze Bots

Zuerst: Ein Profil ist praktisch eine eigenständige Hermes-Installation mit eigener Konfiguration, eigenen Zugangsdaten, eigenem Gedächtnis und eigener Sitzungshistorie. Damit mehrere Profile auf einer Maschine nicht jeweils einen eigenen Gateway brauchen, bringt Hermes einen Multiplexer mit — ein einziger Gateway-Prozess, der die Bots mehrerer Profile gleichzeitig hostet. Diesen Prozess zu teilen ist genau der Vorteil und genau das Risiko: Alles, was darin „global“ aufgelöst wird, kann von einem Profil in ein anderes lecken.

Die übliche Form solcher Installationen ist ein Hauptprofil plus ein paar Sekundärprofile, die sich Prozess und einen Teil des Laufzeitstatus teilen. Wer seine Maschine so aufsetzen will, findet im Leitfaden für mehrere Profile, was geteilt werden darf und was getrennt bleiben muss.

v0.21.2 (Tag v2026.9.11, veröffentlicht am 11. September 2026, offiziell „The state.db Patch Release“ genannt) ist das Patch-Release direkt nach v0.21.1 — und es ist nicht klein: seit v0.21.1 umfasst es 947 Nicht-Merge-Commits, 1.869 geänderte Dateien (+182.504 / -15.564) und 312 gemergte Pull Requests von 140 Beitragenden. Die vollständige Liste nach Blöcken steht auf der Release-Seite zu v0.21.2; unten stehen die Teile, die nichts mit state.db zu tun haben, aber deinen Alltag verändern.

Sieben Leckpfade, in einem Zug geschlossen

Was bei einer Multi-Profil-Installation wirklich weh tut, ist kein Absturz, sondern ein stilles Durchsickern: Ein Profil nutzt Rechte, Secrets oder Dateien eines anderen, und jede Oberfläche sieht dabei normal aus. Genau darauf zielen sieben Pull Requests dieser Version:

PR	Was die Grenze überschritt	Verhalten jetzt
#107616	Die Bots eines Sekundärprofils erbten die Allow-List des Standardprofils; die Rechte-Liste wurde profilübergreifend aufgelöst	jedes Profil löst seine eigene Allow-List auf
#107617	Adapter konnten Zugangsdaten an den Host des Standardprofils schicken	Zugangsdaten reisen mit dem Profil, dem sie gehören
#107630	stdio-MCP-Server bekamen die Vault-Secrets des Standardprofils	sie bekommen nur die Secrets des aktuellen Profils
#107609	Zustellungen über MEDIA: konnten .env, auth.json oder state.db eines anderen Profils mitschleppen	die Zustellung bleibt auf das startende Profil begrenzt
#107620 / #107626	Feishu-Drive-Callbacks und Webhook-Antworten auf einem profilspezifischen Pfad konnten bei einem anderen Profil landen	Callbacks und Antworten bleiben beim gerouteten Profil
#107611	Ein Sekundärprofil konnte den Nous-Bearer-Token eines Schwesterprofils aus dem Prozessgedächtnis übernehmen	Tokens werden nicht mehr profilübergreifend wiederverwendet

#107616 verdient einen eigenen Satz. Die Allow-List definiert die Rechtegrenze eines Bots, und sie wurde bisher gegen das Standardprofil aufgelöst: Was immer du im Hauptprofil freigegeben hattest, erbte ein Sekundärprofil. Bei zwei Bots mit völlig verschiedenen Aufgaben hieß das, die Rechte des Hauptprofils an den anderen zu verschenken. Den Hintergrund dazu liefert der Artikel zur Allow-List pro Profil.

Liest man die Tabelle als Ganzes, ergibt sich ein nützlicher Test: Alles, was „auf Prozessebene“ geteilt wird — Prozessgedächtnis, der Vault, Adapter-Hosts, Zustellkanäle — war die Schwachstelle von Multi-Profil-Setups. Diese Runde flickt nicht Fall für Fall, sondern bindet die Auflösungspunkte wieder an die Profilgrenze.

Der Desktop startet kein Backend pro Profil mehr

Der zweite Block betrifft den Start des Bot Mode im Desktop, und das Symptom war deutlich zu sehen. Früher erzeugte oder wählte der Desktop beim Start und bei jedem Roster-Tick ein Backend für jedes Profil; bewegte man die Maus über die Bot-Liste, entstand ein Backend pro Zeile; ein Profilwechsel konnte doppelte Primary-Backends erzeugen. So viele Profile man hatte, so viele Backend-Prozesse sammelten sich an — und die überzähligen rangen um denselben Gateway.

Diese Version betrifft sowohl den Startpfad als auch das Rendern der Liste: #108069, #108107, #108118, #108134, #107969, #108112. Praktisch heißt das, dass das Szenario von oben ausbleibt: Ein neues Profil bedeutet keinen nächtlichen Gateway-Neustart mehr, und in der Bot-Liste tauchen keine zweifelhaften „Geister“-Einträge mehr auf.

Die Korrekturen für „das ergibt keinen Sinn“

Neben diesen zwei Blöcken räumt die Version eine Reihe kleiner Verhalten auf, die lange still genervt haben. Einzeln ist keines spektakulär; zusammen sind sie eine Wand, gegen die man täglich läuft.

Cron. Ein „jetzt ausführen“ außerhalb der vollen Stunde bricht nicht mehr den nächsten geplanten Lauf ab (#106306); ein von Hand abgebrochener Lauf blockiert nicht mehr das folgende Fünf-Minuten-Fenster (#106733); eine Aufgabe, die von einmalig auf wiederkehrend umgestellt wurde, feuert weiter (#106532); eine Aufgabe ohne festgelegtes Modell läuft mit dem Modell, das beim Anlegen festgehalten wurde (#106499); und hermes profile create --clone-all kopiert keine Cron-Aufgaben mehr mit (#106478). Letzteres ist für Multi-Profil-Nutzer am wichtigsten, denn beim Klonen geht es meistens um wiederverwendete Konfiguration — nicht darum, dieselbe geplante Aufgabe ein zweites Mal im zweiten Profil laufen zu lassen.

Kanban. kanban promote lehnt jetzt eine unabgeschlossene Elternaufgabe ab (#106550), und kanban_request_review lehnt ein unbekanntes Reviewer-Profil ab (#106547). Beides macht aus „eine schlechte Eingabe stillschweigend annehmen“ ein „klar ablehnen“.

Tools und Gedächtnis. Stirbt ein stdio-MCP-Server mitten im Aufruf, wird der Tool-Aufruf nicht mehr wiederholt (#106546) — eine Wiederholung bedeutet, dass ein womöglich schon ausgeführter Schreibvorgang ein zweites Mal passiert; genau deshalb ist dieser Fix so wertvoll. Eine Hintergrund-Review, die nur aus Skills besteht, kann keine Gedächtniseinträge mehr löschen (#106310); das mem0-Gedächtnis verliert keine langen Turns mehr (#106542); tool_search liefert lieber nichts zurück als fünf unzusammenhängende Tools, die sich ein Wort teilen (#106676); entferntes NOPASSWD-sudo löst keine Genehmigungsabfrage mehr aus (#107939); und RSS- und Reddit-Lesen ist nicht mehr standardmäßig aktiv (#105873).

Updates und Kontingent. Die Update-Prüfung fragt jetzt einmal täglich die GitHub-API ab, statt alle 30 Minuten ein git fetch zu machen (#107648); hermes update nennt den echten Grund für einen Fehlschlag und hängt nicht mehr an einem feststeckenden Fetch (#108053).

Provider und Routing. /model und das automatische Auxiliary-Routing stellen keinen Provider in Rechnung, den du nicht ausgewählt hast (#107366); Hermes schaltet nie automatisch auf einen Provider um, für den du keine Zugangsdaten hast (#107281); Bedrock Guardrails greifen (#107815).

Cache. Der Wechsel zwischen Desktop und TUI baut den System-Prompt nicht mehr neu auf und zerbricht damit nicht länger den Prompt-Cache (#105844) — für alle, die den ganzen Tag zwischen beiden Oberflächen springen, eine echte Ersparnis.

Was du tun solltest

Das Update ist ein Befehl:

hermes update

Danach lohnt sich ein kurzer Blick auf ein paar Punkte:

• Wenn du auf einer Multi-Profil-Maschine eine Allow-List konfiguriert hast: Jedes Profil löst nun seine eigene auf (#107616) — prüfe, ob die Listen der Sekundärprofile wirklich das sind, was du willst.
• Wenn du dich darauf verlassen hast, dass hermes profile create --clone-all die Cron-Aufgaben mitbringt, musst du sie jetzt von Hand neu anlegen (#106478).
• Wenn du RSS oder Reddit weiter als Inhaltsquelle nutzen willst, aktiviere sie ausdrücklich — standardmäßig sind sie aus (#105873).
• Hat eine geplante Aufgabe kein festgelegtes Modell, läuft sie jetzt mit dem Modell, das beim Anlegen festgehalten wurde (#106499).
• Die Update-Prüfung läuft nun einmal täglich (#107648) — verstehe das nicht als Verlangsamung, sie holt nur nicht mehr alle halbe Stunde etwas ab.

Noch ein Satz zur state.db-Arbeit, die hier nicht das Thema ist: v0.21.0 hat die Verbindungsbehandlung des Sitzungsspeichers neu geschrieben, wodurch state.db in manchen Installationen fragil wurde; v0.21.2 schließt diese Problemklasse. Wir haben das separat behandelt — Details in Sperren und Schreiber-Konflikte bei state.db.

Fazit

v0.21.2 ist ein Lehrbuch-Härtungspatch: keine Funktion zum Angeben, und die 947 Nicht-Merge-Commits und 312 gemergten Pull Requests fließen überwiegend darein, Grenzen wieder zurückzuholen. Wer nur ein Profil fährt, merkt am ehesten, dass der Desktop nicht mehr auf einem Haufen Geister-Backends sitzt. Wer mehrere Profile auf einer Maschine betreibt, für den ist die Version weit wichtiger: von der Rechte-Allow-List über Vault-Secrets und Credential-Hosts bis zu Tokens im Prozessgedächtnis werden sieben Leckpfade auf einmal geschlossen.

Mehrere Profile sind damit kein Setup mehr, das „läuft, aber man ist nie ganz sicher“: Jedes Profil behält sein eigenes Zeug, und der Desktop öffnet nur die Backends, die er braucht. Genau das repariert dieses Release.