ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

Codex切换DeepSeek后聊天记录消失?一文教你恢复与配置

Codex切换DeepSeek后聊天记录消失?一文教你恢复与配置 这次我们聊一个很实际的坑很多开发者把 Codex CLI 或 Codex 官方客户端从默认 OpenAI 模型切到 DeepSeek API 后再打开界面发现之前的聊天记录全没了界面空白得像刚安装一样。有人以为是切换时把本地数据删了有人干脆重装客户端结果把自己保存的配置文件也一起弄丢了。先说结论在绝大多数情况下聊天记录不是被物理删除而是 Codex 在“换模型提供商”之后会话索引、配置目录或数据入口发生变化导致旧会话不被读取。换回原配置记录往往还在选对恢复方式记录也能找回来。这篇文章会围绕“Codex 切换 DeepSeek 后聊天记录消失”这个具体问题展开内容包括会话文件查找、历史记录恢复、DeepSeek 接入配置、常见报错排查以及一套防止再次翻车的备份方案。如果你正在使用 Codex CLI、VSCode 里的 Codex 插件或者通过 CC Switch、各类 harness 桌面端把模型切到 DeepSeek这篇可以直接收藏。1. 核心问题与能力速览先把问题现象、可能原因和解决方向整理成一张表方便快速定位现象可能原因解决方向切换 DeepSeek 后聊天记录全没了provider 或模型标识变化Codex 会话索引对不上旧记录确认会话文件是否还在优先备份再尝试恢复配置打开第三方桌面端后看不到历史会话桌面端使用独立数据目录不读官方 CLI 的配置确认桌面端读取的是哪个配置目录必要时切回官方入口启动时提示某个模型不受支持配置里还保留 OpenAI 系默认模型名把模型名改为 DeepSeek 开放平台实际支持的模型名请求返回 400提示 reasoning_content 必须回传使用了推理模型但 Codex 或兼容层没有回传思维链内容改用非推理模型或关闭 thinking mode提示找不到 codex cli 二进制文件第三方工具没有正确指定 Codex CLI 路径在工具配置里填写 codex 可执行文件路径CC Switch 切换后 local proxy failed本地代理启动失败或转发参数不对检查本地代理端口、API Key、模型名和 base_url为什么那么多人要把 Codex 切到 DeepSeek核心原因是成本和接口兼容性。Codex 对编码类任务体验不错但默认模型在高频使用时 token 消耗很快DeepSeek API 的定价低且提供 OpenAI 兼容格式社区里因此出现了大量“Codex 接入 DeepSeek”的教程和工具。这个需求本身没问题但模型切换不是简单改一行 base_url它涉及会话索引、模型名、协议字段等细节一步没配对就会造成“记录全没了”的观感。2. 切换 DeepSeek 后聊天记录为什么会消失聊天记录“消失”背后至少有四种常见机制。理解了这四点就不会再盲目重装。2.1 会话索引与模型标识绑定Codex 的会话列表并不是简单读取一个文本文件就万事大吉。它通常会把会话元数据、模型标识、项目路径组合成索引再在界面或 CLI 列表里展示。当你把model_provider从 OpenAI 切成 DeepSeek会话列表加载时发现“这条会话对应的模型标识在当前配置里已经不存在”就可能直接把旧会话过滤掉界面看起来就是空的。这种情况最容易恢复。只要把模型提供商切回原来的 OpenAI 配置或把模型名写成旧会话使用的名称历史记录就会重新出现在列表里。2.2 第三方切换工具改写了配置入口很多用户会通过 CC Switch、harness 类桌面端来切换 Codex 的底座模型。这类工具的原理通常是生成或覆盖 Codex 的配置文件把 base_url、模型名、API Key 替换成 DeepSeek 的有时还会启动一个本地代理把 Codex 的请求转发到 DeepSeek 接口。问题就在这里部分切换工具不读取官方 Codex 的原始配置而是维护一份自己的配置副本或者把配置写进了另一个目录。切换后官方客户端看到的是新的空配置自然找不到旧会话。而当你把配置切换回原来的选项时旧聊天记录通常又会回来因为原始配置文件并没有被删除。2.3 Codex 按项目目录隔离会话很多用户没有注意到Codex 的会话记录是项目级的。在某个目录里开启会话和另一个目录里开启的会话默认不会出现在同一个历史列表里。如果你之前一直在/project-a里用 Codex切换 DeepSeek 后为了测试进到了一个新的空目录看到的自然是没有历史记录的新会话列表。这时只要回到原来的项目目录历史记录会重新出现。不要在一个新目录里反复寻找旧会话那不是数据丢失是目录隔离。2.4 部分桌面端使用独立存储官方 Codex CLI 的历史记录通常存放在本地配置目录里但第三方桌面端未必读取同一份数据。部分工具为了做到多模型管理会把自己生成的历史会话放到独立目录或者只展示“当前 profile 下”的会话。这种情况下你需要在第三方工具里找到“配置目录”“存储位置”或“数据目录”选项确认它指向的是不是官方~/.codex目录。如果工具强制使用自己的目录旧会话就只能回到官方 CLI 里查看不能在桌面端里直接合并显示。3. 先找回聊天记录检查 Codex 本地会话文件遇到“聊天记录全没了”第一件事不是卸载重装而是检查本地会话文件是否还在。只要 jsonl 或等价格式的会话文件还在记录就还在。3.1 定位 Codex 配置目录在 macOS / Linux 上Codex 的配置目录一般位于用户主目录下在 Windows 上则在用户主目录下的隐藏目录里。不同版本可能略有差异常见路径如下# macOS / Linux 常见位置 ls -la ~/.codex# Windows 常见位置实际路径以你的版本为准 Get-ChildItem $env:USERPROFILE\.codex如果这两个路径都不存在说明你的 Codex 版本把数据放在其他位置。可以在终端里执行codex --version确认正在使用的版本再按版本号去查对应的配置目录说明。3.2 查找会话记录文件Codex 的历史会话通常以 jsonl 文件保存。在配置目录里执行以下命令可以快速找到所有会话文件find ~/.codex -name *.jsonl -type f 2/dev/null | head -50如果看到输出说明本地会话数据仍然存在只是 Codex 界面没有加载出来。3.3 确认记录内容是否还在找到 jsonl 文件后可以搜索关键词确认会话内容里是否包含你之前和 Codex 的对话# 在 .codex 目录里搜索某个你在历史会话中写过的关键词 grep -rl 你之前输入过的某个关键词 ~/.codex 2/dev/null | head -20如果文件里有匹配内容基本可以确定旧会话没有被删除。3.4 恢复方式确认数据还在之后优先用下面两种方式恢复第一切回原来的模型提供商。如果你用的是官方客户端或 CLI在配置里把 provider 切回 OpenAI模型名改回旧会话使用的模型重新打开列表大概率能恢复历史记录。第二指定工作目录。如果你只是在新的项目目录里找不到历史回到原来使用 Codex 的项目目录在同一个目录下启动 Codex旧会话就会重新加载。操作之前建议先备份整个 Codex 配置目录避免后续配置过程中误覆盖# macOS / Linux 一键备份 cp -r ~/.codex ~/.codex.backup.$(date %Y%m%d)# Windows PowerShell 一键备份 Copy-Item -Path $env:USERPROFILE\.codex -Destination $env:USERPROFILE\.codex.backup -Recurse备份完成后再去做切换、改配置之类的操作即使出问题也能随时回滚。4. DeepSeek 接入 Codex 的推荐配置如果你确认聊天记录不是真丢接下来就是让 Codex 稳定使用 DeepSeek。这里给出一套在社区里广泛使用的配置思路。4.1 准备 DeepSeek API Key先去 DeepSeek 开放平台注册账号创建 API Key。注意这个 Key 有额度限制创建后只显示一次要自己保存好。不要把 Key 写进代码仓库或直接贴在共享文档里。4.2 修改 Codex 配置文件Codex 的配置文件通常也是~/.codex下的config.toml。下面是一份兼容 OpenAI 协议接入 DeepSeek 的配置模板实际字段以你安装的 Codex 版本支持情况为准# 切换模型提供商为 DeepSeek 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这段配置的意思是全局模型使用deepseek-chat模型提供商指向一个名为deepseek的自定义 providerAPI 地址指向 DeepSeek 接口API Key 从环境变量DEEPSEEK_API_KEY读取。如果你在 Codex 里本身没有自定义过模型供应商社区里的通行做法是将其命名为deepseek然后在model_providers下面注册它。4.3 配置环境变量在终端启动 Codex 之前先设置环境变量# macOS / Linux export DEEPSEEK_API_KEYsk-你的key# Windows PowerShell $env:DEEPSEEK_API_KEY sk-你的key设置完成后再启动 Codex。这样 API Key 不会直接写死在config.toml里相对更安全。4.4 模型名怎么选DeepSeek 开放平台在不同时期提供的模型名不完全一样。从公开资料看deepseek-chat是常见的通用对话模型名deepseek-reasoner则是推理模型名。具体以 DeepSeek 开放平台当前页面展示的模型名为准不要凭记忆硬填。有一个很容易踩的坑Codex 默认配置里可能保留 OpenAI 系模型名比如社区截图里出现过形如gpt-5.6-sol之类的名称。接入 DeepSeek 后如果不把模型名改成 DeepSeek 支持的名称请求会被拒绝报错信息里就会提示当前模型不支持。4.5 第三方桌面端指定 Codex CLI 路径如果你用的是桌面端或 VSCode 插件还要确认它能否找到 Codex CLI。很多报错都指向同一个问题工具没有定位到 codex 可执行文件提示 “unable to locate the codex cli binary”。通常需要在工具的设置里手动指定 codex 的路径。比如通过 npm 全局安装时可执行文件可能位于 npm 全局 bin 目录下如果使用npx openai/codex方式则需要让工具能找到 npx 的调用链。不同工具设置项名称不一样找类似 “Codex CLI Path” 的入口即可。5. 常见报错与排查方法这里把搜索热词里频繁出现的几个 Codex 接入 DeepSeek 报错集中列出每个都直接给排查思路。5.1 unable to locate the codex cli binary这个报错在 VSCode 插件、第三方桌面端里高频出现。检查项说明是否安装了 Codex CLI在终端执行codex --version如果提示找不到命令则未安装或未加入 PATH安装方式如果通过 npm 安装确认全局 bin 目录已加入 PATH工具设置在插件设置里指定 codex 可执行文件的绝对路径解决先把 Codex CLI 在系统终端里能正常启动再重新启动第三方工具。5.2 cc switch local proxy failed这个报错信息比较长常见形态是 local proxy failed while handling codex endpoint。出现这个报错时说明 CC Switch 这类切换工具已经启动了一个本地代理Codex 的请求先到本地代理再由代理转发到 DeepSeek 接口但转发失败。排查重点本地代理端口是否被占用。切换工具的日志里一般会显示监听端口如果和别的服务冲突换一个端口。DeepSeek 的 API Key 是否填写正确。模型名是否已改成 DeepSeek 支持的模型名。base_url 是否指向 DeepSeek 的官方接口地址。5.3 模型名 not supported报错内容通常类似“某个模型名 is not supported when using Codex with a provider”。原因是把 Codex 默认模型名带到了 DeepSeek 配置里。解决把model改为 DeepSeek 开放平台实际支持的模型名例如deepseek-chat。不确定时先去平台页面确认当前可用模型列表。5.4 reasoning_content 必须回传这个报错值得一提它经常出现在使用推理模型时。DeepSeek 推理模型在返回结果时会附带思维链内容如果接入层没有把这个内容原样保存并在后续多轮请求中回传DeepSeek 接口会返回 400提示类似 reasoning_content in thinking mode must be passed back 的信息。解决方式改用非推理模型比如deepseek-chat避开思维链字段回传要求。或者在兼容层关闭 thinking mode。不要在 Codex 里强行配置推理模型做长会话除非兼容层已经处理了字段回传。5.5 鉴权失败或 401/403Codex 请求返回 401/403通常是 API Key 无效或环境变量未生效。判断方法先用 curl 直接请求 DeepSeek 接口确认 Key 是否有效。如果 curl 能通但 Codex 不通说明 Codex 侧的环境变量或配置读取有问题检查env_key是否配置正确、环境变量是否在启动 Codex 前设置。5.6 端口冲突或代理残留切换工具启动的本地代理如果上一次没有正常退出这次启动时会提示端口被占用。解决方式是找到残留进程并结束或者把工具的本地代理端口改成其他值。6. 接口连通性与批量自动化思路Codex 接入 DeepSeek 后建议先独立验证 DeepSeek API 的连通性再回到 Codex 里做功能测试。6.1 用 curl 验证 DeepSeek API下面是一个使用环境变量传入 API Key 的 curl 示例适合在做任何集成之前先确认 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}], stream: false }如果返回内容里包含模型的回答说明 Key 和模型名都可用。这里的接口地址和模型名以 DeepSeek 开放平台实际提供的信息为准。6.2 把备份和切换做成脚本换模型这件事本身不复杂但重复手工操作容易出错。建议把备份、环境变量设置、启动 Codex 整合成一个脚本以后每次切换都走同一套流程。下面是一个简单的 bash 备份示例#!/usr/bin/env bash # Codex 配置备份脚本放到 crontab 里可以定期执行 BACKUP_DIR$HOME/codex-backups mkdir -p $BACKUP_DIR tar -czf $BACKUP_DIR/codex-$(date %Y%m%d%H%M).tar.gz -C $HOME .codex 2/dev/null echo backup done: $BACKUP_DIRWindows 用户可以写一个 PowerShell 脚本把.codex目录复制到带日期的备份目录原理相同。6.3 批量场景下如何管理会话如果你经常用 Codex 处理多个项目建议每个项目固定使用默认的项目目录不要为每个小任务新建随机目录。Codex 的会话按项目隔离目录固定历史记录才能稳定聚合。如果是自动化批量任务可以在脚本里调用 Codex CLI但要把每次任务的输入输出分开保存最好把生成结果纳入 git 管理。这样即使 Codex 侧的会话索引出问题你仍然有一份代码级别的完整备份。7. 资源占用与运行稳定性观察Codex 是 CLI 工具不是本地大模型所以它本身不占显存。主要观察的是终端进程的内存占用、API 请求延迟和长会话稳定性。启动 Codex 后可以在系统任务管理器或终端工具里观察codex进程的 CPU 和内存占用。正常情况下等待用户输入时进程几乎不占 CPU执行编码任务时会出现一段 CPU 波动因为本地有代码解析、提示词组装等逻辑。切换 DeepSeek 后稳定性重点看两点请求延迟。DeepSeek API 的响应速度会影响 Codex 每一步的等待时间。如果某个任务经常超时先把单次请求的模型参数调小或者缩短输入上下文。长会话 token 膨胀。Codex 在长对话里会把历史消息不断带上token 数量增长到一定程度后请求会变慢甚至超出模型上下文限制。遇到这种情况可以开启新会话把关键结论手动粘过去而不是在一个会话里无限继续。另外提醒一点如果通过 CC Switch 本地代理转发代理进程本身也会占用少量内存。代理崩溃、端口冲突都会表现为 Codex 请求失败这时候先去切换工具里看代理日志比反复改 Codex 配置更有效。8. 最佳实践与合规提醒先备份再操作。任何切换模型、修改 provider、升级 Codex 的操作都先备份~/.codex或%USERPROFILE%\.codex。API Key 不进仓库。不要在代码里写死 Key使用环境变量或本机密钥管理工具。如果 Key 意外泄露及时到 DeepSeek 开放平台吊销重建。敏感代码谨慎发送。把 Codex 接入第三方 API 后代码片段、业务逻辑、内部注释都会被发送到模型服务端。涉及商业敏感或隐私数据时先确认是否符合公司规范不要直接把核心代码塞进对话。测试先行。正式批量使用之前先用一个空项目验证 DeepSeek 的模型名、Key、base_url 都正确不要一上来就把所有项目切到新配置。版权合规。让 AI 生成代码本身没问题但如果要把生成结果商用要确认模型服务条款和你所在机构的规定。授权边界。如果是团队共享的 Codex 或切换工具账号不要让多人共用一个 API Key避免产生异常额度和使用纠纷。9. 总结Codex 切换 DeepSeek 后聊天记录“全没了”大多数情况下是会话索引、配置目录或项目目录错位造成的不是真实删库。先备份~/.codex再用find和grep确认 jsonl 会话文件是否还在然后在原配置目录、原模型标识、原项目目录下恢复基本都能找回来。后续接入 DeepSeek 时把模型名、base_url、API Key、本地代理端口都检查清楚尤其是“reasoning_content 必须回传”这类协议细节直接决定推理模型能不能在 Codex 里跑通。日常使用里建立固定项目目录和备份脚本比任何恢复技巧都省心。
返回列表