Um 3 Uhr morgens trifft dein Memory-Watchdog-Webhook-Job auf einen „gefährlichen Befehl“ – und hängt dann volle 300 Sekunden, weil die Genehmigungsaufforderung an niemanden geht, der sie beantworten könnte. Schlimmer noch: Diese verklemmte Session hielt später einen hermes update-Gateway-Drain über fünf Minuten auf. Das ist der Vorfall (Issue #37284) hinter einem Fix, der am 30. August gemergt wurde (PR #98558): Hermes erhält einen approvals.unattended_mode-Konfigurationsschlüssel, Standard deny, sodass Sessions auf unbeaufsichtigten programmatischen Plattformen (webhook, msgraph_webhook, api_server) bei einem gefährlichen Befehl sofort fehlschlagen, statt auf eine Genehmigung zu warten, die niemand erteilen kann. Die Änderung liegt derzeit auf main, noch in keinem Release.

Das Problem: Genehmigungen an jemanden, den es nicht gibt

Hermes’ Genehmigungssystem fängt gefährliche Befehle ab (denk an rm -rf, DROP DATABASE) und zeigt eine /approve-Aufforderung, die auf einen Menschen wartet. Auf Chat-Plattformen funktioniert das gut – irgendjemand sitzt vor dem Bildschirm. Aber webhook, msgraph_webhook und api_server binden HERMES_SESSION_PLATFORM genauso wie Chat-Gateways, also hielt die Genehmigungslogik sie für interaktive Gateway-Sessions – nur haben diese Adapter keinen Kanal, um eine Genehmigung zu senden oder eine Antwort zu empfangen. Ergebnis: Die Session blockierte 60–300 Sekunden und schlug danach ohnehin fehl. Zeit verschwendet – und niemand hatte je die Chance, Ja zu sagen.

Der Fix: unattended_mode, standardmäßig deny

Der Fix dreht sich um einen neuen Konfigurationsschlüssel, der die bestehende cron_mode-Semantik spiegelt:

approvals:
  mode: smart              # smart | manual | off
  timeout: 300
  cron_mode: deny          # cron jobs hitting a dangerous command: deny | approve
  single_query_mode: deny  # hermes chat -q one-shot sessions: deny | approve
  unattended_mode: deny    # webhook/API unattended sessions: deny | approve (new)

• deny (Standard): Eine unbeaufsichtigte Session, die auf einen gefährlichen Befehl trifft, wird sofort abgelehnt (gemessen: 0,04 s) – mit einer handlungsorientierten Meldung: „Diese Session läuft auf einer unbeaufsichtigten Plattform (webhook) ohne anwesenden Nutzer, der sie genehmigen könnte; such einen alternativen Ansatz, der diese Aktion vermeidet; um gekennzeichnete Aktionen zuzulassen, setze approvals.unattended_mode: approve in config.yaml.“
• approve: Opt-in für die automatische Genehmigung aller gefährlichen Befehle auf unbeaufsichtigten Plattformen (das alte Verhalten aus PR #37317, jetzt Opt-in statt Standard).

Die Änderung deckt alle drei Guard-Pfade ab: _run_approval_gate (reguläre Befehle), check_all_command_guards (Tirith-Sicherheitschecks) und check_execute_code_guard (das execute_code-Tool) – und schließt damit auch das #87509-Loch, bei dem execute_code über api_server eine Einmal-Gateway-Genehmigung auslöste, die niemand beantworten konnte.

So konfigurierst du es

Beim Standard bleiben (empfohlen): nichts zu tun, es greift nach dem Upgrade. Um ein bestimmtes unbeaufsichtigtes Szenario zuzulassen (sagen wir: ein vollständig vertrauenswürdiger privater Webhook):

# Via the CLI (equivalent to editing config.yaml)
hermes config set approvals.unattended_mode approve

# Or edit ~/.hermes/config.yaml directly
approvals:
  unattended_mode: approve

Bonus: Der gleiche Fix brachte auch single_query_mode mit – hermes chat -q "..."-Sessions, die eine Runde laufen und sich beenden, ohne dass ein Nutzer auf Antworten wartet, hingen früher genauso und greifen jetzt standardmäßig auf sofortiges deny zurück. Für das vollständige Bild der Genehmigungsrichtlinie sieh dir unseren Smart-Approvals-Setup-Guide und den Guide gegen Genehmigungs-Müdigkeit an.

Was das für deine Automation bedeutet

Wenn du Automation über Webhook oder API betreibst, ist der Effekt: Fehlschläge ändern sich von „5-Minuten-Timeout“ zu „sofortige Ablehnung mit klarer Begründung“. Der Agent bekommt die Ablehnung sofort und kann einen anderen Weg versuchen, statt zu hängen. Eine Verhaltensänderung sei erwähnt: Das alte implizite Verhalten „gefährliche Befehle werden in diesen Sessions automatisch genehmigt“ ist weg – wenn du dich darauf verlassen hast, setze approvals.unattended_mode: approve explizit. Die Genehmigungsstrategie für Cron-Jobs behandelt unser Cron-Automation-Guide, Webhook-Setup der Business-Notifications-Guide.

Wann du es nutzen kannst

PR #98558 wurde am 30. August gemergt und ist nicht in v0.20.6 (getaggt am 27. August). Ziehe das aktuelle main, um es jetzt auszuprobieren, oder warte auf das nächste Release. Wenn du je ein Webhook-Job hattest, das still auf einer Genehmigung hing, lohnt sich das Upgrade allein dafür.