
实际使用 Codex 时把官方模型切换成 DeepSeek 已经很常见。操作也不复杂在~/.codex/config.toml里新增一个模型提供方把base_url指向 DeepSeek 兼容接口再配置好 API KeyCodex 就能用 DeepSeek 模型对话。但很多人完成切换后打开 Codex 的历史会话列表发现原本和 OpenAI 官方模型产生的聊天记录全部消失了。这篇文章会解释 Codex 聊天记录到底存放在哪里、切换 DeepSeek 后为什么列表会变空、如何把历史会话找回来并备份同时覆盖接入 DeepSeek 时最常出现的三个报错和排查路径。1. 先理解 Codex 接入 DeepSeek 后“聊天记录消失”的本质1.1 Codex 的会话记录不是存在云端Codex CLI 会在本地维护自己的数据目录。常见情况下默认数据目录是~/.codexWindows 上通常是%USERPROFILE%\.codex。如果显式设置了CODEX_HOME环境变量则以变量值为准。会话记录位于数据目录下的sessions文件夹里每个会话对应一个.jsonl文件文件名通常是会话 ID。这个文件按行存储每一行是一次完整消息对象包含角色、内容、时间戳、当前工作目录等信息。先确认当前数据目录和会话目录echo CODEX_HOME${CODEX_HOME:-$HOME/.codex} ls -la ~/.codex/sessions | tail -10如果sessions目录下存在大量.jsonl文件说明历史会话数据还留在磁盘上。这里的关键判断是聊天记录并不是一定被删除而是可能没有被当前界面显示出来。1.2 为什么切换模型后会话列表会“重置”Codex 在展示历史会话列表时会根据当前生效的配置来决定枚举范围。当你修改配置、把模型提供方切到 DeepSeek 后当前对话上下文变成另一个作用域界面上的会话列表也随之切换。可以用下面这张表理解不同操作对会话文件和会话列表的影响操作本地会话文件当前界面会话列表修改config.toml新增 DeepSeek provider不变不变把model切到 DeepSeek 模型 ID不变可能被过滤列表变短使用新的 profile 或新数据目录不变看不到旧列表手工删除sessions目录被删除列表为空所以“切到 DeepSeek 后历史记录全没了”最常见的原因并不是数据被清除而是当前模型提供方对应的会话列表里不包含旧的 OpenAI 官方会话。1.3 三个容易误解的点误解实际情况Codex 官方把聊天记录存在云端切换模型后云端记录被清空Codex CLI 的会话记录默认保存在本地~/.codex/sessions切换模型不会主动删除这些文件切换模型会自动清空历史会话Codex 不会因为切换 provider 就清理sessions目录修改配置后旧会话文件就不可恢复文件仍然存在只需要切回对应配置或手动查看 JSONL 文件即可恢复如果遇到这种情况第一步不是重新安装 Codex也不是清空配置目录而是先做备份再判断当前会话列表的作用域。2. 动手找回聊天记录从备份到恢复的完整流程2.1 先确认 sessions 目录的实际位置在恢复之前必须确认会话文件真实路径。先检查默认目录ls -la ~/.codex ls -la ~/.codex/sessions如果设置了CODEX_HOME会话目录可能在别的位置echo $CODEX_HOME ls -la $CODEX_HOME/sessions还要检查当前是否使用了多配置文件或 profile 机制。部分 Codex 版本支持通过CODEX_HOME或配置文件选择不同数据目录目录不同会话列表自然不同。2.2 找出所有 JSONL 会话文件一旦确定数据目录统计目录里的会话文件数量并找出最近修改的文件find ~/.codex -type f -name *.jsonl | wc -l find ~/.codex -type f -name *.jsonl -exec ls -lt {} | head -10如果数量不为零说明旧的聊天记录没有被删除。可以根据文件名创建时间或修改时间判断哪些是切换 DeepSeek 之前的官方会话。也可以直接读取某个 JSONL 文件的开头几行确认里面的模型字段head -n 2 ~/.codex/sessions/session-id.jsonl输出里如果能看到 OpenAI 相关模型名就说明这个文件是官方会话记录。2.3 把整个 Codex 数据目录备份起来恢复操作之前先做一次完整备份。这一步不能省因为后面的操作可能涉及复制、覆盖文件一旦误操作数据可能真的丢失。BACKUP_DIR~/codex-sessions-backup-$(date %Y%m%d%H%M%S) mkdir -p $BACKUP_DIR cp -r ~/.codex $BACKUP_DIR/推荐备份整个.codex目录而不是只备份sessions这样配置文件和会话文件都在同一个备份快照里。备份完成后检查备份目录大小du -sh $BACKUP_DIR2.4 根据会话文件恢复或迁移恢复方案取决于当前配置结构。方案一临时切回官方配置确认旧会话还在。如果当前config.toml被改成 DeepSeek 配置可以先备份当前配置再恢复到切换前的配置启动 Codex 查看历史会话。方案二不切换配置直接读取 JSONL 文件。如果你只是想找回某段重要对话内容不需要让 Codex 界面显示它直接用文本工具或脚本读取即可cat ~/.codex/sessions/session-id.jsonl方案三把旧会话文件复制到当前配置对应的会话目录。要注意这个操作可能带来模型兼容性问题。旧会话里的模型字段是 OpenAI 官方模型恢复后继续对话时Codex 会使用当前 DeepSeek 配置发起新请求历史上下文里的角色和模型字段会一起发送。如果旧会话中包含 DeepSeek 思考模型无法处理的字段可能引发新的请求错误。所以更稳妥的做法是官方模型创建的会话尽量在官方 provider 配置下查看DeepSeek 创建的会话在 DeepSeek provider 下查看。不要盲目把两类文件混在一个目录里。2.5 恢复后验证恢复完成后验证会话文件是否完整。可以用 Python 解析 JSONL 文件确认每一行都是合法 JSONimport json from pathlib import Path path Path.home() / .codex/sessions/session-id.jsonl for i, line in enumerate(path.read_text(encodingutf-8).splitlines(), 1): obj json.loads(line) print(i, obj.get(role), obj.get(model, ))如果所有行都能正常解析说明文件结构没有损坏。如果某一行解析失败说明该文件可能被截断或写入不完整。注意恢复会话不是简单把文件复制回来就结束还要确认模型字段、消息角色和上下文长度都符合当前 provider 的要求。这个环节有一个很常见的坑有人会在 Codex 启动状态下直接复制 session 文件导致文件正在被写入时被复制得到不完整 JSONL。恢复前最好先退出 Codex 进程。3. 排错Codex 接入 DeepSeek 时最常见的三个报错3.1 桌面端提示找不到 Codex CLI现象Codex 桌面端启动时报告类似unable to locate the codex cli binary. set codex cli path界面无法正常进入对话。原因桌面端需要依赖 Codex CLI 可执行文件完成核心操作终端里找不到对应命令或桌面端没有配置可执行文件路径。先检查 CLI 是否可用which codex codex --version如果which codex没有输出说明 CLI 没有安装或安装目录不在 PATH 中。需要安装或重新安装 Codex CLI并把安装目录加入 PATH。如果 CLI 存在但桌面端仍然找不到可以在桌面端配置里设置 CLI 路径。不同版本配置项写法不同常见配置项是codex_cli_path值填写可执行文件的绝对路径。配置后重启桌面端再确认日志里没有定位 CLI 失败的错误。3.2 模型 ID 不受支持导致请求失败现象发起对话时返回错误类似the gpt-5.6-sol model is not supported when using codex with ...请求没有真正发到 DeepSeek。原因Codex 在自定义 provider 模式下会校验模型 ID配置的模型名可能不是 DeepSeek API 支持的模型或者模型 ID 本身写错了。处理方式把配置里的model改成 DeepSeek 官方 API 支持的模型 ID。常见情况下可以用模型 ID说明适用场景deepseek-chatDeepSeek 通用对话模型兼容 OpenAI Chat Completions大多数直接对话、代码生成、文本处理deepseek-reasonerDeepSeek 思考模型会返回推理过程通常需要处理reasoning_content需要推理、分析和复杂问题拆解的场景如果第三方工具里显示的是deepseek-v4-flash这类模型名要确认它能被目标接口真正解析不能只看工具下拉框里有没有。3.3 思考模型报错reasoning_content 必须回传现象请求 DeepSeek 思考模型时上游接口返回 HTTP 400错误提示大致是the reasoning_content in the thinking mode must be passed back to the api。原因DeepSeek 的思考模型和普通对话模型不同。模型返回内容里除了正常回复还有一个reasoning_content字段里面是模型思考过程。当后续请求需要携带历史上下文时这个字段必须原样传回。如果请求转发层对字段做了清洗、重命名或丢弃接口就会拒绝请求。排查顺序确认配置确实使用了 DeepSeek 思考模型例如deepseek-reasoner。检查本地会话文件里的历史消息是否包含reasoning_content字段。确认不是某个客户端或网关在转发请求时把该字段删掉。如果问题出现在第三方封装工具上优先升级工具版本或改用 DeepSeek 官方兼容接口直接接入。预防做法不要手工编辑 JSONL 会话文件去删除reasoning_content。这个字段对普通对话模型没有用但对思考模型是下一次请求的必需内容。3.4 /responses 接口返回 400现象切换转发层后Codex 在调用/responses端点时失败错误信息里能看到 provider 是 DeepSeek上游状态码是 400请求里还带有不被接受的字段。原因OpenAI Codex 原生请求可能走 Responses API而 DeepSeek 兼容接口目前更常用的是 Chat Completions 格式。如果配置里把base_url指向了/v1但wire_api仍然设置成 responses就会造成请求格式不匹配。处理方式# 先确认 base_url 指向哪个接口 grep -n base_url ~/.codex/config.toml # 再确认 wire_api 配置 grep -n wire_api ~/.codex/config.toml如果base_url填的是https://api.deepseek.com/v1一般需要把wire_api设置为chat让 Codex 使用 Chat Completions 方式对接。如果配置项不存在可以查阅当前 Codex 版本对自定义 provider 的wire_api支持情况。注意接入第三方模型时不是所有 OpenAI 端点都通用。Responses API 和 Chat Completions API 在请求体结构、字段命名和返回结构上都有差异要按实际接口能力选择接入方式。4. 最小可用配置把 DeepSeek 接入 Codex 并保留历史会话4.1 配置文件和会话目录的关系Codex 的配置文件通常位于~/.codex/config.toml。接入 DeepSeek 时需要新增一个模型提供方再把默认模型指向该提供方。这里要再次强调修改配置文件不会删除sessions目录里的历史文件。但如果你改了CODEX_HOME环境变量、换了配置文件路径或者把原来的配置备份后创建了全新配置文件Codex 可能读取不到旧会话。4.2 一个示意配置片段下面是一个用于说明配置思路的片段。不同 Codex 版本对字段名和支持范围有差异落地之前先对照当前版本文档确认model deepseek-chat [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY wire_api chat关键点model指定默认模型 ID。base_url指向 DeepSeek 兼容接口的根地址。env_key表示从哪个环境变量读取 API Key。wire_api指定使用 Chat Completions 风格对接。启动前设置环境变量export DEEPSEEK_API_KEYyour-api-key4.3 切换模型时不让会话记录“消失”的关键操作最有效的做法是在切换前记录当前会话 ID。在终端里可以通过会话文件目录看到会话 ID也就是文件名去掉.jsonl的部分。切换前先备份cp ~/.codex/config.toml ~/.codex/config.toml.bak.$(date %Y%m%d)这样如果切换后发现问题可以快速还原配置。不要直接删除旧的 provider 配置保留它能让 Codex 在需要时回到官方模型查看历史会话。4.4 学习环境与生产环境的差异维度本地学习环境生产或团队环境会话数据位置单机本地目录需要统一备份和归档策略API Key 管理环境变量即可需要密钥管理系统避免明文写入配置配置变更直接修改config.toml需要走配置评审和版本控制会话恢复手动复制 JSONL 文件需要可回滚、可审计的方案日志排错查看本机错误信息需要集中式日志和监控5. 日常使用 Codex 的会话管理最佳实践5.1 定期备份会话目录编写一个简单的备份脚本#!/usr/bin/env bash set -euo pipefail BACKUP_ROOT${HOME}/codex-backups mkdir -p $BACKUP_ROOT tar -czf $BACKUP_ROOT/codex-sessions-$(date %Y%m%d%H%M%S).tar.gz \ -C ${HOME}/.codex sessions echo backup done: $(ls -t $BACKUP_ROOT | head -1)手动执行或通过 cron 定时运行。备份时要避免在 Codex 正在写入会话文件时打包否则可能得到不一致数据。5.2 切换提供方前先完成三件事备份config.toml。备份sessions目录。记录当前主要会话 ID方便恢复后快速定位。不要直接改完配置立刻打开会话列表先确认文件备份完成。5.3 谨慎对待自动化清理有些工具或脚本会定期清理~/.codex目录用来释放磁盘空间。这类清理一旦误删sessions目录历史聊天记录就真的没了。如果确实需要清理只清理明确确认过的临时文件不要清理sessions目录。5.4 排查清单问题检查点处理建议会话列表为空~/.codex/sessions下是否还有 JSONL 文件有文件则切换回原 provider 或手动读取找不到 CLI 二进制which codex是否有输出安装 CLI 或配置codex_cli_path模型不支持检查model字段和模型 ID换成 DeepSeek 支持模型 ID请求返回 400检查base_url、wire_api、字段是否被清洗改用 Chat Completions 接入方式思考模型报错检查历史消息里是否保留reasoning_content不要删除该字段升级转发工具6. 扩展方向理解会话文件格式并处理跨机器迁移6.1 JSONL 会话文件的大致结构Codex 会话文件是逐行 JSON 数据每行代表一条消息。大致结构类似{timestamp: 1750000000, role: user, content: 你好, model: , cwd: /home/user/project}具体字段会随 Codex 版本变化。理解这个结构后可以用脚本提取会话主题、统计 token 量甚至把 JSONL 转成 HTML 阅读器。6.2 跨机器迁移需要把 Codex 迁移到新机器时除了复制sessions目录还要保证目标机器安装了相同或兼容的 Codex 版本并设置对应的 API Key。配置文件和会话目录最好一起迁移。tar -czf codex-backup.tar.gz -C ~ .codex在新机器上解压后启动前检查配置里的路径和模型 ID 是否仍然有效。6.3 继续深入的方向编写脚本按日期或模型维度整理会话文件。把会话导出为 Markdown 存档。对接团队备份体系定时上传备份产物。分析 DeepSeek 思考模型的reasoning_content在长期对话中的保留策略。回到最初的问题切换 DeepSeek 后 Codex 官方聊天记录消失绝大多数情况下是会话列表作用域变化而不是数据被删除。先备份、再确认目录、最后按需恢复是最稳妥的处理顺序。真正需要警惕的风险不是切换模型本身而是没有备份就手工清理或覆盖本地数据目录。