Un jour, vous cherchez une session de débogage d’il y a trois mois et /resume ne la trouve tout simplement pas. Puis vous vous souvenez : sessions.auto_prune était actif, et tout ce qui dépassait 90 jours a été supprimé à un démarrage — sans avertissement, sans confirmation. Cela vient de changer. L’élagage automatique est de nouveau une option à activer, et il ne vous interrompt que lorsque le disque est réellement en train de saturer.

Ce qui change : rien n’est supprimé par défaut

Le changement est net : sessions.auto_prune repasse par défaut à false. Les trois états d’installation se comportent ainsi :

Votre configuration	Avant	Maintenant
sessions.auto_prune jamais défini	élagué à 90 jours, en silence	non élagué ; question posée une fois si le disque est bas
auto_prune: true défini	élagué	élagué, inchangé
auto_prune: false défini	conservé	conservé, jamais de question

Notez la deuxième ligne : si vous l’avez activé volontairement, rien n’a changé pour vous. Ce qui a changé, c’est le vaste groupe qui n’avait jamais exprimé d’avis — son historique n’est plus considéré comme de l’espace libre par défaut.

Quand il prend la parole

La logique vit dans un nouveau module, hermes_cli/prune_advisor.py, et le chemin chaud est volontairement peu coûteux : un os.stat, un shutil.disk_usage et une petite lecture YAML. Il ne se déclenche que si tout ce qui suit est vrai :

• le disque est vraiment bas : moins de 2 Gio libres, ou moins de 10 % libres avec en plus moins de 20 Gio de marge (un disque de 4 To à 10 % libres va très bien, et cette clause existe exactement pour ce cas) ;
• votre config.yaml n’a aucune clé sessions.auto_prune ;
• aucune mise en sourdine n’est active.

C’est seulement alors qu’il ouvre la base en lecture seule pour estimer ce qu’un élagage libérerait réellement — les sessions terminées au-delà de retention_days, pondérées par leur part de messages. Cette estimation entre dans la question elle-même, y compris dans le cas embarrassant : « l’élagage ne réglera pas ce disque », soit parce que rien n’est assez ancien, soit parce que trop peu est récupérable pour sortir le disque de la zone basse.

Une seule question, quatre surfaces

• CLI classique : une question y / n / Entrée (plus tard) au démarrage, en TTY uniquement, à côté de la proposition d’image sandbox.
• TUI et Desktop : une notification persistante avec la clé sessions.auto_prune, par profil et par processus. L’estimation de la base s’exécute hors thread pour que l’interface ne l’attende jamais.
• Gateway de messagerie : la question est publiée dans le canal principal du profil servi. Un détail qui compte — la mise en sourdine « plus tard » n’est enregistrée qu’après une publication effectivement délivrée, si bien qu’un gateway sans canal principal ne peut pas avaler en silence la question que le CLI s’apprête à poser.
• Commande slash : /autoprune on | off | later | status, texte identique sur toutes les surfaces puisqu’il passe par un exécuteur de registre unique. La limite de 50 commandes slash de Slack étant atteinte, c’est /hermes autoprune là-bas.

Ce que fait réellement chaque réponse

• on écrit sessions.auto_prune: true et élague les sessions terminées et inactives au-delà de retention_days (90 par défaut). Les sessions ouvertes, épinglées ou en cours de tour ne sont jamais touchées.
• off écrit false, conserve tout et retire la question pour de bon.
• later met en sourdine pendant 7 jours puis repose la question.

Pour voir où vous en êtes :

hermes config get sessions.auto_prune
/autoprune status

Toujours à l’étroit ? Nettoyez par couches

L’élagage automatique n’est qu’une couche. Quand vous avez vraiment besoin d’espace, allez du moins au plus destructif :

hermes sessions optimize          # fusionne les segments FTS5 + VACUUM, aucune donnée modifiée
hermes sessions optimize-storage  # migre l'index de recherche vers la disposition compacte
hermes sessions archive           # masquage doux en masse, aucune suppression
hermes sessions prune             # suppression réelle, filtrable par fenêtre / source / titre

optimize et optimize-storage reconstruisent les index et récupèrent la fragmentation sans toucher à l’historique : commencez par ceux-là. archive cache des sessions de la liste sans les supprimer. prune est la vraie suppression — vérifiez si session_search a encore besoin de cet historique avant de la lancer.

Une manière pratique de choisir

La question sous-jacente est simple : que vaut votre historique face à votre disque ?

• Disque chroniquement plein (un petit VPS, un conteneur de quelques dizaines de Go) et vous ne regardez presque jamais en arrière : /autoprune on demande moins d’effort.
• Vous vous appuyez sur session_search, ou vous conservez des pistes d’audit : laissez la valeur par défaut (conservé, pas de question) et lancez optimize de temps en temps.
• Vous hésitez : n’écrivez rien. Le défaut est l’état prudent.

Si state.db dysfonctionne déjà — par exemple si Hermes signale qu’un autre processus détient un vieux WAL — l’élagage n’est pas la solution ; commencez par le guide de récupération du stockage de sessions. Pour comprendre le fonctionnement des frontières de session, lisez le guide des frontières de session, et pour les options exactes, la référence hermes sessions.

Une précision de statut qu’il vaut mieux dire clairement : ce changement a été fusionné dans main le 2026-10-16, après la sortie de la v0.22.2 le 10-15, il n’est donc dans aucune version publiée pour l’instant — il arrivera dans le build que votre prochain hermes update récupérera.