Escribes /yolo en Hermes por Telegram y te responde que el modo YOLO está activado y que todos los comandos se aprobarán automáticamente. Le encargas una cadena de pasos de automatización dando por hecho que seguirá adelante en lugar de preguntar. Esa noche actualizas Hermes, el gateway se reinicia, y a la mañana siguiente envías otra instrucción — y ahora empieza a preguntar, comando a comando, si puede continuar. Te pones a rebuscar en la configuración: ¿no estaba activado YOLO? La respuesta escuece un poco: se desactivó mientras no mirabas, y nada lo dijo. El arreglo también crea riesgo en la dirección opuesta, así que merece la pena explicar ambos.

El problema: el interruptor solo existía en memoria

En una plataforma de mensajería, /yolo antes no cambiaba más que un conjunto en memoria dentro de tools.approval. Lo cual significaba:

• reiniciar el gateway (hermes update, un crash, que systemd lo levante de nuevo, la reapertura del escritorio) → la memoria se limpia → ese chat vuelve en silencio a las aprobaciones manuales;
• nada en la interfaz dice «tu YOLO ha desaparecido», así que sigues creyendo que está saltando los prompts.

Entonces ocurren dos cosas a la vez. Crees que está ejecutando por su cuenta mientras espera a que apruebes cada paso, y si tu automatización depende de «ninguna confirmación humana», se queda atascada ahí hasta que expira. La redacción oficial del informe es directa: el usuario seguía creyendo que YOLO estaba activado.

Ahora: se guarda con la sesión — y solo con la sesión

La nueva implementación pone el flag en la propia entrada de enrutado del chat (SessionEntry.yolo, persistido en gateway_routing junto al override de /model). Merece la pena leer las reglas una a una, porque deciden en qué situación te sorprenderá:

• /yolo escribe la copia persistida antes de cambiar el flag en vivo, y materializa la entrada cuando lo activas en un primer mensaje.
• Cada turno rearma el flag en vivo desde la entrada que ya había resuelto — así que el primer turno tras un reinicio restaura el estado, en lugar de esperar a que escribas /yolo otra vez.
• El flag se conserva entre el compression-tip y los repoints de binding (switch_session).
• El embudo de seguridad de los límites de conversación borra la copia persistida junto con la de memoria: /new, /resume, /branch y el auto-reset. La intención es explícita — un reinicio nunca debe revivir un bypass que ya habías quitado.

La documentación ahora deja claro el alcance: /yolo solo se aplica a la sesión en la que se escribió; se guarda con la sesión, así que sobrevive a un reinicio — un chat de mensajería lo conserva a través de los reinicios del gateway, y la TUI y la app de escritorio lo conservan cuando reabres o reanudas la sesión. En una plataforma de mensajería, /new y /resume empiezan la siguiente conversación con las aprobaciones de nuevo activadas.

Comprobar el estado de tu sesión es directo:

# estado de YOLO de la sesión actual (y si se persistió)
hermes status

# desactívalo Y descarta la copia persistida: empieza una conversación nueva
/new

Ya que estamos, hay que corregir una afirmación muy repetida: la documentación decía que «/yolo define la variable de entorno HERMES_YOLO_MODE». Nunca lo hizo. Son tres vías de activación independientes: el flag de CLI hermes --yolo (o hermes chat --yolo), el conmutador /yolo dentro de la sesión, y la variable de entorno HERMES_YOLO_MODE=1. Las dos primeras tienen alcance de sesión; la tercera, de proceso — no razones sobre ellas como si fueran lo mismo.

Las dos direcciones pueden morder

Dirección uno: crees que está activado y está desactivado. Ese es el escenario del principio, y está arreglado.

Dirección dos: crees que está desactivado y está activado. Este es el nuevo riesgo que introduce el arreglo — un bypass que ahora sobrevive a un reinicio. Aquí importan dos defensas que ya existen, así que úsalas:

• Los recordatorios visuales no desaparecen. Mientras YOLO está activo, Hermes muestra dos señales persistentes: una línea de banner roja al inicio de la sesión, ⚠ YOLO mode — all approval prompts bypassed (oculta cuando YOLO está desactivado para que el banner por defecto quede limpio), y un fragmento ⚠ YOLO en la barra de estado en todos los anchos, actualizado en vivo mientras conmutas.
• Dos acciones de límite siempre lo borran: /new (y su alias /reset) y /resume. La primera es lo correcto cuando ya no lo necesitas; la segunda, cuando quieres volver a una sesión limpia.

Una cosa más para que no trates YOLO como una llave maestra: YOLO solo salta el paso de aprobación de comandos peligrosos. No salta la blocklist de línea dura, y no salta la guarda de ciclo de vida del gateway supervisado — reiniciar o matar el gateway desde dentro de su propio proceso sigue estando denegado, y ni la aprobación del usuario, ni YOLO, ni force=True sirven de nada. La razón es práctica: hacerlo mataría a la propia herramienta que ejecuta el comando, lo que desencadena un bucle de supervisor/auto-resume.

Cuándo usarlo y cuándo quitarlo

• Encaja bien: automatización puntual, containerizada y con scripts, donde de verdad quieres que actúe sin preguntar y ya sabes qué va a generar.
• Encaja mal: exploración interactiva, comandos destructivos sobre los que tienes dudas y cualquier chat que use más de una persona.
• Consejo general: /new cuando termines. Como un reinicio ya no te lo cierra, cerrarlo tú mismo es la única red de seguridad — y /new es la forma menos olvidable de hacerlo.

Para terminar

• /yolo antes solo cambiaba un conjunto en memoria, así que un reinicio del gateway lo descartaba en silencio mientras tú seguías creyendo que estaba activado.
• Ahora vive en la entrada de enrutado de la sesión (SessionEntry.yolo) y sobrevive a reinicios, compactaciones y repoints de sesión, incluidos los resume de TUI/escritorio.
• /new, /resume, /branch y el auto-reset borran ambas copias, la persistida y la de memoria — un reinicio no puede revivir un bypass que quitaste.
• YOLO solo suspende los prompts de aprobación; la blocklist de línea dura y la guarda de ciclo de vida del gateway supervisado no se ven afectadas.
• La antigua línea de la documentación que decía que /yolo define HERMES_YOLO_MODE era simplemente errónea — esa variable de entorno es una vía de activación aparte.

Hemos escrito sobre las aprobaciones varias veces, y estos encajan bien: en qué se diferencian realmente los siete modos de YOLO, configuración de aprobaciones para ejecuciones desatendidas, y probar en seco tus reglas de aprobación — este último es el que hay que leer cuando has cambiado las reglas de aprobación y no estás seguro de si bloquearán algo que necesitas.