Un día vas a buscar una session de depuración de hace tres meses y /resume simplemente no la tiene. Entonces lo recuerdas: sessions.auto_prune estaba activado y todo lo que pasaba de 90 días se borraba en algún arranque, sin aviso y sin confirmación. Eso acaba de cambiar. La limpieza automática vuelve a ser opcional, y solo te interrumpe cuando el disco de verdad se está quedando sin espacio.

Qué cambió: nada se borra por defecto

El cambio es tajante: sessions.auto_prune vuelve a valer false por defecto. Los tres estados de instalación se comportan así:

Tu configuración	Antes	Ahora
Nunca configuraste sessions.auto_prune	se limpiaba a los 90 días, en silencio	no se limpia; se pregunta una vez cuando el disco está bajo
Configuraste auto_prune: true	se limpiaba	se limpia, sin cambios
Configuraste auto_prune: false	se conservaba	se conserva, nunca se pregunta

Fíjate en la segunda fila: si lo activaste a propósito, nada de tu configuración ha cambiado. Lo que cambió es el grupo grande de gente que nunca opinó — su historial ya no se trata como espacio libre por defecto.

Cuándo te avisa

La lógica vive en un módulo nuevo, hermes_cli/prune_advisor.py, y la ruta crítica es deliberadamente barata: un os.stat, un shutil.disk_usage y una lectura pequeña de YAML. Solo se dispara cuando se cumplen todas estas condiciones:

• el disco realmente está bajo: menos de 2 GiB libres, o menos del 10% libre y también menos de 20 GiB de margen (un disco de 4 TB al 10% libre está bien, y esa cláusula existe precisamente para ese caso);
• tu config.yaml no tiene la clave sessions.auto_prune;
• no hay un snooze activo.

Solo entonces abre la base de datos en modo solo lectura para estimar cuánto liberaría de verdad una limpieza: las sessions terminadas que pasan de retention_days, escaladas por su proporción de mensajes. Esa estimación aparece en la propia pregunta, incluido el caso incómodo: “limpiar no va a arreglar este disco”, ya sea porque nada es lo bastante antiguo o porque se puede recuperar muy poco como para sacar al disco de la banda baja.

Una pregunta, cuatro superficies

• CLI clásico: una pregunta y / n / Enter (más tarde) al arrancar, solo en TTY, junto a la oferta de la imagen de sandbox.
• TUI y Desktop: una notificación fija con clave sessions.auto_prune, por profile y por proceso. La estimación de la base de datos se calcula fuera del hilo principal, así que la interfaz nunca espera por ella.
• Gateway de mensajería: la pregunta se publica en el canal principal del profile servido. Un detalle que importa: el snooze de “más tarde” solo se registra después de una publicación entregada, así que un gateway sin canal principal no puede tragarse en silencio la pregunta que el CLI está a punto de hacer.
• Comando slash: /autoprune on | off | later | status, con el mismo texto en todas las superficies porque pasa por un único ejecutor del registro. El límite de 50 comandos slash de Slack está lleno, así que allí es /hermes autoprune.

Qué hace realmente cada respuesta

• on escribe sessions.auto_prune: true y limpia las sessions terminadas e inactivas que pasan de retention_days (90 por defecto). Las sessions abiertas, fijadas o a mitad de turno nunca se tocan.
• off escribe false, lo conserva todo y retira la pregunta para siempre.
• later pospone 7 días y vuelve a preguntar.

Para ver en qué situación estás:

hermes config get sessions.auto_prune
/autoprune status

¿Sigues justo de disco? Limpia por capas

La limpieza automática es una capa. Cuando de verdad necesites espacio, ve de lo menos a lo más destructivo:

hermes sessions optimize          # fusiona segmentos FTS5 + VACUUM, sin cambiar datos
hermes sessions optimize-storage  # migra el índice de búsqueda al formato compacto
hermes sessions archive           # ocultación masiva y reversible, sin borrar
hermes sessions prune             # borrado real, filtrable por ventana / origen / título

optimize y optimize-storage reconstruyen índices y recuperan fragmentación sin tocar el historial, así que ejecútalos primero. archive oculta sessions de la lista sin borrarlas. prune es lo de verdad — comprueba si session_search todavía necesita ese historial antes de lanzarlo.

Una forma práctica de elegir

La pregunta de fondo es sencilla: ¿cuánto vale tu historial frente a tu disco?

• Disco crónicamente justo (un VPS pequeño, un contenedor con unas pocas decenas de GB) y casi nunca miras atrás: /autoprune on te da menos trabajo.
• Dependes de session_search o mantienes rastros de auditoría: deja el valor por defecto (conservar, sin preguntar) y ejecuta optimize de vez en cuando.
• Si dudas: no escribas nada. El valor por defecto es el estado conservador.

Si state.db ya está dando problemas — por ejemplo, Hermes informa que otro proceso retiene un WAL antiguo — limpiar no es la solución; empieza por el recorrido de recuperación del almacén de sessions. Para entender cómo funcionan los límites de session, lee la guía de límites de session, y para los flags exactos, la referencia de hermes sessions.

Una nota de estado que conviene decir sin rodeos: esto se fusionó en main el 2026-10-16, después de que v0.22.2 saliera el 10-15, así que todavía no está en ninguna versión publicada — llega en la build que descargue tu próximo hermes update.