为Claude Code闲置会话设置定时回收

Claude Code 的任务结束了，编辑器里的会话却可能还活着。作者检查使用报告后发现，65% 的会话已打开至少 8 小时，问题最终指向没有关闭的编辑器标签页。

他的办法是每小时运行一次 Python 清理脚本，只关闭超过空闲阈值、且没有相关子进程的编辑器会话。这篇经验最有用的部分，是如何限定清理范围、验证关闭理由，以及避开一个足以让脚本完全失效的时区问题。

会话开了很久，先查是谁让它活着

作者没有直接写清理脚本，而是先读 /usage。报告显示：

• 94% 的会话提示需要 /clear。
• 65% 的会话已经打开 8 小时或更久。
• 当时有 10 个存活会话，9 个编辑器标签页已经打开了 15 到 17 小时。

这里要区分两件事：会话存活时间长，不等于一直在工作；提示 /clear，也不能直接作为关闭进程的依据。

作者最初怀疑 Remote Control 在维持连接，但检查 5 个老旧空闲标签页后发现，只有 2 个存在 bridge。这个结果不足以支持原来的猜测。

按作者的排查，真正的原因更直接：编辑器标签页没有关闭，对应进程就会继续存活，而 Claude Code 不会自行关闭空闲会话。对习惯同时开多个项目的开发者来说，任务结束和进程退出之间，确实可能隔着一个被忘记的标签页。

不过，原文没有提供 CPU、内存或费用的前后对比，不能把这些存活会话直接算成持续消耗的模型调用。

自动清理的关键，是把关闭条件写窄

作者的脚本只处理编辑器会话，而且必须同时满足两个条件：空闲时间超过阈值，没有 shell 或 Claude 子进程。

launchd 服务、CLI、SDK 和 memory 会话都不在清理范围内。作者还把 /resume 作为恢复入口：被关闭的会话可以重新打开。

会话年龄可以帮助发现问题，真正执行关闭时仍要检查会话类型、空闲状态和子进程。

脚本提供两个参数：--hours 设置阈值，默认值为 4；--dry-run 预演判断，打印每个会话会被保留还是关闭，以及具体原因。作者建议反复检查这些理由，确认符合预期后再启用关闭动作。

下面是作者给 AI 的完整实现要求，它解决的是如何把清理边界、预演模式和定时执行一次说明白：

Write a Python script that lists my Claude Code sessions from ~/.claude/sessions/*.json and closes only editor sessions that have been idle longer than --hours (default 4) and have no shell or claude child process. Add a --dry-run flag that prints every session with a keep or close reason. The session files record procStart in UTC, so compare against ps run with TZ=UTC. Never touch launchd services, CLI or SDK sessions. Log closed sessions to one file and errors to another. Then write a launchd plist that runs the script every hour.

重点看 procStart 和 TZ=UTC 所在的那一句。会话文件里的进程启动时间使用 UTC，而 ps -o lstart 默认输出本地时间。作者第一版没有统一时区，按他的复盘，这会导致脚本一个会话都关不掉。

最终方案用 launchd 每小时执行一次，空闲阈值设为 4 小时。正常日志只记录实际关闭的会话，错误写入另一份文件，方便查看清理结果。

我的判断

我认可这套处理顺序：先看报告，再验证怀疑对象，最后才做自动化。尤其是 --dry-run 输出每个会话的判断理由，比只打印一句「将关闭几个会话」更便于发现误判。

但原文给的是个人工作笔记和实现提示词，没有公开完整 Python 脚本、launchd plist，也没有给出清理后的对照数据。4 小时是否合适，属于作者的经验选择，不能直接当作团队默认值。

还有一个关键缺口：原文没有说明「空闲」究竟如何判定。 procStart 是进程启动时间，只能告诉你进程活了多久；没有 shell 或 Claude 子进程，也不能单独证明用户已经不需要这个标签页。照着实现时，需要补清楚这部分依据。

和手动关闭标签页相比，定时清理减少了遗漏，却增加了识别会话和维护脚本的成本。对多项目、多标签页的工作方式，它可能有用；如果只是偶尔忘关，先养成收尾习惯也很合理。作者提到 /resume 可以恢复会话，但没有展开关闭方式及其影响，不宜把「最坏就是重新打开」推广成所有环境下的保证。

能拿来做什么

• 如果你经常在编辑器里并行处理多个前端项目，先查看 /usage，再核对老旧标签页，确认自己是否存在同类问题。
• 让 AI 编写清理脚本时，把允许处理的会话类型、禁止触碰的对象和子进程检查写进要求，并要求 --dry-run 逐项解释判断。
• 调试时间比较时，明确区分启动时间和空闲时间，并用 TZ=UTC 统一 ps 的输出时区，避免脚本正常运行却始终无法命中。
• 若要采用作者的每小时执行、4 小时阈值方案，先检查预演结果，再启用 launchd，并将关闭记录与错误日志分开保存。