Vous tapez /yolo dans Hermes sur Telegram et il répond que le mode YOLO est actif et que chaque commande sera approuvée automatiquement. Vous lui confiez une chaîne d’étapes d’automatisation en supposant qu’il va simplement s’exécuter au lieu de demander. Pendant la nuit, vous mettez Hermes à niveau, le gateway redémarre, et le lendemain matin vous envoyez une nouvelle instruction — et voilà qu’il se met à demander, commande après commande, s’il peut continuer. Vous fouillez la config : YOLO n’était donc pas actif ? La réponse pique un peu : il a été désactivé sans que vous le voyiez, et rien ne l’a signalé. Le correctif crée aussi un risque dans la direction opposée, donc les deux méritent d’être énoncés.

Le problème : l’interrupteur n’existait qu’en mémoire

Sur une plateforme de messagerie, /yolo ne basculait rien de plus qu’un ensemble en mémoire dans tools.approval. Ce qui voulait dire :

• redémarrer le gateway (hermes update, un crash, systemd qui le relance, une réouverture du Desktop) → la mémoire se vide → ce chat revient silencieusement aux approbations manuelles ;
• rien dans l’interface ne dit « votre YOLO a disparu », donc vous continuez à croire qu’il contourne les invites.

Deux choses se produisent alors en même temps. Vous pensez qu’il s’exécute tout seul alors qu’il attend votre approbation à chaque étape, et si votre automatisation dépend de « aucune confirmation humaine », elle se bloque jusqu’à l’expiration. La formulation officielle du rapport est sans détour : l’utilisateur croyait encore que YOLO était actif.

Maintenant : enregistré avec la session — et uniquement avec la session

La nouvelle implémentation place le drapeau sur la propre entrée de routage du chat (SessionEntry.yolo, persistée dans gateway_routing à côté de l’override /model). Les règles méritent d’être lues une par une, parce qu’elles décident quelle situation vous surprend :

• /yolo écrit la copie persistée avant de basculer le drapeau en direct, et matérialise l’entrée quand vous l’activez sur un premier message.
• Chaque tour réarme le drapeau en direct depuis l’entrée qu’il a déjà résolue — donc le tout premier tour après un redémarrage restaure l’état, au lieu d’attendre que vous tapiez /yolo de nouveau.
• Le drapeau est transporté à travers le compression-tip et les repoints de liaison (switch_session).
• L’entonnoir de sécurité des frontières de conversation efface la copie persistée en même temps que celle en mémoire : /new, /resume, /branch et la réinitialisation automatique. L’intention est explicite — un redémarrage ne doit jamais ressusciter un bypass que vous avez déjà abandonné.

La doc énonce maintenant clairement la portée : /yolo ne s’applique qu’à la session dans laquelle il a été tapé ; il est enregistré avec la session, donc il survit à un redémarrage — un chat de messagerie le conserve à travers les redémarrages du gateway, et le TUI et l’application Desktop le conservent quand vous rouvrez ou reprenez la session. Sur une plateforme de messagerie, /new et /resume démarrent la conversation suivante avec les approbations réactivées.

Vérifier l’état de votre session est simple :

# état YOLO de la session courante (et s'il a été persisté)
hermes status

# le désactiver ET supprimer la copie persistée : démarrez une nouvelle conversation
/new

Tant qu’on y est, une affirmation largement répétée mérite d’être corrigée : la doc disait « /yolo définit la variable d’environnement HERMES_YOLO_MODE ». Ce n’a jamais été le cas. Ce sont trois chemins d’activation indépendants : le flag CLI hermes --yolo (ou hermes chat --yolo), le basculement /yolo en session, et la variable d’environnement HERMES_YOLO_MODE=1. Les deux premiers sont limités à la session, la troisième au processus — ne raisonnez pas sur eux comme s’il s’agissait de la même chose.

Les deux directions peuvent mordre

Direction un : vous croyez qu’il est actif et il est inactif. C’est le scénario d’ouverture, et il est corrigé.

Direction deux : vous croyez qu’il est inactif et il est actif. C’est le nouveau risque qu’introduit le correctif — un bypass qui survit désormais à un redémarrage. Deux défenses existantes comptent ici, alors utilisez-les :

• Les rappels visuels ne disparaissent pas. Tant que YOLO est actif, Hermes affiche deux indices persistants : une ligne de bannière rouge au démarrage de la session, ⚠ YOLO mode — all approval prompts bypassed (masquée quand YOLO est désactivé pour que la bannière par défaut reste propre), et un fragment ⚠ YOLO dans la barre de statut sur tous les paliers de largeur, mis à jour en direct quand vous basculez.
• Deux actions de frontière l’effacent toujours : /new (et son alias /reset) et /resume. La première est le bon geste quand vous n’en avez plus besoin, la seconde quand vous voulez revenir à une session propre.

Une chose de plus pour ne pas traiter YOLO comme un passe-partout : YOLO ne contourne que l’étape d’approbation des commandes dangereuses. Il ne contourne pas la blocklist stricte, et il ne contourne pas le garde de cycle de vie du gateway supervisé — redémarrer ou tuer le gateway depuis son propre processus est toujours refusé, et l’approbation utilisateur, YOLO et force=True n’y changent rien. La raison est pratique : cela tuerait l’outil même qui exécute la commande, ce qui déclenche une boucle superviseur/reprise automatique.

Quand l’utiliser, et quand l’abandonner

• Bon usage : une automatisation ponctuelle, conteneurisée et scriptée où vous voulez vraiment qu’elle agisse sans demander, et où vous savez déjà ce qu’elle va générer.
• Mauvais usage : l’exploration interactive, les commandes destructrices sur lesquelles vous avez un doute, et tout chat utilisé par plus d’une personne.
• Conseil général : /new quand vous avez terminé. Comme un redémarrage ne le ferme plus pour vous, le fermer vous-même est le seul filet de sécurité — et /new est la façon la moins oubliable de le faire.

Pour conclure

• /yolo ne changeait auparavant qu’un ensemble en mémoire, donc un redémarrage du gateway le faisait disparaître silencieusement pendant que vous croyiez encore qu’il était actif.
• Il vit désormais sur l’entrée de routage de la session (SessionEntry.yolo) et survit aux redémarrages, à la compression et aux repoints de session, y compris aux reprises du TUI/Desktop.
• /new, /resume, /branch et la réinitialisation automatique effacent à la fois les copies persistée et en mémoire — un redémarrage ne peut pas ressusciter un bypass que vous avez abandonné.
• YOLO suspend uniquement les invites d’approbation ; la blocklist stricte et le garde de cycle de vie du gateway supervisé ne sont pas affectés.
• L’ancienne ligne de doc selon laquelle /yolo définit HERMES_YOLO_MODE était tout simplement fausse — cette variable d’environnement est un chemin d’activation distinct.

Nous avons écrit plusieurs fois sur les approbations, et ces articles s’accordent bien : ce en quoi les sept modes YOLO diffèrent réellement, la configuration des approbations pour les exécutions sans surveillance, et le test à blanc de vos règles d’approbation — ce dernier est celui à lire quand vous avez changé des règles d’approbation et que vous n’êtes pas sûr qu’elles bloqueront quelque chose dont vous avez besoin.