Du hast eine alte config.yaml auf einen neuen Rechner mitgenommen, oder du hast vor ein paar Wochen ein Plugin deinstalliert und ein Toolset umbenannt. Hermes startet, chattet und sieht vollkommen gesund aus — bis eines Tages ein Plattform-Bot nicht mehr antwortet oder eine ganze Klasse von Tools einfach fehlt. Du öffnest die Config-Datei, und jeder Name, den du erwartest, steht noch da.

Das ist Config-Rot: Die in platform_toolsets gespeicherten Toolset-Namen sind genau das, wovon Hermes zum Speicherzeitpunkt glaubte, dass es existiert. Nachdem ein Plugin entfernt oder ein Toolset umbenannt wurde, zeigen diese Namen ins Leere, und die Laufzeit ignoriert sie stillschweigend. Ein am 2026-09-29 zusammengeführter Patch (PR #127782, der #127392 rettet und die ursprüngliche Urheberschaft beibehält) lässt hermes config check die veralteten Einträge melden und richtet sein Urteil an der Laufzeit aus.

Ein Resolver, drei Aufrufstellen

Der strukturelle Kern des Patches besteht darin, die Frage „Ist dieser gespeicherte Name noch ein echtes Toolset?“ in einer einzigen Funktion zusammenzufassen:

# hermes_cli/toolset_validation.py
def saved_toolset_resolver(config: dict) -> Callable[[str], bool]:
    """is_valid_toolset for a saved platform_toolsets list, mirroring what
    tools_config._get_platform_tools lets through."""

Sowohl hermes config check als auch hermes config migrate laufen jetzt darüber. Warum ist das wichtig? Weil migrate vor dem Fix korrekt konfigurierte MCP-Server-Namen und Plugin-Plattform-Bundles bemängelte — bis hin zu dem Vorschlag, 'hermes-teams' in 'hermes-teams' zu ändern. Eine Migrationsprüfung, die sich selbst widerspricht, ist reines Rauschen.

Die neuen Regeln sind es wert, sich gemerkt zu werden, denn sie erklären, warum deine Config aufgehört hat zu meckern:

• Ein konfigurierter MCP-Server gilt als bekannt, selbst wenn er enabled: false deklariert. Er ist inaktiv, kein Tippfehler. Der alte Code behandelte „inaktiv“ als „unbekannt“ und erzeugte ein sinnloses „unknown toolset — did you mean hermes-cli?“.
• known_plugin_toolsets ist kein Beweis mehr dafür, dass ein Toolset existiert. Es hält fest, was einer Plattform zum Speicherzeitpunkt angeboten wurde, und verdeckte damit genau den Fall, für den diese Prüfung existiert: Namen, die von deinstallierten Plugins übrig geblieben sind.
• Plugin-Lookup und der Scan des Plattform-Manifests laufen nur für Namen, die die günstigeren Prüfungen nicht einordnen können. Eine saubere Config löst nie eine Plugin-Erkennung aus, die Prüfung selbst kostet also nichts.

Deaktivierte Plattformen: bewertet, wie die Laufzeit sie sieht

Die zweite Familie von Fehlalarmen kam von plugins.disabled. Die Laufzeit ist bei der Form nachsichtig — sie berücksichtigt nur eine Liste —, aber die alte Prüfung bewertete den rohen YAML-Wert, sodass diese Zeile:

plugins:
  disabled: platforms/telegram   # a string, ignored by the runtime

als „platform disabled“ gemeldet wurde, während die Laufzeit sie weiterhin bereitwillig geladen hat. Die Prüfung liest jetzt über den eigenen Reader der Laufzeit (_get_disabled_plugins()), ein Nicht-Listen-Wert wird also nicht mehr als Deaktivierung von irgendetwas gemeldet.

Und wenn sie meldet, prüft sie, ob die erforderlichen Zugangsdaten der Plattform tatsächlich konfiguriert sind:

platform plugin 'platforms/telegram' is disabled while its required credentials are configured.
Run `hermes plugins enable platforms/telegram` if you want it active.

Beachte „required“: Das Gate ist _platform_manifest_env_entries(optional=False), optionale Variablen zählen also nie. Eine deaktivierte Plattform ohne Token bleibt unangetastet, und eine optionale Env-Variable kann nicht als „du wolltest das offensichtlich laufen lassen“ missverstanden werden.

Ein Absturz behoben, eine Prüfung entfernt

Zwei weitere Dinge, die unzusammenhängend wirken, es aber nicht sind:

• Ein fehlerhaftes mcp_servers bringt den Befehl nicht mehr um. Schreibst du es versehentlich als Liste (mcp_servers: [a]), löste der alte Code einen AttributeError-Traceback aus; jetzt läuft er durch und meldet das Problem als gewöhnliche Diagnose. Ein Diagnosebefehl, der abstürzt, ist die nutzloseste Art von Fehler.
• Die Prüfung des Top-Level-Schlüssels toolsets ist weg. Der ursprüngliche PR validierte außerdem den Top-Level-Schlüssel toolsets, doch die CLI löst Toolsets aus --toolsets oder platform_toolsets auf und liest den Top-Level-Schlüssel nur für das Legacy-Kanban-Opt-in. Einen Schlüssel zu prüfen, den die Laufzeit nie liest, erfindet nur Arbeit für dich.

Die Tabelle unten stammt aus dem Validation-Run des Patches selbst (echtes hermes config check, temporäres HERMES_HOME), altes Verhalten links:

Fall	Vorher	Jetzt
platform_toolsets.cli listet einen entfernten Namen	gemeldet	gemeldet
Toolset eines deinstallierten Plugins, gemerkt in known_plugin_toolsets	still	gemeldet
MCP-Server mit enabled: false in platform_toolsets gelistet	„unknown toolset, did you mean hermes-cli?“	still
mcp_servers: [a] (falsche Form)	AttributeError-Traceback	läuft
plugins.disabled: platforms/telegram (String) mit konfiguriertem Token	als deaktiviert gemeldet (Laufzeit lädt es trotzdem)	still
plugins.disabled: [platforms/telegram] mit konfiguriertem Token	gemeldet	gemeldet

Warum deine alte Config trotzdem geparst wird

Eine historische Altlast ist leicht zu übersehen: Frühe Builds von hermes config set speicherten ein reines JSON-Array-Argument als String, eine Config kann also Folgendes enthalten:

platform_toolsets:
  cli: '["browser", "terminal"]'    # a string, not a list

Die Laufzeit, hermes doctor und hermes plugins enable lesen diesen Abschnitt jetzt alle über einen Parser, sie sind sich also einig darüber, was du konfiguriert hast. Wenn ein einzelner Reader seinen eigenen Kompatibilitäts-Shim mitbringt, sehen die anderen beiden am Ende ein anderes Setup.

Wann du es laufen lassen solltest

Kurzfassung: nach einem Rechnerwechsel, dem Deinstallieren eines Plugins, dem Umbenennen eines Toolsets oder einem Upgrade von einem älteren Build.

hermes config check      # gespeicherte Auswahlen melden, die sich nicht mehr auflösen lassen
hermes config migrate    # mit demselben Resolver migrieren und reparieren
hermes tools             # Toolsets interaktiv neu auswählen
hermes plugins enable platforms/telegram   # eine von der Prüfung markierte Plattform aktivieren

Drei praktische Einschätzungen:

1. Frage dich bei „disabled while its required credentials are configured“, ob du es absichtlich deaktiviert hast. Die Prüfung selbst erlaubt das — ein konfiguriertes Credential ist nur ein Grund, es zu erwähnen. Wenn du es live willst, führe das vorgeschlagene hermes plugins enable aus.
2. Lösche einen Toolset-Namen, der sich nicht mehr auflösen lässt, nicht sofort. Prüfe, ob er zu einem deinstallierten Plugin gehörte; wenn du diese Fähigkeit weiterhin willst, installiere das Plugin neu. Den Namen zu löschen bedeutet nur, ihn später neu zu konfigurieren.
3. Ein sauberes config check ist keine perfekte Config. Es beurteilt nur, ob gespeicherte Auswahlen von der Laufzeit berücksichtigt werden können — nicht, ob dein Modell eine gute Wahl oder deine Keys aktuell sind. Für diese Art von Frage nutzt du hermes doctor.

Und diese Prüfung wird erst nützlich, wenn die Config selbst aufgeräumt bleibt: Der MCP-Konfigurationsguide und der Beitrag zum Plugin-Katalog sagen dasselbe — nach dem Hinzufügen und Entfernen von Plugins oder MCP-Servern muss die Config aufgeräumt werden. Dieser Patch holt diesen Schritt aus deinem Gedächtnis in einen Befehl.

Die Kurzfassung

• hermes config check meldet jetzt gespeicherte platform_toolsets-Namen, die sich nicht mehr auflösen lassen, sowie Plattformen, die deaktiviert sind, während ihre erforderlichen Zugangsdaten konfiguriert sind.
• Es teilt sich einen Resolver mit hermes config migrate, womit selbstwidersprüchliche Warnungen wie der Vorschlag 'hermes-teams' für 'hermes-teams' enden.
• Das Urteil deckt sich mit der Laufzeit: Ein deaktivierter MCP-Server ist bekannt, known_plugin_toolsets ist kein Beleg, ein als Nicht-Liste gesetztes plugins.disabled lügt nicht mehr, optionale Env-Variablen zählen nie als erforderlich.
• Die Plugin-Erkennung läuft nur bei Bedarf, eine saubere Config zahlt also nichts; ein fehlerhaftes mcp_servers lässt den Befehl nicht mehr abstürzen.
• Die Prüfung des Top-Level-Schlüssels toolsets wurde entfernt, weil die CLI ihn nie liest (nur Legacy-Kanban).
• Führe sie nach einem Rechnerwechsel, dem Entfernen von Plugins oder einem Upgrade aus und repariere dann mit hermes config migrate und hermes tools.

Die vollständige Nutzung steht unter hermes config und hermes plugins.