hermes approvals test: Frag das Approval-System, bevor du den Befehl ausführst

Du willst gerade einen Cleanup-Befehl in ein Script einbauen, das der Agent unbeaufsichtigt ausführen wird, und da ist eine Frage, die du durch Ansehen des Codes nicht beantworten kannst: lässt Hermes das durch? Raten heißt entweder ein Approval-Prompt mitten im Lauf, den niemand beantwortet, oder ein Befehl, der stillschweigend lief, obwohl du erwartet hast, dass er blockiert wird. v0.21.0 bringt dafür das naheliegende Werkzeug mit: hermes approvals test testet jeden Befehl per Dry Run gegen die echten Approval-Guards – die Hardline-Blocklist, deine approvals.deny-Regeln, die Erkennung gefährlicher Muster, die Allowlist, sogar den yolo/off-Bypass – und gibt das Urteil aus, ohne etwas auszuführen, jemanden zu fragen oder etwas zu speichern.
Das Urteil in drei Exit-Codes
hermes approvals test -- rm -rf /tmp/x
Das -- ist wichtig: Es stoppt die Flag-Parsung, damit die eigenen Flags des Befehls (wie -rf) nicht von hermes approvals selbst verschluckt werden. Die Ausgabe verrät dir das Urteil, welche Regel gegriffen hat und den normalisierten Befehlstrace – dieselbe Normalisierung, die auch das echte Gate anwendet. Scripts bekommen die Antwort als Exit-Code:
- 0 – allow
- 2 – ask-approval (würde nachfragen)
- 3 – deny (Hardline-Blocklist oder deine eigene Deny-Regel)
So kannst du es in einen Pre-Flight-Check einbauen: ein Deploy-Script, das sich weigert weiterzumachen, wenn ein Schritt blockiert würde, ein Cron-Job, der bevor er einen Befehl ausführt, den das Gate ohnehin stoppen würde, laut fehlschlägt, oder ein Audit-Durchlauf, der deine Scripts nach allem durchsucht, was in einem unbeaufsichtigten Kontext nachfragen würde.
Was es tatsächlich bewertet
Der Dry Run durchläuft dieselbe Entscheidungskette wie ein echter Befehl, einschließlich:
- die Hardline-Blocklist (bedingungslos verweigerte Befehle),
- deine
approvals.deny-fnmatch-Globs (das Schema findest du in unserem Smart-Approvals-Setup-Guide), - die Erkennung gefährlicher Muster (rekursive Löschungen, sudo, Festplatten-Schreibzugriffe, Bearbeitungen von Zugangsdaten, …),
- die Befehls-Allowlist (Befehle, die du bereits freigegeben hast),
- und den yolo/off-Bypass, falls du mit diesen Modi arbeitest (Yolo-Modi erklärt).
Zwei Flags verfeinern die Prüfung: --env-type sagt ihm, gegen welches Terminal-Backend bewertet werden soll (Standard local; isolierte Container-Backends wie Docker überspringen die Guards, ein Befehl, der im Container in Ordnung ist, kann also lokal nachfragen – gut zu wissen, bevor du das Script schreibst), und --json liefert maschinenlesbare Ausgabe.
Der Bonus-Befehl: hermes approvals suggest
hermes approvals test beantwortet die Frage „Was würde passieren?“; sein Geschwister hermes approvals suggest beantwortet „Was sollte ich erlauben?“ Es durchforstet deine vergangenen Approval-Entscheidungen aus der Session-Datenbank, ordnet die wiederkehrenden Muster nach Häufigkeit und schlägt command_allowlist-Einträge vor – geschrieben wird nichts, außer du wendest sie an:
hermes approvals suggest # nummerierte Vorschläge prüfen
hermes approvals suggest --apply 1,3,7 # die ausgewählten in config.yaml übernehmen
Optionen: --days (wie weit zurück gescannt wird, Standard 90), --min-count (Mindestanzahl an Approvals für ein Muster, Standard 2), --limit, --db (alternative Session-Datenbank), --json. Destruktive Klassen (rekursives Löschen, sudo, Festplatten-Schreibzugriffe, Bearbeitungen von Zugangsdaten, …) werden nie vorgeschlagen – das Tool schlägt nicht vor zu erlauben, wofür es existiert, um es zu gaten. Das passt gut zu unattended approvals für Cron-Kontexte.
Wann du das brauchst
Drei Momente stechen hervor. Vor dem Schreiben von Automatisierung: Prüfe jeden riskanten Schritt einmal und gib ihn entweder bewusst frei oder behandle den Prompt-Pfad. Auditing: hermes approvals test -- <cmd> auf einen verdächtigen Befehl sagt dir exakt, welche Regel ihn abfängt – keine Testläufe nötig. Das System lernen: Der normalisierte Trace zeigt dir, wie Hermes deinen Befehl tatsächlich sieht – der schnellste Weg zu verstehen, warum ein Shell-One-Liner, den du für harmlos hieltest, das Gate auslöst. v0.21.0 hat außerdem die gesamte Approval-Oberfläche gehärtet (destruktive Windows-Befehle lösen sie jetzt aus, geschützte Instruction-Dateien erfordern immer eine Approval) – das vollständige Bild liefern die Release-Notes unter /releases/v0-21-0/.