Du betreibst drei Hermes-Profile: eines für die Arbeit, eines für private Projekte, eines für Experimente. Jedes Profil ist mit dem Docker-Terminal-Backend konfiguriert, sodass bei jedem Start gleich mehrere Container auf deiner Maschine hochfahren – mehr Speicherverbrauch, langsamere Starts, Abhängigkeiten, die in jedem einzeln installiert werden, und Umgebungsänderungen, die Container für Container synchronisiert werden müssen. PR #94633, gemerged am 25. August, bietet eine elegante Lösung: Vertrauenswürdige Profile können sich einen persistenten Docker-Container teilen, gesteuert über einen einzigen Konfigurationsschlüssel.

Vorher: ein Container pro Profil

Zuerst das Standardverhalten: Das Docker-Backend von Hermes (terminal.backend: docker) gibt jedem Profil seinen eigenen Container – die Isolationsregel, die noch am selben Tag durch PR #94560 festgelegt wurde: Container sind pro Profil abgegrenzt und benannt (profile:<name>), keine Querverbindungen. Der Vorteil ist eine saubere Isolation; der Nachteil sind doppelte Ressourcen: Drei Profile bedeuten drei Sätze Abhängigkeiten, drei Caches, drei Umgebungen.

Wenn du Docker hauptsächlich für einmalige isolierte Aufgaben nutzt, ist dieser Standard völlig in Ordnung – keine Änderungen nötig. Wenn aber mehrere deiner Profile zur „vertrauenswürdigen Familie“ gehören – etwa ein Arbeitsprofil und ein Experimentierprofil, die tatsächlich dieselbe Dev-Umgebung verwenden –, ist die Duplizierung reine Verschwendung.

Jetzt: ein Schlüssel, ein Container

PR #94633 führt einen neuen Konfigurationsschlüssel ein: terminal.docker_shared_container_key. Die Regeln sind einfach:

• Nicht gesetzt (Standard: leerer String): aktuelles Verhalten, jedes Profil behält seinen eigenen Container;
• Mehrere Profile auf denselben Wert gesetzt: Sie teilen sich einen persistenten Container, gekennzeichnet als shared:<your-key>;
• Auch direkte CLI-Aufrufe (ohne Profilkontext) mit demselben konfigurierten Schlüssel landen in diesem gemeinsamen Container.

Konfiguration:

hermes config set terminal.docker_shared_container_key team/ws

Oder bearbeite die Konfigurationsdatei direkt (hermes config path zeigt deren Speicherort):

terminal:
  backend: docker
  docker_shared_container_key: "team/ws"

Sobald die Profile work und research beide team/ws verwenden, landen ihre Befehle im selben Container: Abhängigkeiten einmal installieren und alle sehen sie, Caches bleiben warm, Umgebungsänderungen greifen an einer Stelle. In den offiziellen Tests lösen beide Profile denselben Container-Schlüssel shared:team/ws auf.

Fälle, in denen das Teilen bewusst ignoriert wird

Das ist kein blindes Zusammenlegen – drei Grenzen sollte man kennen:

• SSH-Backends machen nicht mit: terminal.docker_shared_container_key betrifft nur das Docker-Backend; SSH-Umgebungen ignorieren es vollständig;
• Nicht-persistenter Modus bleibt isoliert: Wenn du Wegwerf- (nicht-persistente) Docker-Sitzungen nutzt, stopft der gemeinsame Schlüssel keine zwei flüchtigen Sitzungen in einen Container – die Isolation pro Sitzung bleibt erhalten;
• Unterschiedliche Schlüssel = kein Teilen: Der Schlüssel ist die Isolationsgrenze; Profile mit unterschiedlichen Werten nutzen jeweils ihren eigenen Container.

Außerdem bleiben Dateien, die im gemeinsamen Container entstehen (z. B. MEDIA-Anhänge), aus den Sitzungen abrufbar – die offiziellen Tests deckten ausdrücklich die Medienauslieferung aus der gemeinsamen Sandbox ab.

Wann aktivieren, wann in Ruhe lassen

Gute Kandidaten: Profile, die eigentlich nur verschiedene Einstiegspunkte in dieselbe Dev-Umgebung sind; ein gemeinsamer „Umgebungs-Container“ für ein Team; private Nutzer mit mehreren Profilen, die Speicherplatz und Startzeit sparen wollen.

Standard beibehalten: Profile mit geringem gegenseitigem Vertrauen (z. B. solche, die nicht vertrauenswürdige Automatisierung hosten); Umgebungen, die eine strenge Audit-Isolation benötigen; experimentelle Profile, deren Abhängigkeitsversionen kollidieren könnten. Isolation ist immer sicherer als Teilen – der gemeinsame Schlüssel ist für „vertrauenswürdige“ Profile gedacht, und genau das bedeutet „trusted profiles“ im PR-Titel.

Zusammenfassung

Ein Konfigurationsschlüssel verwandelt „ein Docker-Container pro Profil“ in „ein Container für die ganze Familie“: terminal.docker_shared_container_key leer lassen erhält die Standard-Isolation, während mehrere Profile mit demselben Wert einen persistenten Container teilen. Mehr zu Multi-Profil-Workflows findest du in unserem Leitfaden zu mehreren Profil-Instanzen; für Konfigurationsdatei-Operationen deckt die Befehlsreferenz zu hermes config den Rest ab. Noch unsicher, ob Docker das richtige Backend ist? Die Installationsanleitung geht alle Backend-Optionen durch.