如果你最近按照网上的教程，把 Codex 的 API 地址切到了 DeepSeek，重启客户端后猛然发现：之前和 Codex 的官方聊天记录，好像全没了。
先别急着重建会话，也别急着清理缓存。这个问题的答案没有表面看起来那么吓人：记录大概率没有丢，而是 Codex 在“OpenAI 官方连接”和“DeepSeek 自定义连接”之间做了一套会话隔离。切换连接后，界面只展示当前连接下的会话，于是旧记录看起来就像被清空了一样。
这篇文章会把这件事讲透：先解释记录消失的真实原因，再给出 DeepSeek 接入 Codex 的完整配置步骤，然后说明如何找回历史聊天记录。最后，我会把最近大家最常踩的 4 个坑——Codex CLI 找不到、local proxy 返回 400、reasoning_content回传错误、模型 not supported——统一列成对照排查表。文章偏实战，建议收藏后照着操作。
1. 切换 DeepSeek 后，Codex 聊天记录为什么不见了
先还原一个典型场景：你早上还用 Codex 官方账号在项目里调代码、查问题，会话列表里躺着十几次对话。下午为了接入 DeepSeek，按教程修改了 Codex 的配置，把 base_url 指向 DeepSeek 开放平台，重启客户端，结果发现历史会话一条都不剩。
很多人的第一反应是“配置切换把本地数据清掉了”。但从 Codex 的客户端设计逻辑来看，更可能的原因是会话隔离机制在起作用。
Codex 的会话记录并不是一个无序的大列表。它通常会按照“登录账号 + 服务商连接 + 项目上下文”来组织会话视图。当你把 API 地址切换到 DeepSeek，客户端会认为你现在进入了另一个服务提供方的会话环境，因此在界面上只加载这个新环境下的会话。旧会话属于 OpenAI 官方连接，在当前连接下自然不会展示。
这件事可以类比 IDE 里的 Git 分支切换：分支还在，但你的工作区视图会随着 checkout 改变。你不会说“切换分支后文件全没了”，只会说“当前分支的内容不一样了”。Codex 的聊天记录也是同一个道理。
这里要特别提醒一点：如果你在切换配置之后，又顺手执行了“清空缓存”“重置客户端数据”之类的操作，旧会话的恢复难度才会真正变大。如果只是单纯切换配置，一般不会直接摧毁历史记录。
因此，第一步不是去研究怎么恢复数据库，而是先确认你的记录是被“隐藏”了，还是真的被清理了。判断方法也很简单：把你的 Codex 配置切回 OpenAI 官方连接，重新登录官方账号，再打开会话列表。大多数情况下，旧记录会重新出现。
2. Codex 接入 DeepSeek 前需要搞懂的几个基础概念
网上关于“Codex 接入 DeepSeek”的教程很多，但不少教程把概念混在一起讲，导致读者出了问题也分不清是哪一层的问题。这里先厘清几个关键概念。
2.1 Codex 与 Codex CLI
Codex 是 OpenAI 推出的编程助手，形态包括桌面客户端、IDE 插件和命令行工具。Codex CLI 是其中的命令行版本，负责把自然语言任务转化为命令执行或代码修改。当你看到 “unable to locate the codex cli binary” 这类报错时，通常是 GUI 客户端或插件找不到 CLI 可执行文件，属于环境配置问题，与模型本身无关。
2.2 OpenAI 兼容 API
OpenAI 定义了一套 Chat Completions 风格的 HTTP API。很多模型服务商为了降低接入成本，会直接兼容这套接口格式。DeepSeek 开放平台同样提供了 OpenAI 兼容接口，所以 Codex 可以通过修改 base_url、API Key、模型名等方式，把请求转发给 DeepSeek。
2.3 会话隔离
会话隔离是 Codex 客户端对历史记录的加载规则：不同服务商、不同账号、不同项目之间的会话不会混在同一个列表里。这是产品设计上的安全与隔离考虑，避免 A 项目的对话出现在 B 项目的上下文里。切换到 DeepSeek 后看不到旧记录，本质就是这个规则在起作用。
2.4 官方连接与自定义 Provider
Codex 默认使用 OpenAI 官方连接，模型和聊天记录都绑定在官方账号体系之下。当你添加 DeepSeek 作为自定义 Provider，就相当于引入了一套独立配置。在 Codex 的配置体系中，这是两个不同的“连接”，可以共存，但界面默认不会把它们混在一起展示。
下面用一张表对比默认配置和接入 DeepSeek 后的差异：
| 对比维度 | Codex 官方默认 | Codex + DeepSeek 自定义连接 |
|---|---|---|
| 会话存储 | 绑定官方账号与服务端 | 绑定本地配置与当前 Provider |
| 登录方式 | ChatGPT 账号登录 | API Key 鉴权 |
| 模型来源 | OpenAI 官方模型 | DeepSeek 开放平台模型 |
| 历史会话列表 | 展示官方连接下的会话 | 展示 DeepSeek 连接下的会话 |
| 典型适用场景 | 日常使用官方模型 | 在 Codex 中调用 DeepSeek 模型 |
另外，社区里还出现了不少第三方封装工具，比如带界面的 Harness、Hermes 桌面端等。它们的本质是把 DeepSeek 包装成 Codex 可识别的服务。第三方封装在模型 ID、reasoning_content字段处理上差异很大，遇到问题更难排查。本文优先使用官方 Codex CLI + DeepSeek 开放平台 API 的方式，这也是最可控的路径。
3. 环境准备与前置条件
在修改任何配置之前，先把环境准备到位。本文的示例以 macOS / Linux 为主，Windows 用户把路径替换成%USERPROFILE%\.codex即可。
3.1 检查 Node 与 npm 环境
Codex CLI 基于 Node.js 环境安装，建议先确认本机 Node 和 npm 可用。具体版本要求以 Codex 官方文档为准，本文只演示通用思路。
node -v npm -v如果 Node 未安装，需要先安装 Node.js LTS 版本。版本过低可能导致 Codex CLI 安装失败或运行异常。
3.2 安装 Codex CLI
Codex CLI 的常见安装方式是 npm 全局安装：
npm install -g @openai/codex安装完成后，确认命令行可以解析到codex：
codex --version如果提示找不到codex，说明 npm 的全局 bin 目录没有加入 PATH。可以先用下面的命令查看 npm 全局路径：
npm bin -g然后把这个目录加到 shell 的 PATH 中。桌面端如果仍然报 “unable to locate the codex cli binary”，可以把 codex 可执行文件的完整路径通过环境变量CODEX_CLI_PATH指定给客户端，这也是报错信息里提示的核心思路。
3.3 准备 DeepSeek API Key
在 DeepSeek 开放平台注册并创建 API Key。这个 Key 是你调用 DeepSeek 模型的凭证，建议临时导出到当前终端，而不是直接写死在配置文件里：
export DEEPSEEK_API_KEY="sk-你的密钥"3.4 备份 Codex 配置目录
这一步很容易被忽略，但它是整个排障流程里最重要的一步。Codex 的配置通常存放在用户目录下的.codex文件夹中。切换配置前，先做一次整体备份：
cp -r ~/.codex ~/.codex.bak.$(date +%Y%m%d)这样即使后续配置改坏了，也能随时恢复，不会影响历史会话目录。
3.5 验证 DeepSeek API 连通性
在接入 Codex 之前，先用 curl 直连 DeepSeek 接口，确认 Key 和网络都是正常的：
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": "hello"}] }'这里以deepseek-chat为例。实际模型名以 DeepSeek 开放平台文档为准。如果接口返回正常内容，说明 Key 和网络没有问题，可以进入下一步；如果返回 401 或 404，先不要动 Codex，问题多半出在 Key 或 API 地址上。
4. DeepSeek 接入 Codex 的完整配置流程
现在进入正题。整个接入过程的核心，是让 Codex 在发起模型请求时，把流量导向 DeepSeek 的兼容接口，并读取 DeepSeek 的 API Key。
4.1 修改 config.toml 添加 DeepSeek Provider
Codex CLI 的配置文件一般位于~/.codex/config.toml。打开这个文件，在保留原配置的前提下，追加一个 DeepSeek 的 Provider 定义。常见配置形如下面这样：
# 文件路径：~/.codex/config.toml model = "deepseek-chat" model_provider = "deepseek" [model_providers.deepseek] name = "DeepSeek" base_url = "https://api.deepseek.com/v1" env_key = "DEEPSEEK_API_KEY"这里解释一下每个字段的作用：
model：Codex 发起会话时使用的默认模型。model_provider：告诉 Codex 使用哪个 Provider，对应下面定义的[model_providers.deepseek]段。name：Provider 的展示名称。base_url：DeepSeek 兼容接口的地址。以 DeepSeek 开放平台文档为准，部分版本需要带/v1后缀。env_key：Codex 会从该环境变量读取 API Key。这里配置成DEEPSEEK_API_KEY，就要求启动 Codex 前先export DEEPSEEK_API_KEY=...。
如果你的 Codex 版本对 Provider 协议类型有要求，可能还需要补充wire_api = "chat"之类的字段。不同版本配置字段会有差异，建议以当前版本的官方 schema 为准。配置完成后保存文件。
4.2 启动 Codex 并验证调用
回到终端，确保环境变量已生效，然后启动 Codex：
export DEEPSEEK_API_KEY="sk-你的密钥" codex进入交互界面后，可以直接输入一个简单任务来验证：
“用 Python 写一个快速排序，并打印排序结果。”
如果配置正常，Codex 会调用 DeepSeek 模型完成任务。如果这里出现 400、401、404 等错误，说明配置细节有问题，可以跳到第 6 节的排查表对照处理。
4.3 使用 codex exec 做无交互验证
如果你不希望进入交互界面，也可以使用codex exec子命令做一次性验证：
codex exec "用 Python 写一个冒泡排序"这种方式更适合在 CI 或脚本中验证配置，也能更直观地看到报错信息。测试通过后，说明 Codex + DeepSeek 的链路已经打通。
4.4 切换配置时保留官方连接
接入 DeepSeek 并不代表要删除 OpenAI 官方连接。建议在config.toml中保留原有的官方 Provider 配置，只修改默认的model_provider。这样，你想回到官方模型时，只需要把model_provider改回去，或者通过环境变量临时覆盖，不需要重写整个配置。
这里真正容易踩坑的地方是：很多教程让你直接删除或覆盖 config.toml，导致官方登录态和会话目录被破坏。保留原配置、只做增量修改，是更安全的做法。
5. 历史聊天记录的找回步骤
如果你已经完成了上面的配置，现在想找回旧聊天记录，可以按下面的顺序操作。
5.1 切回官方连接查看记录
聊天记录找回的核心思路是：把 Codex 切回 OpenAI 官方连接，再查看会话列表。具体做法是把config.toml中的model_provider恢复为官方默认值，或者直接使用你之前备份的配置：
# 假设备份目录为 ~/.codex.bak.20250101 cp ~/.codex.bak.20250101/config.toml ~/.codex/config.toml然后重新运行codex，登录你的官方账号。会话列表中通常会出现之前的历史记录。此时不要急着再次切换 DeepSeek，先确认记录是否完整。
5.2 检查登录账号与组织
如果你在 Codex 中登录过多个账号，或者公司账号与个人账号混用，历史会话的归属也可能不同。切回官方连接后，在客户端中确认当前登录的账号、组织是否与产生历史记录时一致。组织不一致时，即使切回官方连接，会话列表也可能为空。
5.3 确认会话列表是否存在筛选条件
部分 Codex 客户端会按项目目录或工作区过滤会话。如果你的历史会话是在另一个项目目录下产生的，切换到当前目录后，列表也可能不展示旧记录。可以把目录切回历史项目，再查看会话列表。
5.4 记录确实无法找回时的处理顺序
如果以上步骤都做了，旧记录仍然没有出现，再考虑数据是否真的受损。建议按下面的顺序排查：
- 确认切换期间没有执行过“清空历史”“重置客户端”操作。
- 查看
~/.codex目录的备份文件和日志，确认配置切换的时间点。 - 如果 Codex 配置了云同步或团队托管，联系管理员确认账号数据状态。
需要说明的是，Codex 不同版本的会话存储实现可能不同，部分版本可能把记录放在本地，部分版本依赖账号服务端。具体机制请以官方文档为准。但无论如何，先检查配置切换、再检查登录状态，这个顺序不会错。
6. 常见错误与排查方法
接入 DeepSeek 后，大家提到最多的是下面几个报错。这些问题在社区里反复出现，这里统一列成排查表。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 切换后历史聊天记录消失 | Codex 按 Provider / 账号隔离会话 | 切回官方连接并登录原账号查看 | 恢复原配置或切换回官方 Provider，不要重建会话 |
| unable to locate the codex cli binary | 桌面端 / IDE 插件找不到 CLI 可执行文件 | 在终端执行codex --version确认是否可用 | 设置CODEX_CLI_PATH指向 codex 可执行文件，或重装 CLI 并加入 PATH |
| cc switch local proxy failed while handling codex endpoint /responses | 本地转发层把请求转到 DeepSeek 后返回 400 | 查看 upstream_status 和 cause 字段 | 若 cause 涉及 reasoning_content，关闭 thinking mode 或升级兼容层 |
thereasoning_contentin the thinking mode must be passed back to the api | DeepSeek 推理模型要求多轮中回传推理内容，当前客户端未处理 | 检查是否开启思考模式 | 关闭思考模式，或换用不返回该字段的模型 |
| the 'gpt-5.6-sol' model is not supported | 当前 Provider 不支持请求的模型 ID | 核对 config.toml 中的 model 字段 | 换成 DeepSeek 开放平台支持的模型名 |
| 401 Unauthorized | API Key 错误或环境变量未生效 | 用 curl 直连 DeepSeek 接口验证 | 重新生成 Key，确认DEEPSEEK_API_KEY已导出 |
| 404 Not Found | API Base URL 路径写错 | 核对 DeepSeek 文档中的接口地址 | 修正 base_url，确认是否需要/v1后缀 |
下面单独展开几个最典型的错误，因为它们不是普通的环境问题，而是 Codex 与 DeepSeek 之间的协议兼容问题。
6.1 unable to locate the codex cli binary
这个报错通常出现在 Codex 桌面版或 IDE 插件中，原因是 GUI 启动时找不到 CLI 可执行文件。报错提示里给出了两个方向：设置codex_cli_path，或者把 codex 加入 PATH。
推荐做法是先确认 CLI 是否可用：
codex --version如果可用，记下它的绝对路径，例如/usr/local/bin/codex，然后在桌面端的配置中设置 CLI 路径，或导出环境变量：
export CODEX_CLI_PATH="/usr/local/bin/codex"如果 CLI 本身不可用，先用npm install -g @openai/codex重新安装，再检查 npm 全局 bin 路径。
6.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...。
很多读者看到 “local proxy failed” 就以为是本地代理问题，实际上这里的含义是：Codex 客户端通过本地转发层把请求发给了 DeepSeek，DeepSeek 返回了 400。也就是说，网络链路是通的，问题出在请求内容不符合 DeepSeek 的接口要求。
排查思路是：先看upstream_status。如果是 400，说明上游接口拒绝请求，需要检查请求体是否满足 DeepSeek 的格式要求。再看cause字段，它通常会直接告诉你原因。例如 cause 里出现reasoning_content，就要按后面第 6.3 节处理。
另外，报错中出现的deepseek-v4-flash这类模型名，如果 DeepSeek 开放平台不返回对应该模型的响应，也会导致 400 或 404。遇到这种情况，应去开放平台核对模型 ID，不要使用社区里流传的非官方模型名。
6.3 reasoning_content 必须回传
这个错误是 Codex 调用 DeepSeek 推理模型时最容易遇到的问题。DeepSeek 的部分推理模型在生成回答时，除了正常内容，还会返回一个reasoning_content字段，表示模型的思考过程。在开启 thinking mode 的情况下，后续请求必须把这个字段原样回传，否则接口会返回 400。
错误信息明确写着：the reasoning_content in the thinking mode must be passed back to the api。也就是说，多轮对话中，Codex 或中间封装层没有正确携带这个字段，导致 DeepSeek 拒绝继续生成。
处理方法有两种：
- 在客户端或配置中关闭 thinking mode / 思考模式，让请求不需要回传 reasoning_content。
- 升级 Codex 或更换能正确处理该字段的接入层版本。
不建议为了绕过问题而伪造reasoning_content，因为这会影响模型对上下文的判断，而且接口格式不匹配时依然会报错。
6.4 model not supported
报错原文类似the 'gpt-5.6-sol' model is not supported when using codex with a...。这类问题通常有两种情况：一种是写错了模型名，另一种是当前 Provider 只接受 DeepSeek 自己的模型 ID。
如果是接入 DeepSeek，模型名应使用 DeepSeek 开放平台提供的名称，而不是 OpenAI 模型名。社区里出现的deepseek-v4-flash、gpt-5.6-sol等名称，不一定是官方模型 ID，配置之前务必核对平台文档。
7. 最佳实践与工程建议
Codex 接入 DeepSeek 本身不难，但要在实际项目中稳定使用，建议遵循下面这些工程习惯。
7.1 配置前先备份
无论什么情况下，修改~/.codex配置之前先备份。备份成本极低，但能在配置改坏、会话消失、插件异常时提供一条退路。建议把备份命令写成一行固定脚本：
cp -r ~/.codex ~/.codex.bak.$(date +%Y%m%d_%H%M%S)7.2 使用独立 Profile 或配置段管理多 Provider
不要每次都直接覆盖默认配置。Codex 支持多 Provider 共存，建议把 OpenAI 官方连接和 DeepSeek 连接都保留在配置中，通过model_provider切换。这样切换模型服务商时，不会破坏官方账号的历史会话视图。
7.3 用环境变量管理 API Key
不要在config.toml中明文写入 API Key，更不要把 Key 提交到 Git 仓库。推荐做法是使用环境变量，例如DEEPSEEK_API_KEY，由 Codex 通过env_key字段读取。团队协作时，可以在.env.example中只写变量名，不写真实 Key。
7.4 直连验证 API，避免多层排查
遇到调用错误时，先用 curl 直连 DeepSeek 接口。如果直连成功，说明问题出在 Codex 配置或转发层；如果直连失败，问题在 Key、网络或模型 ID。这个顺序能帮你快速定位问题边界。
7.5 记录报错关键字段
Codex 报错信息里经常包含provider、model、upstream_status、cause这些关键字段。排查时不要只截图，要把这些字段复制下来搜索或记录。很多问题只要看到 cause 就已经知道答案了。
7.6 团队统一配置模板
如果团队多人使用 Codex + DeepSeek，建议统一维护一份经过验证的config.toml模板，明确模型 ID、Base URL、环境变量名，避免每个人用不同的配置，出现问题后互相无法复现。
8. 总结与后续学习方向
回到最初的问题：切换 DeepSeek 后 Codex 官方聊天记录全没了吗？大部分情况下不是。Codex 的会话隔离机制把不同服务商、不同账号的会话分开加载，切换连接后旧记录只是不可见，切回原配置后通常可以恢复。真正需要注意的是，切换前做好~/.codex备份，切换中不要清理缓存，切换后如果记录消失，优先把配置切回原状态再排查。
Codex 接入 DeepSeek 的关键点可以浓缩为三件事：Base URL 是否正确、模型 ID 是否是 DeepSeek 官方模型、是否处理了reasoning_content回传问题。把这三个点核对清楚，Codex + DeepSeek 的组合在大多数场景下就能稳定工作。
后续如果还想深入，可以从三个方向继续研究：一是 Codex 多 Provider 的配置与切换机制，二是 DeepSeek 推理模型与普通对话模型在参数行为上的差异，三是团队环境下如何把模型接入配置标准化。先把备份习惯建立起来，再逐步优化自己的接入方案。
)