最近有不少朋友在问这样一件事：把 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 Key；
- Codex CLI，安装方式以官方文档为准，常见是通过包管理器安装，也可以直接下载二进制；
- 一个干净的测试目录，用来验证接入是否成功。
版本方面，不同版本的 Codex CLI 在配置字段上可能有差异，本文给出的配置是通用结构，建议运行codex --help或查看官方文档确认当前版本的字段。
4.2 配置 Codex CLI
Codex 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_KEY="sk-你的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 Support，Windows 下可以检查%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/completions
Codex 默认走的是较新的 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 日常开发中稳定、可靠的后端模型。建议把这篇文章收藏备用，下次切换供应商前翻一遍，能帮你省下不少排查时间。
