切换 DeepSeek 后Codex 官方聊天记录全没了先别急着重装客户端。这类问题最近出现频率很高我前后也踩过两次最后发现代码一条没丢记录文件也还在只是 Codex 的会话列表把新旧 provider 的历史隔离开了。Codex 默认把会话写在本地.codex/sessions目录并按模型提供方存放。切到 DeepSeek 之后界面去读的是 DeepSeek 对应的会话目录旧目录自然就显示为空。你真正要做的是两件事把两套会话目录理顺把 DeepSeek 的接入参数配到不报错。下面按实测顺序拆。1. 先搞清楚 Codex 的历史记录到底存在哪里1.1 会话文件不是云端同步而是本地 JSONL很多人以为 Codex 的聊天记录和 ChatGPT 网页一样存在云端切到 DeepSeek 后还能通过同一个账号找回。实际情况不是这样。Codex CLI 的会话记录默认落在本地目录而且是一行一行的 JSONL 文件里面记录了用户输入、助手输出、工具调用、耗时这些内容。在 macOS 和 Linux 上默认路径是~/.codex/sessions在 Windows 上一般是%USERPROFILE%\.codex\sessions如果你设置过CODEX_HOME环境变量那么所有配置和会话都在你指定的目录里不在这两个默认位置。执行下面的命令能看到会话目录的实际结构ls -la ~/.codex/sessions/常见版本里这个目录下会按 provider 再分一层子目录子目录里才是具体的会话 JSONL 文件。也就是说OpenAI 默认配置产生的记录、DeepSeek 配置产生的记录会被放进不同的 provider 子目录。这里容易踩的第一个坑是凭记忆去猜目录名。不同版本的 Codex 对 provider 子目录的命名不太一样有的是openai有的是openai-responses还有的是自定义 provider 名。先ls看清楚再继续下一步。1.2 为什么切换后界面显示“全没了”Codex 客户端、VS Code 扩展、社区桌面壳在展示会话列表时只会读取当前生效 provider 对应的会话目录。你把默认模型切到 DeepSeek 后config 里的 model_provider 变了界面就改去读 DeepSeek 那个子目录。这个目录如果是空的或者刚创建列表自然是空的。所以这不是“官方聊天记录被清空”而是“当前 provider 的会话目录里没有旧数据”。还有一点要明确第三方 provider 的对话不会进入 OpenAI 的云端历史。DeepSeek 的接口返回什么Codex 就记什么所有内容都停在本地。本地文件只要还在恢复就有戏。2. 切换 DeepSeek 前先备份会话目录别把恢复寄托在别人身上2.1 一条命令把整个 sessions 目录带走无论你用的是官方 Codex 还是社区桌面壳切换 provider 前最值得做的动作就是备份sessions目录。备份命令很简单macOS / Linux 用cp -r ~/.codex/sessions ~/.codex/sessions_backup_$(date %Y%m%d)Windows PowerShell 用Copy-Item -Path $env:USERPROFILE\.codex\sessions -Destination $env:USERPROFILE\.codex\sessions_backup_20250101 -Recurse备份的意义不只是防聊天记录丢失还防配置工具误操作。比如某些本地切换工具在切换 provider 时会重写 config.toml甚至清理或迁移会话目录。你手动留一份后面就能拿最原始的文件做对比。我一般会备份两份一份整个.codex目录一份单独的sessions。原因很简单.codex里还有 config.toml、auth.json、日志等文件排查问题时要看上下文只备份 sessions 并不够。2.2 备份前先确认 CODEX_HOME 和目录大小备份之前先确认 Codex 到底在哪个目录工作echo $CODEX_HOME ls -la ~/.codex如果CODEX_HOME有值备份目标要跟着变。直接备份~/.codex可能备份了一堆无关旧文件真正在用的却在你设置的自定义目录里。还要看一眼 sessions 目录占用多大du -sh ~/.codex/sessions如果只有几百 KB说明会话量不大复制很快。如果有几百 MB多半是长期使用且图片、日志内容很多复制时要有耐心不要中途关终端。3. 接入 DeepSeek 的配置链路越简单越稳3.1 最小可运行的 config.toml 示例Codex 接入 DeepSeek 的本质是告诉 Codex 去请求哪个 base_url、用哪个密钥、按哪种协议解析响应。最小配置一般在~/.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 wire_api chat四个字段各有用意model当前会话默认使用的模型名DeepSeek 的对话类模型可以先用deepseek-chat这类常规模型验证链路。model_provider指定走下面哪个 provider 配置必须和[model_providers.deepseek]名字一致。base_url接口地址。不同 provider 可能要求带/v1也可能不带以实际文档为准。env_keyCodex 读取密钥的环境变量名。这里配了DEEPSEEK_API_KEY你就需要提前在终端或系统环境变量里设置它。wire_api协议类型。DeepSeek 的官方兼容端点以 chat completions 为主所以示例里用chat。社区里也有人把wire_api配成responses但这要看你的 provider 或本地转发服务到底支不支持/responses端点。如果刷出来的报错是cc switch local proxy failed while handling codex endpoint /responses上游返回 400那多半就是端点不匹配。先改成chat再试通常能避开这个坑。配置完成后先跑一条最简单的请求验证curl https://api.deepseek.com/v1/chat/completions \ -H Authorization: Bearer $DEEPSEEK_API_KEY \ -H Content-Type: application/json \ -d {model:deepseek-chat,messages:[{role:user,content:你好}]}如果返回正常 JSON 且有回复内容说明密钥、模型名、base_url 都没问题。如果返回 401先查环境变量有没有正确设置如果返回 400先查模型名是不是不存在。3.2 VS Code 扩展和桌面端找不到 codex cli 的修复接入 DeepSeek 过程中很常见的一个报错是unable to locate the codex cli binary. set codex cli path or ensure the electron...这个报错和 DeepSeek 本身没关系是扩展或桌面壳找不到 Codex CLI 的可执行文件。Codex 的 VS Code 扩展和部分桌面客户端本质上是把任务交回给本地的 codex 命令去执行找不到二进制文件界面自然启动不了。先从命令行确认 codex 装在哪which codexWindows 用where codex如果命令输出为空说明 Codex CLI 还没装。常见安装方式是npm install -g openai/codex具体包名和安装方式以你当前版本的官方说明为准不要在别人配置里复制一段安装命令就闷头装。如果命令行能找到 codex但扩展还是报错就在 VS Code 的扩展设置里找 CLI Path 相关选项把which codex输出的绝对路径填进去然后重新加载窗口。填完之后先跑一次最简单的对话确认扩展能正常调用 CLI再切到 DeepSeek 模型上测试。4. 聊天记录恢复的三种实操方案4.1 方案一切回原 provider用 CLI 的 resume 找回如果你只是想找回某一段重要对话最快的方法是暂时把 config 切回原来的 provider然后使用 Codex CLI 的会话恢复能力。常见版本里命令行执行codex resume会列出最近的会话。找到目标会话后直接在里面翻看内容把需要的上下文复制出来。这个方法不需要改目录、不用动文件风险最低。切回原 provider 时注意只要 config.toml 里的 model 和 model_provider 改回去界面会话列表基本上就会恢复。找回内容后再决定要不要切回 DeepSeek。4.2 方案二把旧 provider 会话目录复制到当前 provider 下如果你确定旧会话文件在~/.codex/sessions/旧provider名下面而当前界面读的是~/.codex/sessions/deepseek可以尝试把文件复制过去cp -r ~/.codex/sessions/旧provider名 ~/.codex/sessions/deepseek复制前先确认目标目录名可以通过ls ~/.codex/sessions/查看实际命名不要想当然。这个方案有一个要注意的点复制之后界面上的会话列表可能能看到了但某些版本在恢复时会检查会话的 provider 和模型信息。如果发现恢复不了或者恢复后行为异常不要继续改文件回到方案一更稳妥。复制操作建议只做“追加”不要删除原目录。目录名改成 provider 名容易改回去就很难还原状态。4.3 方案三直接打开 JSONL 文件提取关键内容如果界面和 resume 都失灵最后一个兜底方案是把会话文件当作普通文本处理。sessions 目录下的 JSONL 文件每一行都是一个事件包含用户消息、assistant 回复、工具调用和错误日志。用编辑器或命令行直接查看less ~/.codex/sessions/旧provider名/xxxx.jsonl需要提取某段对话时可以用 grep 搜索关键词grep -l 关键字 ~/.codex/sessions/旧provider名/*.jsonl这个方法适合找回个别关键结论不适合批量恢复整个会话树。真到了这一步说明连接层已经乱了先解决配置问题再考虑恢复历史。5. 接入 DeepSeek 的常见报错和排查顺序5.1 高频报错速查表接入 DeepSeek 后下面几个报错出现频率最高先看表再动手。报错关键字大概率原因优先处理方式unable to locate the codex cli binary扩展或桌面端找不到 Codex CLI安装 CLI把 CLI 路径配到扩展设置里the gpt-5.6-sol model is not supported when using codex with a...当前模型名和 provider 不匹配检查 config 里的 model 和 model_provider不要照搬别人配置里的模型名cc switch local proxy failed while handling codex endpoint /responses本地切换工具把请求打到了 /responses 端点上游不支持检查本地转发服务的端口和端点配置把 wire_api 改成 chatreasoning_content in the thinking mode must be passed back to the api思考模型返回的 reasoning_content 没有按要求回传关闭思考模式或改用非思考类模型再验证表格里第三行提到的报错完整形式通常长这样provider: deepseek; model: deepseek-v4-flash; upstream_status: http 400; cause: the reasoning_content in the thinking mode must be passed back to the api.这个报错和密钥没关系它说明请求携带了思考模式相关字段但连接方式或模型不支持正确回传。排查时先关掉 thinking mode或者把模型换成不带思考能力的对话模型多半就能跑通。5.2 按顺序排查不要上来就改参数遇到连不上 DeepSeek 的问题我建议按这个顺序走先看是界面报错还是上游报错。界面报错多是 CLI 路径、本地转发服务、端口问题上游报错多是模型名、base_url、密钥问题。再用 curl 直接打一次 API。这一步能快速区分“Codex 配置问题”和“DeepSeek 接口问题”。最后检查 config.toml。重点看 model、model_provider、base_url、wire_api 这几个字段是否和 provider 文档一致。如果用了本地切换工具确认它和 config.toml 没有互相覆盖。有时候你手动改了 config工具一启动又把它改回去了。如果你用的是 DeepSeek Harness 这类社区桌面壳排查思路也是一样的。它的底层仍然是读取 Codex 的本地会话目录和配置遇到“聊天记录消失”或“请求 400”不要只盯着壳界面回到.codex/sessions和 config.toml 里看状态。6. 稳定使用的三条建议6.1 先跑通单条再考虑批量和归档接入 DeepSeek 后不要一上来就同时开多个会话或跑批量任务。先在 CLI 里用一条对话验证配置再看 VS Code 扩展能不能正常调用最后才切到日常任务。这样做的原因很简单批量任务一旦跑起来报错会成倍出现日志会混在一起很难判断是 provider 问题还是 Codex 本身的问题。单条对话跑通之后参数、密钥、端点才对得上后面批量才值得试。6.2 把会话目录备份变成例行操作聊天记录恢复的难度完全取决于你有没有备份。我建议每次切换 provider 或升级 Codex 版本之前都做一次 sessions 目录备份。平时也可以加个定时任务把.codex目录打包归档。另一个建议是给会话文件命名时保留时间信息。不同版本的 Codex 生成的文件名不一定可读但目录创建时间能帮助定位哪一段对话发生在哪个阶段。排查时优先按时间排序找文件。6.3 区分“界面不显示”和“文件被清理”遇到“聊天记录全没了”先判断是界面问题还是文件问题。界面问题通常可以通过切回原 provider、重启扩展、检查 sessions 目录解决文件被清理则是另一回事一般发生在目录误删、切换工具自动清理、磁盘空间不足等场景。所以排查顺序是先看 sessions 目录在不在再看子目录命名最后才看界面。顺序反了容易误判为数据丢失甚至做出重装客户端的错误决定。这个问题的关键不在 DeepSeek 能不能接而在于 Codex 的会话目录天然按 provider 隔离。切换之前做好备份切换之后按报错逐层排查聊天记录基本都能找回来。踩过几次之后会发现很多所谓“记录丢失”其实只是新的 provider 目录里还没有内容而已。