Wenn Ihr Hermes zwei Profile gleichzeitig betreibt – eines für den Firmenserver, eines für Ihr NAS zu Hause – sollten Sie zuerst das hier lesen: #92156, am 22. August in main gemergt, behebt ein Leck, durch das Sie Befehle auf dem falschen Host ausführen könnten. Das klingt hochgradig technisch, doch die Konsequenz ist unmittelbar: Nach einem Profilwechsel könnten Ihre Terminalbefehle stillschweigend weiterhin die zwischengespeicherte SSH-Umgebung des vorherigen Profils verwenden – ein Befehl, von dem Sie dachten, er laufe auf Server A, wurde also tatsächlich auf Server B ausgeführt.

Wie das Leck entstand

Das Terminal-Tool von Hermes cached die Remote-Umgebung jeder Session (etwa die SSHEnvironment), damit es nicht bei jedem Befehl die Verbindung neu aufbauen muss. Dieser Cache lebt in einem Dictionary namens _active_environments, das über einen Schlüssel indiziert wird, den _resolve_container_task_id() erzeugt.

Das Problem war genau dieser Schlüssel: Jede WebUI-/Gateway-Session landete auf dem gemeinsamen Schlüssel default. Im selben Prozess teilten sich also Profil A (ssh_host=10.0.0.1) und Profil B (ssh_host=10.0.0.2) einen einzigen Cache-Slot – nach einem Profilwechsel konnte das Terminal von B die gecachte SSH-Umgebung von A aufgreifen, und Befehle liefen stillschweigend auf 10.0.0.1 statt auf dem gemeinten 10.0.0.2.

Über SSH ist das besonders gefährlich: rm, git push, Konfigurationsänderungen – wenn sie auf dem falschen Host laufen, bedeuten das destruktive Aktionen am falschen Ziel, ganz ohne Warnung, denn die Ausgabe sieht völlig normal aus.

Der Fix: Cache pro Session begrenzt

Der Fix in #92156 ist unkompliziert: Der Cache-Schlüssel wurde von default auf session:<key> geändert.

• Die WebUI-Streaming-Ebene setzt pro Session einen eigenen Session-Schlüssel;
• Der gateway injiziert über contextvars einen Session-Schlüssel pro Nachricht;
• Nach einem Profilwechsel (Session-Wechsel) erhält die neue Session einen anderen Cache-Schlüssel und kann die SSHEnvironment des vorherigen Profils nicht mehr wiederverwenden – Befehle können also nicht mehr an den falschen Host geschickt werden.

Beachten Sie, was der Fix nicht bricht: Subagenten teilen weiterhin den langlebigen Container der übergeordneten Session, und RL-/Benchmark-Umgebungen (TerminalBench2 usw.) behalten ihre Isolation pro Aufgabe – diese Pfade haben ihre eigenen Schlüsselregeln, und delegate_task-Kinder nutzen weiterhin die Verbindung der übergeordneten Session.

Was Sie tun sollten

1. Multi-Profil- und SSH-Nutzer: Aktualisieren Sie auf einen Build, der den Fix enthält (hermes update --branch main), oder warten Sie auf das nächste Release – die neueste stabile Version ist weiterhin v0.20.5;
2. Verifizieren Sie es: Richten Sie zwei Profile mit unterschiedlichen Remote-Hosts ein, führen Sie in jedem hostname oder echo $SSH_CONNECTION aus und bestätigen Sie, dass die Ausgabe zur Konfiguration des jeweiligen Profils passt;
3. Allgemeiner Tipp: Multi-Profil-Setups werden in Hermes-Profile: Mehrere unabhängige Instanzen behandelt; die Schlüssel für die Terminal-/Umgebungs-Konfiguration werden auch in 4 versteckte Hermes-Tricks erwähnt.

Release-Status

Der Fix (#92156) ist in main gemergt (22. August) und noch in keinem Release enthalten. Zum frühen Ausprobieren: hermes update --branch main. Er gehört zur selben Serie von Gateway-/Terminal-Härtungen Ende August wie der Leitfaden zur Loop-Watchdog-Abstimmung.

Fazit

Das profilübergreifende SSH-Umgebungsleck ist eine unsichtbare Falle: kein Fehler, sondern stillschweigendes Ausführen auf dem falschen Host. Die gute Nachricht: Der Fix ist bereits in main – dank der pro Session begrenzten Cache-Zuordnung kann ein Profilwechsel die Remote-Umgebung des vorherigen Profils nicht mehr aufgreifen. Wenn Sie viele Profile nutzen, lohnt es sich, sofort zu aktualisieren und zu verifizieren.