会话恢复了，旧密钥也该留下吗？
保存一段 AI 会话，是为了明天还能接着做。对话历史需要留下，这很容易理解。
但启动助手时用过的密钥，也需要跟着留下吗？
这里的密钥，是程序访问服务时使用的凭证。换了账号或连接配置，当前运行可能已经改用新凭证。我们用真实临时文件做实验，却看到一种容易被忽略的状态：恢复已经用上新值，旧值仍躺在磁盘文件里。
“现在能继续工作了”，回答不了“以前的副本清理了吗”。
为什么会话记录里会混入密钥？
问题来自 electrumnz 提交的 Paperclip #13498。Paperclip 是用于组织 AI 助手工作的开源应用；研究时，这份修复提案尚未合入。
程序启动助手时，会传入一组配置，称为“环境变量”，其中可能包含访问服务所需的密钥。上游指出，这组启动配置跟着会话设置一起写进了文件，于是原本为本次运行准备的凭证，也变成了可长期保留的副本。
这吸引我们，是因为“为了以后恢复，尽量多存一些”听起来很合理。但历史消息和启动凭证的用途不同：明天需要接着读昨天的对话，并不意味着必须继续使用昨天的凭证。
候选修复把这两件事拆开：保存时去掉启动环境，恢复时再填入当前运行的环境。我们的研究问题随之变得具体：这样既能保留历史，又能处理磁盘上的旧值吗？
用假密钥，检查真的文件
实验只用容易识别的合成字符串代替凭证，不读取真实密钥。我们把候选的保存和加载代码接到临时文件上：先准备一个旧值，再用另一个当前值恢复，最后直接查看文件里还剩什么。
| 操作 | 磁盘是否仍含旧合成值 | 恢复时是否使用当前值 |
|---|---|---|
| 直接保存未经处理的原记录 | 是 | 是，加载仍经过候选代码 |
| 经过候选代码保存新记录 | 否 | 是 |
| 读取已有旧记录，不再保存 | 是 | 是 |
| 读取旧记录后，再经过候选代码保存 | 否 | 是 |
四个场景都保留了对话历史。保存时传入的原始对象也没有被修改：去掉文件副本里的环境，没有顺手破坏运行中仍可能需要的内存数据。
这张表里最值得停一下的是第三行。恢复拿到了当前值，磁盘检查却仍找到了旧值。两项检查都没看错，它们看的是不同地方。
图 1：加载时使用新值，与保存时移除旧环境，作用在不同位置。来源：本轮真实临时文件实验，由作者绘制。
为什么读过旧文件，旧值还在？
因为读文件和改文件，本来就是两个动作。
候选代码读取旧记录后，给当前运行返回一份换上新环境的对象。它没有在读取期间重写原文件。我们随后明确再保存一次，受测位置里的旧值才消失。
这符合提案中“再次保存后移除环境字段”的说明。对升级软件的人而言，还有一件事要说清：那些以后不再打开、不再保存的旧记录，准备怎样处理？备份里如果还有旧副本，又由谁处理？
修复已经阻止了新保存记录继续带上启动环境，也让恢复采用当前环境。实验帮助我们看清的是，它与“把已有副本全部清理完”之间，还隔着一项升级工作。
旧副本清了，旧凭证就不能用了吗？
还不能这样推断。“旧”只表示它是以前使用的值，不表示服务端已经让它失效。删除本机的一份记录，也不等于吊销那段凭证。
所以开发者需要分别回答三问：
- 今后还会不会写入？ 检查新保存的记录。
- 以前留下的副本怎么办？ 明确旧会话文件和备份的处理责任。
- 不该继续有效的凭证是否已失效？ 这需要凭证管理，不能靠删除文件来代替。
本轮实验回答了受测保存与加载路径的行为，没有执行凭证轮换、吊销或备份清理。
对普通使用者，这也可以变成一个具体反馈：更换账号或连接以后，软件是否说明了哪些历史会保留、旧连接材料怎样处理？恢复成功当然有用，但它不应该让人误以为所有旧副本也已处理完。
我们由此向维护者提出的追问是：能否把“阻止新写入”和“处理既有记录”的区别写进升级说明，并明确后者的责任？这个问题关系到修复如何被正确使用，而不仅是保存函数怎样写。
给技术读者：过滤范围、第五个对照与实验边界
来源作者 electrumnz；研究时 #13498 仍 OPEN。固定候选 bfe7f568976a2c671184722a6e6294927d6e6fae，来源基线 9cfa7fd2d13213b73396cf34b9fc95912857ff69。
运行候选完整 session-store.ts：它包装存储接口，在 save 时移除 acpx.session_options.env，在 load 时放入本次的 launchEnv。底层使用我们实现的真实临时 JSON 文件存储。直接保存原记录是反例对照，不称为完整旧 ACPX 实现。
第五个边界场景故意把同一个合成值放进无关的 debug 字段。候选移除了指定环境字段，却保留那个任意字段中的值。这验证它是针对已知结构的过滤，不是通用敏感值扫描器；人工字段不能证明生产系统另有泄露路径。
上游讨论了同一操作系统账号下多个助手席位的访问风险，也提出关闭 shell 快照的改动。我们没有复现这些路径，没有启动真实 ACPX 子进程，也没有验证跨席位访问、备份清理、凭证轮换或完整产品恢复。上游报告的 195 项测试不计入我们的实测数量。
五个场景的原始观察、探针与固定源码。没有据此断言 CodeFlowMu 存在相同泄露。