Codex 切换 API 站点后聊天记录消失？一招教你找回失忆的对话历史
最近在折腾各种 AI 客户端，发现不少朋友在使用 Codex 这类第三方工具时，都遇到过一个特别让人抓狂的问题：明明用得好好的，用 cc-switch 切换了一个 API 站点，重启一下客户端，之前的聊天记录竟然全没了！
这就像是你的 AI 助手突然“失忆”了一样，辛辛苦苦调教的 Prompt 和重要对话瞬间归零。为啥有的站点切换没事，有的站点切换记录就飞了？今天就来扒一扒这背后的原理，顺便教大家怎么解决这个问题。
为什么聊天记录会消失？
首先，我们要明白这些第三方客户端是怎么保存你的聊天记录的。大多数客户端并不是把你的聊天记录“存”在 API 服务器上（毕竟很多中转 API 也不提供这个功能），而是本地存储。
当你切换 API 站点时，软件通常会把聊天记录和一个特定的“身份标识”绑定在一起。如果这个标识发生了变化，客户端就会以为你开启了一个全新的会话，自然就找不到之前的记录了。
cc-switch 配置示例
这就解释了为什么有的站点切换没问题，有的就不行——关键就在于这个“身份标识”是否一致。
核心解法：统一 ID 同步机制
根据大佬们的实测反馈，解决这个问题的核心秘诀在于：保持所有 API 供应商的 ID 一致。
在 cc-switch 这类工具中，其实有一个“统一会话历史”的机制。原理非常简单粗暴：只要你在不同 API 站点的配置中，把关键的标识 ID 填成一样的，客户端就会认为这是同一个会话的延续，从而把本地的历史记录加载出来。
模型提供商映射设置
简单来说，聊天记录的读取逻辑是：
- 客户端查找当前的会话 ID。
- 去本地数据库检索该 ID 对应的历史记录。
- 只要 ID 对得上，无论你底层调用的是 OpenAI、Claude 还是其他中转 API，它都能把之前的对话“喂”给你看。
实操避坑指南
除了最核心的 ID 统一问题，还有一个细节值得注意：模型提供商的映射。
有用户反馈，如果在 cc-switch 中修改了 model_provider（模型提供商），聊天记录也会莫名其妙地消失。但如果你把配置改回原样，记录又神奇地回来了。
这说明，有些客户端在判断会话一致性时，不仅看 ID，可能还会校验模型名称或提供商字段。因此，在切换站点时，尽量保持模型名称和提供商配置的一致性，不要随意改动这些字段，除非你想开启一个新的对话分支。
总结一下
不想让 Codex 或其他客户端“失忆”，记住这两点：
- ID 统一： 确保不同 API 站点配置中，用于标识会话的 ID（通常是自定义的 User ID 或 Session ID）保持完全一致。
- 配置稳住： 尽量不要频繁修改
model_provider等关键配置字段，以免触发客户端的新会话判断机制。
搞懂了这个原理，以后无论怎么“白嫖
评论已关闭