某天你想翻三个月前的一次调试记录，/resume 里怎么都找不到那个会话。翻遍配置才想起来：sessions.auto_prune 是开着的，90 天前的历史在某个启动瞬间被静静删掉了，没有提示、没有确认。这件事现在改了——自动清理重新变成“要你点头才做”，而且只在你磁盘真的快满的时候才来打扰你。

变了什么：默认不删了

改动很干脆：sessions.auto_prune 的默认值从 true 改回 false。三种安装状态的行为差别如下：

你的情况	之前	现在
从没设过 sessions.auto_prune	90 天后静默清理	不清理；磁盘吃紧时问一次
显式设了 auto_prune: true	清理	照旧清理
显式设了 auto_prune: false	不清理	不清理，也不会再问

注意第二行：之前主动打开过的人不受影响，你的选择被尊重。真正变化的是“从来没表过态”的那一大群人——他们的历史不再被默认当成可回收资源。

什么时候它会开口

判断逻辑写在新增的 hermes_cli/prune_advisor.py 里，热路径只做三件很便宜的事：os.stat、shutil.disk_usage，再读一小段 YAML。只有同时满足这些条件才会弹问题：

• 磁盘确实低：剩余少于 2 GiB，或者剩余比例低于 10% 且总量剩余不到 20 GiB（一块 4 TB 的盘剩 10% 不算紧张，这个条件就是为它写的）；
• 你的 config.yaml 里没有 sessions.auto_prune 这个键；
• 没有生效中的“稍后再说”。

一旦触发，它才去开数据库做只读估算：按 retention_days 之外的已结束会话，结合它们占消息总量的比例，估个能释放多少。估算结果会直接写进问题里，包括最尴尬的情况——“清理救不了这块盘”：没有足够老的会话，或者能回收的空间不足以让磁盘离开低水位。

同一个问题，四个界面

• 经典 CLI：启动时问一句，只有 y / n / 回车（稍后），只在 TTY 下出现，位置就在沙箱镜像提示旁边。
• TUI 与桌面端：发一条 sticky 通知（键名 sessions.auto_prune），每个 profile 每个进程只发一次；数据库估算是另开线程跑的，不会卡住界面。
• 消息网关：把问题发到被服务 profile 的 home channel。这里有个容易踩的细节——“稍后再说”只在真的投递成功之后才记录，所以一个没有 home channel 的网关不会把问题悄悄吞掉，让 CLI 那边永远等不到。
• 斜杠命令：/autoprune on | off | later | status，四个界面文本完全一致（走同一套注册执行器）。Slack 的 50 个斜杠命令名额满了，所以那边走 /hermes autoprune。

三个回答各自意味着什么

• on：写下 sessions.auto_prune: true，从此按 retention_days（默认 90 天）清理已结束且不活跃的会话。打开着的、钉住的、正在 turn 里的会话永远不动。
• off：写下 false，历史留着，而且这个问题再也不会出现。
• 稍后（later）：静默 7 天，之后再问。

想先看一眼自己的现状：

hermes config get sessions.auto_prune
/autoprune status

磁盘还是紧？手动分层清理

自动清理只是其中一层。真的需要腾空间时，按“破坏性从小到大”来：

hermes sessions optimize          # 合并 FTS5 段 + VACUUM，不改数据
hermes sessions optimize-storage  # 把搜索索引迁到更紧凑的布局
hermes sessions archive           # 批量软隐藏，不删除
hermes sessions prune             # 真正删除（可按时间窗、来源、标题过滤）

optimize 和 optimize-storage 只是重建索引、回收碎片，不动历史记录——这两条最值得先跑。archive 是软隐藏，删不掉数据但能让列表清爽。prune 才是真删，跑之前先想清楚有没有 session_search 需要的历史。

一点取舍建议

这条改动其实在问一个很实际的问题：历史值多少钱，磁盘值多少钱。

• 磁盘长期紧张（小 VPS、容器里只有几十 GB）、又很少回看历史：/autoprune on 更省心。
• 常用 session_search 翻旧账、或者要留审计痕迹：保持默认（不删，也不问），偶尔手动 optimize。
• 拿不准：什么都不写。默认状态就是最保守的那一种。

如果哪天 state.db 已经出问题了——比如提示有别的进程占着旧 WAL——那不是清理能解决的，先看会话库损坏的修复流程；想弄清会话边界的机制，可以读会话边界指南；命令细节在hermes sessions 参考。

需要说明的是，这次改动在 2026-10-16 合入 main，晚于 v0.22.2 的发布（10-15），所以它还没进任何已发布版本，等你下次 hermes update 拉到的版本才会带上。