把 Codex 的默认模型切换到 DeepSeek 后你发现官方聊天记录全没了。这大概是我最近被问得最多的问题也是很多教程和视频没有正面回答过的问题。多数教程会教你改一个 base URL填一个 API Key然后告诉你可以用了。但没人告诉你切换模型服务商这件事不只是一个配置项的改变而是整套运行环境和数据路径的变化。聊天记录“消失”往往不是被删除了而是 Codex 没有加载到正确的位置。真正值得搞清楚的是这个工具在接入第三方模型时哪些环节会让你误以为数据丢了以及怎么用一套稳定的流程把切换、备份和恢复串起来。我的核心判断是Codex 接入 DeepSeek 并不是把模型名一换就完事它同时涉及 CLI 路径、本地转发层、模型参数和会话存储四个层面的适配。聊天记录看起来“全没了”更多是切换后的配置分支隔离和路径加载问题而不是数据被清空。搞懂这个过程下次再换模型才不会反复踩同一批坑。1. 先搞清楚聊天记录到底是“没了”还是“没有被加载出来”1.1 Codex 的会话存储和账号绑定习惯Codex 的官方桌面端和 CLI 在默认情况下会话记录并不是存在云端某个“通用聊天记录库”里而是跟着当前账号配置、本地配置目录以及运行模式走的。你平时点开 Codex 看到的历史会话其实是它从本地某个会话存储区读出来的同时会通过账号信息做一次校验。也就是说Codex 认为你“有没有权限看这些会话”取决于当前运行环境能否关联到原来的账号身份和配置路径。这个问题在接入第三方模型时很容易暴露出来。因为你切换到 DeepSeek 时通常会做这几件事安装或升级 Codex、修改配置文件、设置环境变量、重启应用。每一步都可能让应用落到一个新的配置分支里。如果存储路径本身没有变但账号校验失败界面就可能显示成空列表如果路径变了那等于从一套房间搬到了另一套房间旧家具还在原地但门牌号对不上了。1.2 切换 DeepSeek 后到底发生了什么先别急着下“数据被删了”的结论。从工程经验看会话记录全没了的现象通常分成三类界面空列表历史会话还能在磁盘上找到但应用没有加载。应用闪退或起不来报错信息指向 CLI 路径或配置文件导致根本没有机会进入会话列表。会话数据被写到了新目录你切模型时更新了配置目录但旧会话还在旧目录。处理思路是先备份再确认数据是否还在最后调整配置让应用加载回正确位置而不是反复重装或反复清缓存。1.3 先备份再迁移一条不会错的恢复路径无论你现在遇到的是哪一类现象第一步都应该先做备份而不是忙着重装。常见做法是关闭 Codex 相关进程找到本地配置目录把整个目录复制一份到安全位置。复制完再启动应用。如果启动后能看到旧会话通常说明只是配置分支切换导致的加载问题。接下来要做的是对比当前运行配置和旧配置的差异尤其是 CLI 路径、模型服务商地址、账号信息这三项。这里给一个通用的判断顺序备份配置目录。检查日志Codex 启动时有没有尝试加载某个存储文件有没有报路径错误。用原来可以正常使用的模型配置启动一次确认旧会话是否可见。如果旧配置可见说明数据没有丢问题出在新旧配置的分支隔离。找一个你不那么在乎的会话测试几次再决定是否合并目录或迁移数据。提醒不要重复“启动 — 看到空列表 — 重装 — 再启动”这个循环。每一步都可能把可恢复的状态推得更远。2. 接入 DeepSeek 的第一步把 CLI 路径和环境变量理顺2.1 为什么会出现 unable to locate the codex cli binary很多人在把 Codex 切换到 DeepSeek 后会看到一条比较长的报错核心在于 “unable to locate the codex cli binary. set codex_cli_path or ensure the elec...” 这类信息。它说的是Codex 的图形界面找不到 CLI 可执行文件。这不是 DeepSeek 的问题而是 Codex 的桌面端本身依赖 CLI。Codex 桌面端在调用模型、读取配置、执行本地操作时很多底层动作都要通过 CLI 来承接。当你切换模型时如果 Codex 的 CLI 没有安装或者安装在当前用户无法访问的路径或者 PATH 环境变量里找不到它应用就会直接拒绝启动表现出来的就是聊天记录列表没加载成功。2.2 设置 Codex CLI 路径的常见做法解决思路分三步确认 Codex CLI 是否真的安装了。打开终端执行codex --version或which codexWindows 下是where codex看能不能找到。找到可执行文件的实际路径。如果找不到大概率是安装步骤没完成或者安装到了某个没有加入 PATH 的目录。在 Codex 桌面端的设置里或者在配置文件中设置codex_cli_path把它指向实际的 codex 可执行文件。示例结构如下具体路径要结合自己的系统调整# Linux / macOS 常见做法 export PATH$HOME/.codex/bin:$PATH codex --version{ codex_cli_path: /Users/你的用户名/.codex/bin/codex }注意配置文件字段名在不同版本里可能不同有的版本用codex_cli_path有的版本用其他命名。如果设置后仍然报同样的错误先看日志里读取的是哪个字段。2.3 版本和 PATH 的影响还有一个容易被忽略的地方版本。Codex 的桌面端和 CLI 如果版本完全对不上也会出现这种定位不到的情况。比如桌面端已经升级到新版本但 CLI 还是旧版本或者反过来。更稳妥的做法是安装官方说明里的同一版本组合并保证 PATH 中只保留一个可执行的 codex避免多个版本互相干扰。如果是在公司电脑或服务器上使用还可能需要检查权限。CLI 可执行文件是否对当前用户有执行权限配置文件目录是否可写。很多时候不是路径写错了而是权限不够导致 CLI 根本没有办法写日志和缓存应用就判断为不可用。3. 兼容端点的秘密Codex 不是原生支持 DeepSeek而是通过 API 兼容层接入3.1 同一个 JSON 结构不同模型服务的差异Codex 官方界面并不直接提供“连接 DeepSeek”这个选项。它默认走的是 OpenAI 风格的 API 协议。DeepSeek 开放平台本身提供了兼容 OpenAI 的接口格式于是才有了“把 Codex 切到 DeepSeek”的玩法把 Codex 的 API 端点地址改成 DeepSeek 的接口地址把模型名改成 DeepSeek 的模型名再填上 DeepSeek 的 API Key。这个思路能跑通核心原因是两边共享了很多请求字段model、messages、temperature、max_tokens 这类基础字段都能对上。但“协议兼容”不等于“功能完全一致”。DeepSeek 有自己的模型特性比如某些模型支持推理模式和思考内容字段而 Codex 不一定把这些字段完整传给 DeepSeek或者传过去的格式不符合 DeepSeek 的预期。3.2 转发失败时应该从哪一层排查很多用户遇到过这样一条报错cc switch local proxy failed while handling codex endpoint /responses. provider: deepseek; model: deepseek-v4-flash; upstream_status: http 400; cause: the reasoning_content in the thinking mode must be passed back to the api.这条报错描述了三个关键信息请求经过了本地转发层也就是 cc switch 这类本地工具。目标 provider 是 deepseek。报错原因是 reasoning_content 在思考模式下必须原样回传。这类问题不是网络断了而是模型参数和协议字段不匹配。Codex 发起请求时带有自己的格式而 DeepSeek 在思考模式下要求把某段 reasoning_content 原样传回去。如果中间转发层丢弃或改写了这个字段就会导致 HTTP 400。排查顺序很重要看请求能不能到 DeepSeek如果报错里有upstream_status说明请求已经出去了是上游返回的。看是哪个字段被拒报错里会说明是 reasoning_content、还是 model、还是其他字段。看转发层是否对 Codex 的请求做了处理有些本地工具会统一改写请求格式但可能没有适配 DeepSeek 的思考模式。尝试在转发层配置里关闭/开启思考模式或者使用不带思考模式的模型看是否能绕过。提醒看到 http 400 时不要一上来就怀疑 API Key更常见的是请求字段不符合上游模型的要求。3.3 本地转发层的定位这类工具本质上是一个本地 HTTP 服务Codex 把请求发给本地地址它再转发给 DeepSeek。它对你的价值不是“加速”而是把 Codex 的模型格式转换成 DeepSeek 能理解的请求。所以配置时应该想清楚本地服务地址、监听的端口、目标 API 地址、目标模型名、API Key这五样都要对。如果配置完报错说 “local proxy failed”先确认本地服务是否真的在运行端口是否被占用以及 Codex 的 base URL 是否指向了正确的本地地址。有的错误是服务没启动有的错误是端口冲突有的则是配置里的地址缺了路径。不要只看“failed”就急着调 DeepSeek 那边。4. 模型名和模型能力要对上从两个常见报错说起4.1 模型名不是想填什么就填什么接入第三方模型时配置里填写的模型名必须同时满足两边的要求Codex 能识别DeepSeek 也能识别。很多人遇到过类似the gpt-5.6-sol model is not supported when using codex with a...的报错这说明 Codex 在某个模型列表中找不到对应的模型名或者当前接入方式不支持这个模型名。这类问题在接入第三方模型时非常常见因为 Codex 本身是为官方模型设计的部分字段和模型名会做硬编码校验。解决办法通常是在 Codex 的模型配置里把第三方模型的标识准确配置好同时让转发层保留原模型名不用 Codex 默认模型名去替代。4.2 reasoning_content 报错的产生原因与处理回到 deepseek-v4-flash 那条报错。reasoning_content 是思考模型的一个特殊字段用来承载模型的推理过程。Codex 在请求时可能不发送完整的历史推理内容而 DeepSeek 在思考模式下要求接收方把上一轮请求里返回的 reasoning_content 原样带回以保证多轮对话的连贯性。如果你在转发层已经配置好仍然遇到这个报错说明当前 Codex 版本对思考模型的支持还不够完善或者转发层没有正确保留 reasoning_content 字段。临时做法是切换到一个不带思考模式的模型或者关闭思考模式长期做法是更新 Codex、更新本地转发工具到较新版本再看是否兼容。从使用经验看遇到这种报错与其反复试不同参数不如先做一个小实验用一条消息不开思考模式看看能不能跑通。如果不开思考模式能跑通说明问题就出在思考模式的字段处理上而不是整体链路的问题。4.3 先建立最小验证清单接入不同模型时建议不要第一轮就上完整任务。先在 Codex 里输入一句最简单的测试话比如“输出一个 hello world 的 Python 文件”。如果这个能成功再试长对话再试代码生成最后再试工具调用或文件操作。每前进一层都要确认前一层没有新的报错。验证层级建议测试内容通过标准基础连通问一句“你好”能正常回复代码生成要求生成一个简单函数能输出代码块多轮对话追问修改意见能理解上下文工具调用请求读取本地文件权限和路径正常批量任务连续处理多个请求没有限流和字段报错5. 聊天记录的备份、迁移和长期管理5.1 找出 Codex 会话数据目录聊天记录不是神秘消失而是大概率还躺在某个目录里。要恢复它第一步是找到 Codex 的会话数据目录。常见位置包括系统常见位置Linux / macOS~/.codex下可能有 sessions、logs、config 等子目录Windows用户主目录下的 AppData 相关目录自定义环境通过本地配置工具写入的目录这些目录的具体名称会因版本不同而变化所以最好的方式是看 Codex 自己的日志。日志里通常会记录启动时读取了哪个配置目录、哪个会话存储文件。5.2 迁移时的配置一致性检查把聊天记录从旧配置迁移到新配置不能简单复制文件。因为会话记录通常会和模型、账号、CLI 路径等信息关联。直接复制文件可能会出现“能看到会话但点进去报错”的情况。更稳妥的做法是分步验证先在旧配置下确认会话可以正常打开。记录旧配置的模型名、API 地址、账号信息。把整个数据目录复制到新位置但先保留旧目录不动。在新配置中指定新的数据目录并保持一致的环境变量。打开一条旧会话看内容是否完整是否还能继续发送消息。注意迁移的目标不是“让旧会话在新模型下继续聊”而是“让旧会话在新环境中还能查看和引用”。如果后续要接着聊建议把关键内容以文件或 Markdown 形式导出再基于新模型开启新对话。5.3 用版本控制和管理备份避免再次“消失”聊天记录这种数据越是在切换频繁的环境里越需要主动备份。一个可复用的习惯是每次切换模型、升级 Codex、修改配置文件之前先存档。存档可以是压缩包也可以是 git 仓库。你会得到一个明确的回滚点。再遇到“聊天记录全没了”的情况恢复就是解压或者 checkout 的事不用再猜。需要备份的不只是会话文件还包括配置、环境变量说明和安装记录。建议在项目里维护一份简单的 README把本地 Codex 接入第三方的配置过程和关键变量写下来。这比任何工具都可靠因为它记录的是“为什么这样配置”。6. 从教程到工程化把这次切换沉淀为可复用流程6.1 最小可用流程综合前面的内容接入 DeepSeek 并保留旧会话的完整流程可以简化为备份当前 Codex 配置目录。确认 CLI 能正常执行路径设置正确。确认本地转发层已启动端口和地址正确。配置 DeepSeek 的 API 地址、模型名和 Key。用一条最小消息验证模型连通性。验证会话列表是否能显示旧数据。如果旧数据不可见检查日志比对配置目录。这套流程适合第一次接入时使用。熟练之后可以把多数重复操作写成脚本或命令减少手工配置。6.2 真实场景下的批量使用和异常重试如果只是学习和小规模验证单条消息能跑通就够了。但如果要用在真实项目里比如批量生成代码、批量整理文档就要考虑失败重试、日志记录、输出目录和成本控制。建议不要把批量数和并发数一上来就拉满。先用一条样例确认输入输出正常再逐步增加批量数。对于失败的任务把错误日志单独收集按状态码归类。HTTP 400 通常处理字段HTTP 401 通常处理密钥HTTP 429 通常处理限流。这类判断顺序比盲目重试更有效。6.3 适合谁不适合谁Codex DeepSeek 的组合适合以下场景想要用 Codex 的操作界面和本地文件操作能力但不想为每条消息都走官方模型的用户。已经熟悉 Codex CLI想接入不同模型服务做对比的开发者。对模型接入机制感兴趣希望通过兼容层理解 API 协议的人。不太适合的场景包括完全零基础且只想“开箱即用”的用户。因为整个切换链路里涉及的 CLI 路径、本地转发层、配置字段都是需要一定命令行基础才能处理好的。需要官方多模态、插件市场、最新特性和稳定支持的生产环境。第三方模型接入通常要靠社区维护遇到问题需要自己排查。对数据敏感的生产场景。因为会话记录、日志、中间转发层都涉及数据流向落地前需要先确认权限和隐私边界。6.4 真正决定长期体验的几件事最后说几个会影响长期体验的点。第一版本。Codex 和 DeepSeek 的 API 都在迭代某次升级后可能突然出现字段不兼容。写配置时最好把版本信息记下来方便回滚。第二字段。不要只看请求是否成功还要看多轮对话、文件操作、工具调用是否正常。Codex 的很多能力依赖额外的上下文字段这些字段在第三方模型上不一定都受支持。第三备份。一切顺利的时候备份看起来没用一旦出了问题备份是唯一的救命绳。第四文档。把每一步配置、每个报错的解决方法记录下来下次再遇到就不用靠回忆了。这段体验真正教会我的不是“怎么把 Codex 切到 DeepSeek”而是“切换模型这个动作背后藏着一整套运行环境的问题”。当你下次面对“聊天记录全没了”类似的提示时先不要慌更不要反复重装。先备份再读日志然后一层层排查。切换模型不是改一个配置的事它是把工具的运行环境、数据路径和模型契约一起换掉的过程。搞懂了这个过程下次再换任何模型都不会再有“数据凭空消失”的错觉。