Du tippst /yolo in Hermes auf Telegram, und es antwortet, dass der YOLO-Modus an ist und jeder Befehl automatisch genehmigt wird. Du übergibst ihm eine Kette von Automatisierungsschritten in der Annahme, dass es einfach weitermacht, statt zu fragen. Über Nacht aktualisierst du Hermes, das Gateway startet neu, und am nächsten Morgen schickst du eine weitere Anweisung — und jetzt fängt es an, Befehl für Befehl zu fragen, ob es fortfahren darf. Du gräbst die Config durch: War YOLO nicht an? Die Antwort schmerzt ein wenig: Es wurde ausgeschaltet, während du nicht hingeschaut hast, und nichts hat es gesagt. Der Fix erzeugt außerdem Risiko in die entgegengesetzte Richtung, also lohnt es sich, beide auszubuchstabieren.

Das Problem: der Schalter existierte nur im Speicher

Auf einer Messaging-Plattform kippte /yolo früher nichts weiter als ein In-Memory-Set in tools.approval. Das bedeutete:

• starte das Gateway neu (hermes update, ein Absturz, systemd bringt es zurück, ein Desktop-Reopen) → der Speicher wird geleert → dieser Chat fällt still auf manuelle Approvals zurück;
• nichts in der UI sagt „dein YOLO ist weg“, also glaubst du weiter, es umgehe Prompts.

Dann passieren zwei Dinge gleichzeitig. Du denkst, es führt von selbst aus, während es darauf wartet, dass du jeden Schritt genehmigst, und wenn deine Automatisierung auf „keine menschliche Bestätigung“ angewiesen ist, hängt sie dort fest, bis sie in ein Timeout läuft. Die offizielle Formulierung des Berichts ist unverblümt: der Nutzer glaubte weiterhin, YOLO sei an.

Jetzt: mit der Session gespeichert — und nur mit der Session

Die neue Implementierung legt das Flag auf den eigenen Routing-Eintrag des Chats (SessionEntry.yolo, persistiert in gateway_routing neben dem /model-Override). Die Regeln lohnt es, einzeln zu lesen, denn sie entscheiden, welche Situation dich überrascht:

• /yolo schreibt die persistierte Kopie, bevor es das Live-Flag umlegt, und materialisiert den Eintrag, wenn du bei einer ersten Nachricht einschaltest.
• Jeder Turn lädt das Live-Flag aus dem Eintrag neu, den er bereits aufgelöst hat — also stellt schon der allererste Turn nach einem Neustart den Zustand wieder her, statt darauf zu warten, dass du erneut /yolo tippst.
• Das Flag wird über Compression-Tip und Binding-Repoints (switch_session) hinweg mitgeführt.
• Der Sicherheitstrichter an der Konversationsgrenze löscht die persistierte Kopie zusammen mit der In-Memory-Kopie: /new, /resume, /branch und Auto-Reset. Die Absicht ist explizit — ein Neustart darf nie ein Bypass wiederbeleben, das du bereits verworfen hast.

Die Docs nennen den Geltungsbereich jetzt klar: /yolo gilt nur für die Session, in der es getippt wurde; es wird mit der Session gespeichert, also übersteht es einen Neustart — ein Messaging-Chat behält es über Gateway-Neustarts hinweg, und TUI und Desktop-App behalten es, wenn du die Session neu öffnest oder fortsetzt. Auf einer Messaging-Plattform starten /new und /resume die nächste Konversation mit wieder eingeschalteten Approvals.

Den Zustand deiner Session zu prüfen ist unkompliziert:

# YOLO-Zustand der aktuellen Session (und ob er persistiert wurde)
hermes status

# ausschalten UND die persistierte Kopie verwerfen: eine frische Konversation starten
/new

Wo wir schon hier sind: Eine weit verbreitete Behauptung muss korrigiert werden: Die Docs sagten früher, „/yolo setzt die Umgebungsvariable HERMES_YOLO_MODE“. Das tat es nie. Das sind drei unabhängige Aktivierungspfade: das CLI-Flag hermes --yolo (oder hermes chat --yolo), der In-Session-Umschalter /yolo und die Umgebungsvariable HERMES_YOLO_MODE=1. Die ersten beiden sind Session-scoped, die dritte ist Prozess-scoped — denke nicht über sie nach, als wären sie dasselbe.

Beide Richtungen können beißen

Richtung eins: Du denkst, es ist an, und es ist aus. Das ist das Eröffnungsszenario, und es ist behoben.

Richtung zwei: Du denkst, es ist aus, und es ist an. Das ist das neue Risiko, das der Fix einführt — ein Bypass, das jetzt einen Neustart überlebt. Zwei bestehende Verteidigungen sind hier wichtig, also nutze sie:

• Die visuellen Erinnerungen verschwinden nicht. Solange YOLO aktiv ist, zeigt Hermes zwei dauerhafte Hinweise: eine rote Bannerzeile beim Session-Start, ⚠ YOLO mode — all approval prompts bypassed (ausgeblendet, wenn YOLO aus ist, damit das Standard-Banner sauber bleibt), und ein ⚠ YOLO-Fragment in der Statusleiste über alle Breitenstufen, live aktualisiert beim Umschalten.
• Zwei Grenzaktionen löschen es immer: /new (und sein Alias /reset) und /resume. Ersteres ist der richtige Schritt, wenn du es nicht mehr brauchst, letzteres, wenn du zu einer sauberen Session zurückwillst.

Noch eine Sache, damit du YOLO nicht als Generalschlüssel behandelst: YOLO umgeht nur den Genehmigungsschritt für gefährliche Befehle. Es umgeht nicht die Hardline-Blocklist und nicht den Lifecycle-Guard des überwachten Gateways — das Gateway aus seinem eigenen Prozess heraus neu zu starten oder zu killen wird weiterhin verweigert, und Nutzer-Approval, YOLO und force=True helfen alle nicht. Der Grund ist praktisch: Das würde genau das Tool killen, das den Befehl ausführt, was eine Supervisor-/Auto-Resume-Schleife anstößt.

Wann du es nutzen solltest und wann du es fallen lässt

• Guter Fit: einmalige, containerisierte, geskriptete Automatisierung, bei der du wirklich willst, dass sie ohne Fragen handelt, und du schon weißt, was sie erzeugen wird.
• Schlechter Fit: interaktive Erkundung, destruktive Befehle, bei denen du unsicher bist, und jeder Chat, den mehr als eine Person nutzt.
• Allgemeiner Rat: /new, wenn du fertig bist. Da ein Neustart es nicht mehr für dich schließt, ist es selbst zu schließen der einzige Backstop — und /new ist der am wenigsten vergessbare Weg.

Die Kurzfassung

• /yolo änderte früher nur ein In-Memory-Set, also ließ ein Gateway-Neustart es still fallen, während du weiter glaubtest, es sei an.
• Es lebt jetzt am Routing-Eintrag der Session (SessionEntry.yolo) und übersteht Neustarts, Compression und Session-Repoints, einschließlich TUI/Desktop-Resumes.
• /new, /resume, /branch und Auto-Reset löschen beide Kopien, die persistierte und die im Speicher — ein Neustart kann kein von dir verworfenes Bypass wiederbeleben.
• YOLO setzt nur Genehmigungs-Prompts aus; die Hardline-Blocklist und der Lifecycle-Guard des überwachten Gateways bleiben unberührt.
• Die alte Doc-Zeile, dass /yolo HERMES_YOLO_MODE setzt, war schlicht falsch — diese Umgebungsvariable ist ein separater Aktivierungspfad.

Wir haben schon mehrfach über Approvals geschrieben, und diese passen gut dazu: worin sich die sieben YOLO-Modi tatsächlich unterscheiden, Approval-Konfiguration für unbeaufsichtigte Läufe und das Dry-Running deiner Approval-Regeln — der letzte ist der, den du lesen solltest, wenn du Approval-Regeln geändert hast und unsicher bist, ob sie etwas blockieren, das du brauchst.