企业官网建设流程全解析

切换 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_key：Codex 读取密钥的环境变量名。这里配了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 codex

Windows 用：

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 后，下面几个报错出现频率最高，先看表再动手。

表格里第三行提到的报错，完整形式通常长这样：

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 的问题，我建议按这个顺序走：

1. 先看是界面报错还是上游报错。界面报错多是 CLI 路径、本地转发服务、端口问题；上游报错多是模型名、base_url、密钥问题。
2. 再用 curl 直接打一次 API。这一步能快速区分“Codex 配置问题”和“DeepSeek 接口问题”。
3. 最后检查 config.toml。重点看 model、model_provider、base_url、wire_api 这几个字段是否和 provider 文档一致。
4. 如果用了本地切换工具，确认它和 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 目录里还没有内容而已。