Stell dir eine Maschine mit mehreren Profiles vor: dein eigenes, ein team-geteiltes und ein Demo-Profil für Kunden. Jemand installiert ein Community-Plugin – eine kleine Sache, die ein Ticketsystem in den Chat einspeist. In dem Moment, in dem es importiert wird, lebt dieses Plugin im selben Python-Prozess wie jede Session, jede Provider-Credential und jeder im Speicher gehaltene API-Schlüssel. Auch ein Plugin-Autor mit guten Absichten kann eine globale Variable, einen Monkeypatch oder einen nie endenden Thread ausliefern, und all das kann Dinge erreichen, die es nie berühren sollte.

Hermes gibt dir jetzt einen Schalter dafür: Plugins von Drittanbietern aus dem Hauptprozess herausnehmen. Die Konfiguration ist eine Zeile, plugins.isolation: host, und das Plugin selbst ändert sich überhaupt nicht.

Der Standard hat sich nicht geändert; der neue Modus ist ein Host pro Profile

Seien wir präzise, denn nichts ändert sich, bis du es verlangst. Der Standard ist weiterhin in_process: Plugins werden in den Hermes-Prozess importiert, genau wie bisher. Nur ein explizites host ändert das Verhalten.

plugins:
  isolation: host        # Standard: in_process
  host:
    launcher: []         # optionales argv-Präfix für den Host, z. B. ein Sandbox-Runner

Mit host bekommt jedes Profile einen separaten, bei Bedarf gestarteten Python-Prozess – den Plugin-Host –, der nur die vom Nutzer installierten Plugins dieses Profiles importiert und über eine private Pipe mit Hermes spricht. Mitgelieferte (bundled) Plugins sind nicht betroffen und laufen weiterhin im Prozess.

Ein Designdetail ist leicht zu übersehen und wichtig: Der Host-Prozess startet mit nur der Umgebung und den Secrets dieses Profiles. Ein Plugin sah früher, welche Credentials der Prozess mit sich trug; jetzt sieht es die des eigenen Profiles. In einem Multi-Tenant-Deployment ist das die praktische Bedeutung von „der Plugin-Code eines Mandanten teilt niemals Speicher mit den Daten eines anderen Mandanten“.

Plugins ändern sich nicht: dasselbe ctx, über die Pipe serialisiert

Das Lästige an den meisten Isolationsgeschichten ist, dass man Code umschreiben muss. Hier nicht.

Im Host bekommt ein Plugin dasselbe ctx wie immer. Tools, Hooks, Slash-Befehle, CLI-Befehle, Skills und Provider-Objekte (Bild- und Videogenerierung, Websuche, Browser, TTS/STT, Memory, Context-Engines, Cron) registrieren sich exakt wie zuvor. Hermes registriert auf seiner Seite passende Proxies, die bei Bedarf in den Host hineinrufen – die Docs nennen das Objekt, das Plugins erhalten, RemotePluginContext.

Es ist außerdem re-entrant: Während ein Plugin einen Tool-Aufruf bearbeitet, kann es über ctx.dispatch_tool, ctx.get_config oder ctx.llm zurück in Hermes rufen – und Hermes wartet darauf, genau als wäre das Plugin noch lokal. Für Plugin-Autoren ist das im Wesentlichen kostenlose Isolierung.

Es gibt einen Preis, und er wird veröffentlicht statt entdeckt. Eine Handvoll Oberflächen braucht wirklich In-Process-Code, und unter host werden diese Plugins mit einer klaren Begründung abgelehnt, statt still Funktionen zu verlieren. Die dokumentierte Liste: Gateway-Plattform-Adapter (register_platform), Approval-Transporte, Telegram- und andere Plattform-Handler, Model-Provider-Profile, die ihren eigenen SDK-Client bauen (create_client), Streaming-Dashboard-Endpunkte und Plugins, die Hermes-Module monkeypatchen. Betreibe diese mit isolation: in_process.

Abstürze bleiben im Host

Der erste Gewinn der Isolierung ist nicht Sicherheit, sondern Stabilität. Unter host:

• das Modul eines Plugins gelangt nie in den Hermes-Prozess, kann also keine Daten eines anderen Profiles aus dem Speicher lesen oder Hermes-Interna patchen;
• ein Plugin, das abstürzt oder sich beendet, reißt seinen Host mit, nicht Hermes. Der laufende Aufruf gibt einen Tool-Fehler zurück, danach startet Hermes den Host neu und lädt seine Plugins nach (mit begrenzten Retries), während jede andere Session weiterläuft.

Wenn du jemals ein Plugin installiert und mit ihm das ganze Gateway hast untergehen sehen, ist dieser Abschnitt für dich.

Aktivieren, prüfen, festnageln

Aktiviere es mit dem Konfigurationsblock oben. Zwei Befehle sagen dir sofort die Wahrheit:

# Prüft, ob ein Plugin im Host-Modus laufen kann; erklärt jede Ablehnung
hermes plugins validate <dir>

# Zeigt, wo ein bestimmtes Plugin läuft
hermes plugins show <name>

host.launcher gibt es für strengere Setups: Es nimmt ein argv-Präfix, das den Host-Prozess in deinen eigenen Sandbox-Runner einwickelt. Die Docs empfehlen außerdem, das Terminal des Agenten auf einem isolierten Backend (Docker, SSH und so weiter) laufen zu lassen – das Plugin zu isolieren, während das eigene Terminal des Agenten weiterhin die Dateien des Operators lesen kann, bringt dir nur die halbe Isolierung.

Dann ist da das praktischste Problem in geteilten Deployments: plugins.isolation ist gewöhnliche Profile-Config, also kann jeder, der die config.yaml eines Profiles bearbeiten darf, sie abschalten. Wenn die Profiles genau den Leuten gehören, von denen du sie gegeneinander isolierst, pinne den Wert stattdessen im Managed Scope – eine root-eigene /etc/hermes/config.yaml, die jedes Profile liest. Der Managed-Wert gewinnt gegen die eigene Config jedes Profiles, und hermes config set weigert sich, ihn zu ändern:

# /etc/hermes/config.yaml (root-eigen; wird von jedem Profile der Maschine gelesen)
plugins:
  isolation: host
  host:
    launcher: [...]

Wie viel vom Katalog bereit ist

Die naheliegende Sorge: Wenn ich das einschalte, funktionieren meine installierten Plugins dann noch?

Die Docs nennen die Zahl zum Zeitpunkt des Schreibens: 299 der 348 Plugin-Katalog-Einträge laufen unverändert im Host. Das ist der eigentliche Wert der Nicht-unterstützt-Liste oben – sie verwandelt „Wird das kaputtgehen?“ in eine kurze, prüfbare Liste statt in ein Experiment auf deiner eigenen Maschine.

Wann du es bekommst

Das Feature wurde am 3. Oktober 2026 in den main-Branch gemergt. Die neueste Release ist v0.21.5 (Tag v2026.9.24), also lebt es derzeit nur auf main und ist noch in keiner getaggten Release. Installationen, die main verfolgen, bekommen es beim nächsten hermes update; Release-Nutzer erhalten es im nächsten Tag.

Für das breitere Plugin-System – Installationsquellen, die Enable-Allow-List, Unterkategorie-Verzeichnisse – sieh dir den Plugin-Katalog-Leitfaden an. Katalog-Delistings und Supply-Chain-Regeln behandelt der Beitrag zum Katalog-CI-Gate, und wenn dein Schmerz „Ich muss neu starten, bevor eine Plugin-Änderung wirkt“ ist, passt der Leitfaden zum Live-Rewire von Plugins besser.

Die Kurzfassung

Ein Plugin zu installieren bedeutete früher, fremden Code in deinen Prozess einzuladen. Jetzt kannst du ihn draußen halten, und das Plugin merkt nicht einmal den Unterschied. Auf einem Single-User-Laptop wirst du diese Zeile wahrscheinlich nie anfassen. Auf einer Maschine, die mehrere Personen oder Mandanten trägt, gehört sie in die Kategorie der Schalter, die du vor dem Vorfall gerne aktiviert hättest – nicht danach.

Wenn du ein geteiltes Deployment betreibst, tu zwei Dinge: führe hermes plugins validate über alles aus, was du installiert hast, und schreibe dann plugins.isolation: host in den Managed Scope, statt es jedem Profile selbst zu überlassen.