最近有不少朋友在问这样一件事把 Codex 接上 DeepSeek 之后打开官方客户端发现之前和 Codex 的聊天记录一条都不剩了。更难受的是终端里紧接着冒出一堆报错什么unable to locate the codex cli binary什么reasoning_content in the thinking mode must be passed back to the api。如果只看视频标题你可能会以为这是某个工具的 Bug甚至担心数据被永久删除了。这里先给一个明确判断绝大多数情况下聊天记录没有被物理删除它只是“看不到了”。切换模型供应商这件事远不止改一个模型名那么简单。它还会改变会话的索引维度、本地存储逻辑、请求走的是哪个 API 端点以及多轮对话里需要回传哪些字段。这篇文章不打算复述视频里的点击步骤而是把背后的原理、验证方法和可落地的恢复步骤讲清楚。读完本文你会明白四件事聊天记录丢失的真实原因是什么如何在一分钟内判断记录是否还能找回如何通过备份和配置管理避免再次丢失以及接入 DeepSeek 后最常见的几个报错到底该怎么处理。整个过程不需要猜也不需要删库重来。1. 为什么要把 Codex 接到 DeepSeek先说动机。Codex 是 OpenAI 生态里的编程智能体既能跑在 CLI 里也能跑在官方桌面客户端里适合让 AI 直接改代码、跑命令、提交 PR。对于重度使用者来说模型调用成本是真实存在的压力。尤其当任务量大、上下文长的时候每轮对话消耗的 token 会迅速累积。DeepSeek 的 API 在接口层面兼容 OpenAI 的消息格式这让“替换模型供应商”成为一个可行的降本方案。很多开发团队甚至直接把 DeepSeek 部署到内网或本地再由 Codex 客户端通过自定义 provider 指向这套服务。这样既保留了 Codex 的交互方式又能在模型成本、数据流向和中文理解效果之间找到平衡点。但这里真正容易踩坑的地方在于Codex 官方客户端和 CLI 的设计目标是围绕 OpenAI 官方模型来工作的。当你把 base_url 指向 DeepSeek把模型名改成deepseek-chat客户端确实能发请求但会话历史、模型参数、字段协议并不会自动跟着切换。于是出现了一类很典型的症状模型能对话但聊天记录不显示官方功能像“半失灵”。所以这篇文章适合三类读者个人开发者希望用 DeepSeek 替代默认模型降低日常编程辅助成本团队负责人正在评估 Codex 私有化 DeepSeek 的组合想提前规避数据和管理风险被视频标题吸引进来的排查者已经切换完、聊天记录消失、报错不断需要一份系统性的排查手册。2. 基础概念Codex、DeepSeek API 与第三方切换工具要把这个问题讲透先分清几个经常被混在一起的概念。2.1 Codex 官方产品和 Codex CLI 不是一回事Codex 这个名称现在覆盖了多个形态ChatGPT 桌面客户端内置的 Codex 功能面向交互式编程任务OpenAI 开源的 Codex CLI一个可以在终端里独立运行的编程智能体第三方客户端通过接入 Codex 的接口协议来实现类似体验。不同的形态数据存储位置和配置方式也不同。官方桌面客户端的聊天记录和 CLI 的会话历史很可能根本不在同一个地方。这也是“聊天记录全没了”的第一个隐患来源用户以为记录在云端实际上它可能只存在于本地某个目录用户以为桌面端和 CLI 共享历史实际上两者各存各的。2.2 DeepSeek API 的 OpenAI 兼容到底兼容到什么程度DeepSeek 开放平台提供了与 OpenAI 格式高度兼容的接口。官方给出的base_url有两种写法https://api.deepseek.com和https://api.deepseek.com/v1使用 OpenAI SDK 时基本可以无缝替换。常见模型名有两个一个是deepseek-chat对应非思考模式的对话模型另一个是deepseek-reasoner对应带推理过程的深度思考模型。后者在响应中会多返回一个reasoning_content字段而且官方要求后续多轮请求中必须把该字段原样回传否则接口会直接返回 400。这个细节就是高频报错the reasoning_content in the thinking mode must be passed back to the api的技术根源。理解这一点的意义在于接入 DeepSeek 不是简单的换 URL模型厂商独有的字段会向上层工具渗透。如果 Codex 或第三方切换工具没有处理reasoning_content请求就会在中途失败。2.3 第三方切换工具做了什么社区里常见的 CC Switch、DeepSeek Harness、DeepSeek Hermes 等工具本质上是两类东西的混合一类是“供应商切换器”帮你快速把 Codex 的配置从 OpenAI 切到 DeepSeek 或其他兼容服务另一类是“本地代理”它在本地启动一个服务拦截 Codex 发出的请求再转发给真实上游。这类工具确实降低了接入门槛但也带来两个问题。第一部分工具会在配置或本地存储中写入自己的索引切换后官方客户端可能无法识别旧数据第二工具内置的模型别名并不一定与上游真实模型一致一旦名称对不上就会触发model not supported一类错误。这里建议把第三方工具定位成“调试辅助”而不是“官方数据层”。聊天记录这类核心资产不能默认由切换工具托管。2.4 角色对比下表可以帮助你快速建立整体认知角色实际功能数据位置聊天记录风险Codex CLI终端编程智能体本地配置目录常见~/.codex切换 provider 后会话列表隔离ChatGPT 桌面客户端官方交互界面系统应用数据目录切换供应商后可能不再读取旧索引DeepSeek API模型推理服务云端本身不管理 Codex 会话CC Switch / Harness / Hermes切换配置或本地代理各自目录或内存可能改写配置、引入模型别名本地部署 DeepSeek自托管模型服务自己的服务器需要保证端点与模型名完全匹配3. 聊天记录“全没了”的真相是被隔离不是被删除3.1 先做两个低成本判断当你说“聊天记录全没了”时先别急着卸载软件按下面两步操作第一步把 Codex 的配置切回原来的 OpenAI 供应商重启客户端再看聊天记录是否恢复。如果恢复了说明数据没有丢只是旧会话和当前供应商配置不匹配客户端没有展示。第二步检查本地数据目录是否存在。Codex CLI 的配置和会话数据通常集中在~/.codex目录桌面客户端的记录则位于系统的应用数据目录中。只要能找到这些目录数据大概率还在。从大量报错案例看90% 的“聊天记录消失”都属于这种情况。会话本身是一条条有元数据的数据记录记录里存着模型供应商、模型名、项目路径、时间戳等信息。切换供应商后客户端会按照新的条件去查会话列表新条件下一条记录都没有页面自然显示为空。你可以把它理解为 IDE 里的多个工作区你在 A 工作区打开过一系列文件切到 B 工作区后文件并没有被删除但编辑器不会把 A 工作区的文件列在 B 工作区的文件树里。3.2 为什么切换供应商会导致会话列表为空Codex 在保存会话时通常会记录这条会话属于哪个 profile、哪个模型供应商、哪个项目目录。当你在 config 里把model_provider从默认 provider 改成 DeepSeek 后新会话会带上一套新的元数据。客户端读取历史时如果按当前 provider 作为过滤条件旧会话就全部被过滤掉了。如果你用的又是第三方切换工具情况会更复杂。切换器可能会在启动时修改 Codex 的配置文件甚至重建本地索引。如果它把配置文件中的模型名、项目路径改成了新的值旧会话与这些字段对不上也会表现为“聊天记录丢失”。还有一个容易被忽略的点如果桌面客户端和 CLI 的会话数据本来就不在一个目录而视频教程只演示了 CLI 的接入方式你打开桌面客户端自然看不到任何 CLI 会话。这是“不同客户端数据源不一致”导致的不是数据丢失。3.3 什么情况下才算真删除真删除的情况相对少见但确实存在切换工具在初始化时自动清理了旧配置目录用户手动执行了清空缓存或卸载重装覆盖了本地存储客户端检测到不兼容的旧索引后自动做了重建。这类场景一旦发生靠界面操作是找不回来的唯一可靠的办法就是备份。所以后面第五节会把“切换前备份”作为一个完整步骤来讲。4. 环境准备与最小配置先跑通再谈迁移无论你是第一次把 Codex 接入 DeepSeek还是已经遇到“聊天记录消失”问题想重新捋一遍都建议按最小可运行方案重新配置一次。4.1 准备工作你需要准备三样东西一个 DeepSeek 开放平台的账号并创建 API KeyCodex CLI安装方式以官方文档为准常见是通过包管理器安装也可以直接下载二进制一个干净的测试目录用来验证接入是否成功。版本方面不同版本的 Codex CLI 在配置字段上可能有差异本文给出的配置是通用结构建议运行codex --help或查看官方文档确认当前版本的字段。4.2 配置 Codex CLICodex CLI 的配置文件通常位于~/.codex/config.toml。下面是一个把模型替换为 DeepSeek 的最小配置# 文件路径~/.codex/config.toml model deepseek-chat model_provider deepseek [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com env_key DEEPSEEK_API_KEY wire_api chat这段配置的关键点有三个。第一model deepseek-chat明确告诉 Codex 使用 DeepSeek 的非思考模型。这样做的原因是先绕开deepseek-reasoner的reasoning_content字段问题把链路跑通。第二base_url指向 DeepSeek 官方地址不需要额外拼接路径。第三env_key DEEPSEEK_API_KEY表示 Codex 会从环境变量读取 API Key而不是把 Key 明文写在配置文件里。这一点很重要尤其当你可能把配置提交到 Git 仓库时。4.3 设置环境变量在终端中执行export DEEPSEEK_API_KEYsk-你的key codex这里有一个常见误解很多人以为配置了env_key就能直接生效实际上还需要在启动 Codex 前把对应环境变量设置好。如果环境变量不存在Codex 会报找不到 Key 的错误。如果你用的是 Windows PowerShell可以用下面的方式$env:DEEPSEEK_API_KEY sk-你的key codex4.4 先用 curl 验证 DeepSeek API不要直接跳到 Codex先用 curl 确认 API 链路本身是通的curl https://api.deepseek.com/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $DEEPSEEK_API_KEY \ -d { model: deepseek-chat, messages: [ {role: user, content: 用一句话介绍 Codex 接入 DeepSeek 的配置要点} ] }如果返回中包含choices字段说明 API Key 和端点都没有问题。此时再启动 Codex你会发现命令能正常完成聊天记录也不会出现异常。这一步的意义在于先验证底层 API再调试上层工具可以把问题范围缩小一半。4.5 通过第三方切换工具接入时的注意点如果你用的是 CC Switch 或类似的切换器需要注意三点模型名一定要确认存在不要盲目使用工具预设的未经验证的别名切换器的“本地代理”模式本质是改配置或转发请求切换后要重启 Codex 客户端切换前先备份配置避免切换器覆盖原有数据。很多“聊天记录全没了”的案例其实是切换器把配置写成了新模型名导致旧会话索引失效。这不是 DeepSeek 的问题也不是 Codex 的问题而是切换流程缺少备份和验证步骤。5. 聊天记录找回与迁移的完整实操5.1 先定位本地数据Codex CLI 的配置和会话数据通常在这个目录下ls -la ~/.codex桌面客户端的记录则要按操作系统查找。macOS 下可以检查Library/Application SupportWindows 下可以检查%APPDATA%。不同设计的产品目录名不同建议在系统应用数据目录下用关键词搜索codex、openai等字段。这里建议直接看客户端自己暴露的存储设置或借助文件系统搜索。如果你完全找不到任何相关目录才需要考虑另一种可能你使用的客户端将数据以加密形式存放在官方账号体系中。这种情况下切换本地代理后客户端不再同步官方历史也会表现出“聊天记录消失”。5.2 切换前强制备份备份是成本最低的保险手段。在切换配置前把整个 Codex 数据目录复制一份cp -r ~/.codex ~/.codex.bak.$(date %Y%m%d)桌面客户端的数据目录也是同样思路。备份文件建议放在项目工作区之外避免被误删。5.3 尝试切换回官方配置找回记录如果你已经发生了“聊天记录消失”最简单直接的办法是切回官方配置codex --profile default或者把config.toml里的model_provider恢复为官方值。重启客户端后如果聊天记录回来了验证工作就完成了。这里要特别提醒在判断“聊天记录是否还在”之前不要反复在多个供应商之间快速切换。每一次切换都可能让新的索引覆盖旧的显示状态频繁切换会让问题更难定位。5.4 备份目录的恢复操作如果切回官方配置仍然看不到历史记录你可以尝试从备份目录恢复# 先确认备份时间点 ls -la ~/.codex.bak.*确认备份文件存在后把当前目录重命名再把备份复制回原位mv ~/.codex ~/.codex.old cp -r ~/.codex.bak.20250101 ~/.codex注意恢复前建议停止 Codex 和桌面客户端避免程序正在写入导致文件冲突。恢复完成后启动客户端检查历史列表。5.5 备份重要对话并迁移到新会话如果你只是想保留某几条关键会话最可靠的方式是直接导出为 Markdown。Codex CLI 里可以查看历史会话并用--continue继续旧对话但前提是当前配置与旧会话的元数据匹配。这意味着迁移到 DeepSeek 之后旧会话可能无法直接继续。一个更工程化的方案是把重要会话内容整理成项目文档放入仓库。这样即使工具本身发生迁移对话里的决策、命令、上下文也已经变成团队资产不再绑定在某一个客户端的会话列表里。5.6 验证恢复结果恢复完成后建议按下面的顺序验证打开官方客户端确认旧聊天记录出现在列表中新建一个会话确认 DeepSeek 模型能正常回复检查~/.codex或系统应用数据目录确认新会话已经写盘切换回 DeepSeek 配置再次确认旧记录仍然被隔离但数据目录没有变小。6. 高频报错逐个排查CLI 找不到、400、模型不支持接入 DeepSeek 之后除了聊天记录问题最常见的是下面几个报错。这些报错往往不是孤立出现而是同一个配置错误在不同环节的表征。6.1unable to locate the codex cli binary这个报错经常出现在桌面客户端启动 Codex 功能时。错误信息里的set codex_cli_path or ensure the elec...说明桌面端的 Codex 功能需要依赖本地安装的 Codex CLI 二进制但应用在当前环境中没有找到它。排查思路如下确认 Codex CLI 已经正确安装在终端中执行codex --version确认桌面客户端的 PATH 环境变量中包含 codex 所在目录在应用的配置中指定codex_cli_path指向实际二进制位置修改后重启桌面客户端。这个错误和 DeepSeek 没有直接关系但很多人是在切换供应商后第一次打开桌面端 Codex 才发现这个问题的所以容易被误认为是接入 DeepSeek 导致。6.2reasoning_content in the thinking mode must be passed back to the api这个报错是 DeepSeek 思考模型的特有问题。当使用deepseek-reasoner时API 会在回复里返回reasoning_content字段而官方要求后续轮次的请求里必须把上一次的reasoning_content原样传回。Codex 或本地代理不会自动处理这个字段于是第二次请求就直接 400。处理方案有三种如果不需要深度思考能力把模型改成deepseek-chat不使用 reasoning 模型如果必须使用deepseek-reasoner则让代理层自动处理reasoning_content的回传检查配置中的wire_api确认走的是chat端点而不是未经适配的responses端点。这句话单独理解可能有些抽象你可以把它类比成一次需要“回忆上下文”的对话服务方要求你把上次思考过程一起带回来但客户端只记住了结果没记住过程于是第二次沟通直接被拒绝。deepseek-chat没有这个额外要求所以接入成本低得多。6.3model not supported/ 模型别名不存在Codex 或第三方切换工具报model not supported通常是配置里写的模型名在当前供应商中不存在。这个问题的典型场景是工具预设了某个模型别名但该别名对应的上游接口并不是 DeepSeek 官方模型。处理方式在 DeepSeek 开放平台文档中确认当前可用模型名把config.toml中的model改成官方模型名如果使用的是 CC Switch 等工具检查工具的模型映射表确认deepseek-chat真的被映射到了正确的上游模型不要使用来源不明的模型 ID比如某些视频里随口提到的非官方模型名。6.4 端点相关错误/responses与chat/completionsCodex 默认走的是较新的 Responses API 结构社区里部分切换工具也只转发了这个端点。如果你在错误信息里看到endpoint /responses说明请求打到了/responses但 DeepSeek 官方提供的是/chat/completions。解决思路在 Codex 配置中把wire_api指定为chat让请求走 OpenAI Chat Completions 风格如果切换工具强制走/responses需要确保工具内部做了协议转换使用 curl 直接请求 DeepSeek 的/chat/completions先确认上游是正常的再回到 Codex 排查。6.5 常见问题汇总下面这个表格可以收藏备用问题现象可能原因排查方式解决方案聊天记录不显示provider/profile 切换导致会话元数据不匹配切回原配置查看记录是否恢复统一 profile切换前备份桌面端找不到 codex cli未安装 CLI 或 PATH 未配置终端执行codex --version安装 CLI设置codex_cli_path请求 400提示 reasoning_content使用了deepseek-reasoner未回传字段查看报错中的模型名改用deepseek-chat或升级代理层提示 model not supported模型名在该供应商不存在在开放平台文档确认模型名将model改为官方模型名请求走了 /responses 但上游不支持Codex 默认协议与兼容层不匹配检查wire_api字段或代理日志设置wire_api chat切换工具导致配置被覆盖第三方切换器重写了 config.toml对比切换前后配置文件切换前备份切换后人工检查配置7. 最佳实践与工程建议7.1 用 profile 管理多供应商不要手动改全局配置Codex CLI 支持不同的 profile 配置。建议把官方默认配置定义为一个 profile把 DeepSeek 配置定义为另一个 profile。这样切换供应商不是“改配置文件”而是“切换 profile”会话和管理逻辑都会清晰很多。比如针对 DeepSeek 的 profile配置里明确写死模型名和 base_url。切换前只需要执行对应的 profile 命令不用手动逐行改配置。7.2 API Key 一律走环境变量不要把 Key 直接写在config.toml或提交到 Git。配置中只用env_key引用环境变量。团队协作时可以通过临时环境变量注入而不是共享一份含密钥的配置文件。7.3 接入前先做 API 连通性验证任何可视化工具接入之前先执行一次curl调用确认 API Key、模型名、参数格式全部正确。这个习惯可以帮你把“模型问题”和“工具问题”快速分离。7.4 备份要成为切换动作的默认环节无论从 OpenAI 切到 DeepSeek还是从 DeepSeek 切回官方执行前先备份数据目录。备份命名带上时间戳避免和旧备份混淆。很多“聊天记录全没了”的求助帖最后发现是没备份导致无法恢复非常可惜。7.5 谨慎使用第三方切换工具第三方工具方便但不是所有工具都会正确处理reasoning_content、/responses和模型别名。使用前先在测试环境验证不要把生产环境的核心配置直接交给未验证的工具改写。如果团队中有多人使用 Codex建议统一工具版本并把验证通过的配置沉淀到团队文档中。7.6 注意安全边界Codex 接上 DeepSeek 之后本质上你是在让一个编程智能体访问你的代码仓库和本地命令。无论选择哪家模型都要注意API Key 只授予最小必要的权限不要让测试用的 Key 拥有生产环境的写权限本地代理工具如果需要监听端口确认只监听本机地址涉及敏感代码或生产环境变更时不要直接让 AI 执行高风险命令。这些不是 DeepSeek 特有的问题而是接入任何模型供应商都必须遵守的工程底线。8. 总结接入 DeepSeek 的正确姿势回到开头的问题切换 DeepSeek 后Codex 官方聊天记录全没了该怎么办答案可以归纳成一句话先确认是“隔离”还是“删除”再决定是“切回去”还是“恢复备份”。90% 的情况聊天记录没有真正丢失只是切换供应商后会话列表的查询条件变了。验证方法也很简单切回原配置看记录是否恢复即可。为了防止以后再遇到类似问题建议把这三件事变成固定习惯切换前备份~/.codex和桌面客户端数据目录用 profile 管理不同的模型供应商而不是频繁手工改配置接入 DeepSeek 时优先选择deepseek-chat绕开reasoning_content字段的兼容问题。Codex 接入 DeepSeek 的技术价值很明显它让开发者可以用更低成本、更可控的方式运行编程智能体同时保留 Codex 强大的终端交互体验。但它也提醒我们任何“换个模型供应商”的操作都不仅仅是换个 URL而是涉及会话存储、协议字段和工具链兼容性的一次小规模迁移。把这些细节处理好DeepSeek 完全可以成为 Codex 日常开发中稳定、可靠的后端模型。建议把这篇文章收藏备用下次切换供应商前翻一遍能帮你省下不少排查时间。
