Claude Code 空闲也压缩，你的检查跑了吗
Hello，我是飞飞。
你给 Claude Code 交代完一堆要求，停下来忙别的。回来敲一句「继续」，它接着干了。可你有没有想过，它接着看的，可能已经是一份摘要？
Claude Code 的空闲压缩，已经写进官方更新日志。它会在满足条件时提前整理长会话。可恢复工作后，那些不能漏的检查，靠什么兑现？
这次我没做空闲前后的对照实测。能核实的有官方说明、本机版本，还有我三月那次真翻车。那次也是压缩之后，类型检查被跳过了。
为什么空闲也要压缩
官方更新日志给的条件挺具体：终端会话超过约二十万 token，空闲约五十四分钟，会赶在一小时提示缓存到期前压缩。
token 是模型处理文字的计量单位。代码、命令输出、你来回纠正的要求，都会占地方。提示缓存能复用重复的背景资料。每一轮重新处理的负担就轻一些。
这就解释了那个有点别扭的时间。你明明没发新消息，它也可能动会话。官方给的理由是，在缓存失效前先压短。下次继续时，少重新处理一些内容。
所以，五十四分钟得和前面的条件一起看。短对话停一会儿，不能直接套进去。它也没有承诺，你离开电脑就一定会触发。
这与窗口快满时的自动压缩，还得分开。前者看空闲与缓存条件；后者处理资料越积越多的问题。两条路径都可能把旧对话整理成摘要，触发原因却不同。
我能理解这个取舍。一大段排查日志，很多行早就用不上了。每次继续都带着，确实累赘。但哪些内容用不上，这个判断也交给了压缩过程。
你丢掉十屏安装日志，可能毫无感觉。丢掉一句「这里先别动」，后面的改动方向就可能跑偏。对我来说，恢复后的检查比那一下省了多少更值得盯。
我漏过的那次检查
三月十六号，我写过一篇Claude Code Hooks 进阶指南。开头讲的就是自己的事。
我在 CLAUDE.md 里写了规则。每次修改代码后，跑 TypeScript 类型检查。对话刚开始，它会做，大部分时候也确实做了。
那次会话拉得很长。上下文压过一轮，它悄悄跳过了检查。我没注意，带类型错误的代码被提交。隔天上线，出了问题。
现在回看，最坑的是我自己。规则写在文件里，它之前又照做过。我就把这次也算成做过了。提交的时候，少看的恰好是检查有没有真的跑。
这段旧经历没有记录空闲时长，也无法回头确认触发路径。它证明不了今天这项功能有故障。拿它当空闲压缩实测，我自己都交不了差。
它提醒我：会话接上了，检查记录还得重新对。
而且我那篇旧文，把 Hooks 写得太满了。说成「每次都执行，没有例外」。现在我会收回来：配置要加载，匹配要命中，脚本也得跑成功。少查其中一项，都可能给自己壮胆。
这个开关管哪一段
我核了这台机器，Claude Code 是 2.1.296。用户级配置和项目本地配置里，都没有显式写空闲压缩开关。项目共享配置文件也不存在。
这些结果只说明我没在这几处手动配置。还不足以判断，当前会话是否启用了那条运行路径。我也没为了写稿去改它。
官方更新日志写明，下面这项设置可以关闭空闲压缩：
1 | { |
开关与阈值配置，需要 v2.1.290 或以上。这个版本号说的是配置支持条件。它无法证明这项功能今天才发布。
文件放哪，决定影响谁。官方设置文档列得很清楚：用户级的 ~/.claude/settings.json 影响本机各项目。项目个人设置用 .claude/settings.local.json。
已有文件，就往原来的 JSON 对象里合并这个键。整份覆盖过去，原先配好的其他设置也跟着没了。只想管一个项目，就别顺手改成全局。
阈值另有一个环境变量，叫 CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS。它管空闲压缩的最小上下文规模。把门槛调高，也得继续面对窗口终究会满的问题。
关掉这条路径，更不能理解成从此再无压缩。官方工作机制文档仍然说明，接近窗口上限时，会清理旧工具输出，必要时总结对话。
想在暂停期间保留原来的上下文？你可以了解这个开关。但它解决到这里就够了。后面的质量检查，还得另有着落。
继续之前看什么
我现在更愿意把「继续」当成一次交班。接班的人说听懂了，我还是要看看桌上剩下哪些活。
长期适用的规则，放项目指令文件。当前做到哪，写进任务记录。哪些检查跑过，保留命令、结果和对应的改动。三类内容混成一大段聊天，回来很难分辨哪句还有效。
官方的记忆说明也提醒，CLAUDE.md 是给模型的背景指令。它能指导行为，不能靠一行文字就强制动作发生。
拿我漏过的类型检查说，项目规则能写「改完要检查」。验收时，我得看到检查命令运行过。结果还得对应当前这份代码。中间又改了文件，旧结果就不能直接拿来交差。
Hook 可以帮忙把检查接进执行流程。说人话就是，在指定动作发生时跑一段脚本。但它在哪个动作前后运行，会决定它究竟能挡住什么。
官方 Hooks 文档区分得很细：编辑后的处理器，面对的是已经完成的编辑；操作前的处理器，才有机会拦下那次操作。不能看见脚本退出码，就笼统说它挡住了一切。
我这套写作流水线里，就有一份容易认错的记录。初稿写完，会先存一份到知识库。后面润色只改博客正文，那份副本还停在初稿。
流程里就单列了副本回写。配图完成后，跑同步脚本，先查两份正文是否一致。有差异再回写，并保留旧副本。仅凭「知识库里已经有这个文件」，根本判断不了里面是哪一版。
代码检查也有这个问题。看见一条成功记录，要追问它检查的是哪次修改。记录与当前文件对不上，那个绿勾很容易让人提前放心。
同样，写了交接文件，也得在恢复时读。文件躺在目录里，模型没打开。「检查尚未完成」那句，依然传不过去。
与其只敲「继续」，我更愿意把这句话发过去：
先读任务记录，列出当前目标、已改文件和未完成检查。每项附文件位置或命令结果。没有证据就标待核对，先别改代码。
这是一段恢复前的核对提示，还没经过本次空闲对照测试。它的用处，是把「我记得」拆成能查的东西。类型检查没结果，就明摆着留在待办里。
我先把证据留住
这次没有空闲前后的实验结果。开关要怎么选，我还给不了实测推荐。
真要测，也得把版本、会话规模、暂停时长写下来。确认触发过压缩，再对照任务约束与实际操作。只看它能复述几条要求，还量不到执行有没有漏。
可我三月那次漏检，已经够提醒自己了。规则在那里，检查却没跑。那次带错提交，比一句「我会记住」实在得多。
你暂停长任务再回来，最常需要补哪句交代？不要动的文件、刚做过的决定，还是没跑的检查？