Eines Tages suchst du eine Debugging-Session von vor drei Monaten und /resume hat sie einfach nicht. Dann fällt es dir wieder ein: sessions.auto_prune war an, und alles jenseits von 90 Tagen wurde bei irgendeinem Start gelöscht – ohne Warnung, ohne Rückfrage. Das hat sich gerade geändert. Automatisches Aufräumen ist wieder Opt-in, und es unterbricht dich nur, wenn der Plattenplatz wirklich zur Neige geht.

Was sich geändert hat: standardmäßig wird nichts gelöscht

Die Änderung ist unmissverständlich: sessions.auto_prune steht wieder auf false. Die drei Installationszustände verhalten sich so:

Dein Setup	Vorher	Jetzt
sessions.auto_prune nie gesetzt	nach 90 Tagen stillschweigend aufgeräumt	nicht aufgeräumt; einmal gefragt, wenn der Platz knapp wird
auto_prune: true gesetzt	aufgeräumt	aufgeräumt, unverändert
auto_prune: false gesetzt	behalten	behalten, nie gefragt

Beachte die zweite Zeile: Wer es bewusst eingeschaltet hat, für den ändert sich nichts. Geändert hat sich etwas für die große Gruppe, die nie eine Meinung geäußert hat – deren Historie gilt nicht länger per Default als freier Speicher.

Wann es sich meldet

Die Logik steckt in einem neuen Modul, hermes_cli/prune_advisor.py, und der Hot Path ist bewusst billig: ein os.stat, ein shutil.disk_usage und ein kleines YAML-Read. Es greift nur, wenn all das zutrifft:

• Die Platte ist wirklich knapp: unter 2 GiB frei oder unter 10 % frei bei gleichzeitig unter 20 GiB Reserve (eine 4-TB-Platte mit 10 % frei ist in Ordnung, und genau für diesen Fall gibt es die zweite Bedingung);
• deine config.yaml hat keinen Schlüssel sessions.auto_prune;
• es ist kein Snooze aktiv.

Erst dann öffnet es die Datenbank read-only, um zu schätzen, was ein Prune tatsächlich freigeben würde – beendete Sessions jenseits von retention_days, skaliert nach ihrem Anteil an Nachrichten. Diese Schätzung fließt in die Frage selbst ein, inklusive des unangenehmen Falls: „Aufräumen rettet diese Platte nicht“, sei es, weil nichts alt genug ist oder weil zu wenig zurückzugewinnen wäre, um die Platte aus dem knappen Bereich zu holen.

Eine Frage, vier Oberflächen

• Klassische CLI: beim Start eine Frage mit j / n / Enter (später), nur im TTY, direkt neben dem Angebot für das Sandbox-Image.
• TUI und Desktop: eine klebende Benachrichtigung mit dem Key sessions.auto_prune, pro Profil und Prozess. Die Datenbankschätzung läuft außerhalb des Threads, damit die UI nie darauf wartet.
• Messaging-Gateway: Die Frage wird in den Home-Channel des bedienten Profils gepostet. Ein Detail, das zählt: Der „später“-Snooze wird erst nach einem zugestellten Post vermerkt, damit ein Gateway ohne Home-Channel die Frage nicht still verschluckt, die die CLI gleich stellen will.
• Slash-Befehl: /autoprune on | off | later | status, überall identischer Text, weil er durch einen gemeinsamen Registry-Executor läuft. Slacks Limit von 50 Slash-Befehlen ist ausgeschöpft, dort heißt es also /hermes autoprune.

Was die einzelnen Antworten tatsächlich tun

• on schreibt sessions.auto_prune: true und räumt beendete, inaktive Sessions jenseits von retention_days auf (Standard 90). Offene, gepinnte oder mitten im Turn befindliche Sessions werden nie angefasst.
• off schreibt false, behält alles und zieht die Frage für immer zurück.
• later verschiebt um 7 Tage und fragt dann erneut.

Um zu sehen, wo du stehst:

hermes config get sessions.auto_prune
/autoprune status

Immer noch knapp? In Schichten aufräumen

Automatisches Pruning ist eine Schicht. Wenn du wirklich Platz brauchst, geh von am wenigsten zu am meisten destruktiv:

hermes sessions optimize          # FTS5-Segmente zusammenführen + VACUUM, keine Datenänderung
hermes sessions optimize-storage  # Suchindex auf das kompakte Layout migrieren
hermes sessions archive           # Massen-Softhide, kein Löschen
hermes sessions prune             # echtes Löschen, filterbar nach Zeitfenster / Quelle / Titel

optimize und optimize-storage bauen Indizes neu und holen Fragmentierung zurück, ohne die Historie anzutasten – lauf die also zuerst. archive blendet Sessions aus der Liste aus, ohne sie zu löschen. prune ist der harte Weg – prüfe vorher, ob session_search diese Historie noch braucht.

Eine praktische Entscheidungshilfe

Die Frage hinter dieser Änderung ist einfach: Was ist dir deine Historie wert, gemessen an deiner Platte?

• Chronisch knappe Platte (ein kleiner VPS, ein Container mit ein paar Dutzend GB) und du schaust selten zurück: /autoprune on ist weniger Arbeit.
• Du verlässt dich auf session_search oder führst Audit-Trails: lass den Default (behalten, nicht gefragt) und lauf gelegentlich optimize.
• Unentschieden: schreib nichts. Der Default ist der konservative Zustand.

Wenn sich state.db schon daneben benimmt – etwa weil Hermes meldet, ein anderer Prozess halte ein altes WAL –, dann ist Pruning nicht die Lösung; beginne mit der Wiederherstellungs-Anleitung für den Session-Store. Wie Session-Grenzen funktionieren, steht im Leitfaden zu Session-Grenzen, und die genauen Flags findest du in der Referenz zu hermes sessions.

Ein Status-Hinweis, der klar gesagt gehört: Das hier ist am 2026-10-16 in main gemerged, nachdem v0.22.2 am 15.10. erschienen ist – es steckt also noch in keiner veröffentlichten Version. Es kommt mit dem Build, den dein nächstes hermes update zieht.