临时文件占用磁盘空间

一些用户在 opencodex 主目录（默认为 ~/.opencodex）中发现了大量名为 responses-state.json.ocx.<pid>.<seq>.tmp 的文件，总量达到数 GB，并且每次重启后都会增长。

这些文件是什么

opencodex 维护续接缓存，使 previous_response_id 链在代理重启后仍可使用。它以原子方式写入快照：先将内容写到临时文件，再一次性替换正式文件。这样即使写入途中崩溃，也不会留下只写了一半的快照。

交换完成后，临时文件通常会立即移除。如果进程在这两步之间终止，临时文件就会留下。

由于每次都重写整个快照而非追加，每个文件最大可达 24 MB。因此，只要遗留几百个文件，空间占用就会迅速增加。

它们是缓存，而非持久状态。 删除它们的唯一代价是进行中的对话链可能重新发送一次上下文。这些文件不含配置、凭据或历史记录。

为什么会累积

原本已有清理机制，但它只在一个时刻运行：代理首次加载续接缓存时，也就是该进程写入任何内容之前。这造成了两个后果。

崩溃后重启的代理清理得太早，无法看到前一个进程刚留下的临时文件，因为有 15 分钟宽限期，避免触碰当前正在写入的文件。此后代理的整个生命周期中都不会再次检查。于是每次重启都会多留一个文件。

更糟的是，如果文件的所属进程 ID 仍然存在，清理机制会跳过它。重启后，操作系统常会重复分配相同的进程 ID，因此旧文件可能被永久误认为属于当前运行的进程。这就是文件数量随重启次数增长的原因。

opencodex 现在如何处理

清理会在代理的常规后台定时器上重复执行，而非仅在启动时运行一次，因此运行中的代理会自行回收遗留文件。对于早于本次系统启动的文件，清理还会忽略进程 ID 检查，因为任何当前运行的进程都不可能拥有它们。

安全规则不变：不会删除创建不足 15 分钟的文件，代理也绝不会删除自己正在写入的文件。

快照写入频率

写入采用防抖机制，延迟时间根据上一次实际写入的快照大小决定：文件较小时，变更后约两秒安排下一次写入；接近 24 MB 上限后，等待时间最长延至 30 秒。因此，刚刚变大的缓存仍会经历一次短等待；较长的节奏从下一次写入后才开始适用。只有当本进程已经向同一文件写入相同字节、磁盘上的文件仍匹配，并且在 Windows 以外其权限仍为仅所有者可访问时，才会跳过刷新。新进程仍会重写一次相同快照；如果文件内容或权限在代理之外发生变化，也会通过加固写入路径重写，而不会置之不理。

每次普通后台周期最多执行一次完整的原子重写。如果写入期间续接缓存再次变化，opencodex 会在常规延迟周期中安排一次后续写入，而不会立即再次重写整个快照。正常关闭时，进行中的请求排空后仍保留有界重试行为，使最终快照能在进程退出前赶上变化。

这些措施使缓存增长时的写入速率大致保持平稳，而不是每两秒都重新序列化并替换整个文件。

正常关闭会立即刷新，不等待定时器。因此，较长的等待主要扩大了强制终止可能丢失最新续接条目的时间窗口；如上所述，这些条目属于缓存。刷新仍是一项磁盘写入，也可能失败；如果关闭时磁盘已满或卷为只读，同样可能丢失这些条目。

回收已经累积的文件

如果代理正在运行，一两分钟内会自动完成回收。

如果代理无法启动——这也是文件堆积最快的情况——可从命令行检查并回收：

ocx doctor

“Response-state temp files” 部分会报告可回收文件的数量和占用空间。此命令只报告信息，不会修改文件。

实际删除文件请运行：

ocx doctor --reclaim-response-temps

两个命令都无须运行代理。被其他进程锁定的文件只会报告出来，不会强制处理。下一次回收会重试：代理运行时会自动重试，否则在下次执行该命令时重试。

如果积压量太大，一次处理不完，命令会报告剩余文件数量，供你再次运行。

此功能专门处理响应状态快照的临时文件。其他组件也可能写入名称相似的临时文件，但这里不会触碰它们。