如果你最近按照网上的教程把 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 CLICodex 是 OpenAI 推出的编程助手形态包括桌面客户端、IDE 插件和命令行工具。Codex CLI 是其中的命令行版本负责把自然语言任务转化为命令执行或代码修改。当你看到 “unable to locate the codex cli binary” 这类报错时通常是 GUI 客户端或插件找不到 CLI 可执行文件属于环境配置问题与模型本身无关。2.2 OpenAI 兼容 APIOpenAI 定义了一套 Chat Completions 风格的 HTTP API。很多模型服务商为了降低接入成本会直接兼容这套接口格式。DeepSeek 开放平台同样提供了 OpenAI 兼容接口所以 Codex 可以通过修改 base_url、API Key、模型名等方式把请求转发给 DeepSeek。2.3 会话隔离会话隔离是 Codex 客户端对历史记录的加载规则不同服务商、不同账号、不同项目之间的会话不会混在同一个列表里。这是产品设计上的安全与隔离考虑避免 A 项目的对话出现在 B 项目的上下文里。切换到 DeepSeek 后看不到旧记录本质就是这个规则在起作用。2.4 官方连接与自定义 ProviderCodex 默认使用 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 CLICodex CLI 的常见安装方式是 npm 全局安装npm install -g openai/codex安装完成后确认命令行可以解析到codexcodex --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_KEYsk-你的密钥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 ProviderCodex 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这里解释一下每个字段的作用modelCodex 发起会话时使用的默认模型。model_provider告诉 Codex 使用哪个 Provider对应下面定义的[model_providers.deepseek]段。nameProvider 的展示名称。base_urlDeepSeek 兼容接口的地址。以 DeepSeek 开放平台文档为准部分版本需要带/v1后缀。env_keyCodex 会从该环境变量读取 API Key。这里配置成DEEPSEEK_API_KEY就要求启动 Codex 前先export DEEPSEEK_API_KEY...。如果你的 Codex 版本对 Provider 协议类型有要求可能还需要补充wire_api chat之类的字段。不同版本配置字段会有差异建议以当前版本的官方 schema 为准。配置完成后保存文件。4.2 启动 Codex 并验证调用回到终端确保环境变量已生效然后启动 Codexexport DEEPSEEK_API_KEYsk-你的密钥 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 并加入 PATHcc 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 apiDeepSeek 推理模型要求多轮中回传推理内容当前客户端未处理检查是否开启思考模式关闭思考模式或换用不返回该字段的模型the gpt-5.6-sol model is not supported当前 Provider 不支持请求的模型 ID核对 config.toml 中的 model 字段换成 DeepSeek 开放平台支持的模型名401 UnauthorizedAPI Key 错误或环境变量未生效用 curl 直连 DeepSeek 接口验证重新生成 Key确认DEEPSEEK_API_KEY已导出404 Not FoundAPI 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 客户端通过本地转发层把请求发给了 DeepSeekDeepSeek 返回了 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 推理模型与普通对话模型在参数行为上的差异三是团队环境下如何把模型接入配置标准化。先把备份习惯建立起来再逐步优化自己的接入方案。