症状： 新 Work/Codex 正常，只有以前 API 创建的聊天 stream disconnected。 原因： 旧聊天仍绑定旧 model_provider。 解决： 保留旧 Provider ID 作为兼容别名，删除旧 base_url，不要再把旧 Provider 设为全局默认，让它使用当前 ChatGPT/Plus 登录认证。不要删旧聊天，也不要删整个 .codex。
问题描述： chatGPT桌面端可以使用API登录（CC-Switch）也可以使用chatGPTPLUS账号登录。 选择本地的文件夹作为项目，进行对话。使用API发现太贵了，切换为PLUS账号登录。
注销原有的登录方式。如图所示。
在你选择切换为plus账号登录后，可能遇到的问题： 1.你原来的对话可能加载不出来，解决方案，在项目文件夹新建一个对话，他自己会读取出来的。
2.出现： stream disconnected before completion: stream closed before response.completed
3.解决2出现的问题后： ChatGPT 无法加载 config.toml，因此此对话串无法继续。
请修复 config.toml:Model provider `milionengine`not found。保存文件后，重新打开此对话串。
本文出现的API为中转站，不便宜，也不推荐，仅作为举例。
吐槽：13块钱就用了20min左右。
下面文章是为了解决这个问题。
ChatGPT Desktop 从第三方 API 切换 Plus 后，旧 Work / Codex 对话断流的完整解决办法
一、问题现象
这种故障有一个非常明显的特征。
普通 ChatGPT 聊天可以正常使用，新的 Work 对话也可以正常工作，新建一个空文件夹交给 Codex 后同样可以正常执行任务。
但是，只要打开以前在第三方 API、自定义 Provider 环境下创建的历史对话，就会出现异常。
常见报错包括：
Model provider 'xxx' not found
或者旧对话虽然能够正常加载历史内容，但一发送新消息就出现：
stream disconnected before completion: stream closed before response.completed
并伴随多次重新连接。
这时不要优先怀疑聊天记录损坏。
如果新对话、新 Work、新 Codex 都正常，只有旧 API 对话异常，那么问题通常集中在旧聊天保存的 model_provider 与当前本地配置之间。
二、问题原理
Codex / Work 的历史 thread 会记住创建时所使用的 Provider。
例如以前使用：
millionengine
那么旧聊天恢复时仍然可能尝试寻找：
model_providers.millionengine
假设后来切换到 ChatGPT Plus，并删除了原来的 Provider 定义，就会发生：
旧聊天 → 查找 millionengine → 当前配置不存在 → 无法恢复
所以会看到：
Model provider 'millionengine' not found
如果为了让聊天重新打开，又把原来的 Provider 配置完整恢复，例如：
[model_providers.millionengine]
name = "millionengine"
base_url = "https://millionengine.com"
wire_api = "responses"
requires_openai_auth = true
旧聊天确实能够重新识别 Provider。
但是新的问题随之出现。
因为：
base_url = "https://millionengine.com"
仍然告诉程序：
“这条聊天继续把请求发送到旧 API。”
如果旧 API 已经失效、认证方式已经改变、账号已经不用、线路异常或者当前环境已经改成 Plus，就可能最终出现：
stream disconnected before completion
所以需要同时解决两个问题：
旧聊天必须继续认识原 Provider ID。
但这个 Provider 又不能继续使用以前的第三方 API 地址。
三、正确解决思路
不要修改每一条聊天。
不要删除旧聊天。
不要迁移整个 sessions 数据库。
也不要重新使用旧 API。
正确思路是建立一个“兼容 Provider”。
假设旧聊天记住的是：
millionengine
那么继续在 config.toml 中保留：
[model_providers.millionengine]
但是不再让它指向以前的：
https://millionengine.com
而是让它使用当前 ChatGPT 登录认证。
这样旧 thread 看到的 Provider ID 没有变化，所以仍然可以恢复。
但实际请求已经不再访问旧 API。
四、正式操作
首先完全退出 ChatGPT Desktop。
建议同时确认系统托盘中没有残留运行的 ChatGPT / Codex 进程。
然后进入：
C:\Users\你的用户名\.codex
找到：
config.toml
修改之前建议复制一份，例如：
config.toml.backup
这样无论发生什么都可以恢复。
如果旧配置中存在：
model_provider = "millionengine"
不要保留这一行。
这一行会把 millionengine 设置为全局默认 Provider，可能导致新的 Work 和 Codex 也重新走旧配置。
同样，如果旧配置中存在：
base_url = "https://millionengine.com"
或者任何已经不再使用的第三方 API 地址，也不要继续放在兼容 Provider 中。
最终加入：
[model_providers.millionengine]
name = "OpenAI"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = true
supports_standalone_web_search = true
其中：
millionengine
必须与旧聊天原本记录的 Provider ID 一致。
如果你的旧 Provider 不叫 millionengine，例如叫：
myapi
那么应该写：
[model_providers.myapi]
而不是照抄 millionengine。
五、一个完整的最小配置示例
例如当前正常配置是：
[desktop]
followUpQueueMode = "queue"
[windows]
sandbox = "elevated"
[projects.'d:\codex\测试']
trust_level = "trusted"
那么兼容旧聊天以后，可以变成：
[desktop]
followUpQueueMode = "queue"
[windows]
sandbox = "elevated"
[projects.'d:\codex\测试']
trust_level = "trusted"
[model_providers.millionengine]
name = "OpenAI"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = true
supports_standalone_web_search = true
关键区别是：
没有：
model_provider = "millionengine"
也没有：
base_url = "https://millionengine.com"
这两个区别非常重要。
六、修改后的测试顺序
保存配置后，完全退出 ChatGPT Desktop，然后重新启动。
先不要马上测试最重要的历史项目。
首先新建一个 Work 对话，发送：
你好，回复1
如果正常，再创建或打开一个空文件夹，让 Codex执行同样的测试。
如果这两个都正常，说明现在的 Plus 环境没有被兼容配置污染。
最后打开以前使用 API 创建的历史对话。
先观察历史记录能否完整加载。
然后发送：
你好，回复1
如果成功回复，说明旧 Provider 已经完成兼容。
此时应该得到这样的状态：
新聊天 → 当前 Plus → 正常
新 Work → 当前 Plus → 正常
新 Codex → 当前 Plus → 正常
旧 API 对话 → 保留原历史 → 当前登录环境 → 正常
七、为什么不应该删除 .codex
.codex 并不只是一个 API 配置目录。
其中可能包含历史 session、项目状态、本地索引、skills、数据库以及桌面端相关设置。
所以遇到 Provider 问题时直接删除整个：
C:\Users\你的用户名\.codex
属于非常激进的处理方式。
本问题真正需要修改的通常只是：
config.toml
中的 Provider 路由关系。
只要聊天正文和 session 数据仍然存在，就没有必要为了一个 Provider 配置错误而删除历史数据。
八、为什么“恢复整个旧 config.toml”也不正确
旧配置通常不仅包含历史 Provider 名称，还可能包含：
model_provider = "旧Provider"
model = "旧模型"
base_url = "旧API地址"
甚至包含旧认证方式和其他 API 参数。
直接把整个旧配置恢复，相当于把 ChatGPT Desktop重新带回以前的 API 环境。
典型表现就是：
旧聊天能打开了。
但是新的 Work 和 Codex又开始断流。
因此正确方法不是：
“恢复旧配置。”
而是：
“从旧配置中只保留历史聊天需要识别的 Provider ID。”
九、如何判断自己是不是同一种问题
最有效的诊断方法是比较新旧对话。
如果普通 ChatGPT正常，而且新建 Work 正常、新建 Codex 空文件夹正常，只有历史 API 对话报错，那么非常符合旧 Provider 残留问题。
反过来，如果连新建 Work 和新的空文件夹都出现：
stream disconnected before completion
那应该先检查当前全局配置。
尤其是：
model_provider
base_url
第三方 Provider 定义
旧代理
旧 API 环境
这时不要先处理历史聊天。
先让新的 Work / Codex恢复正常，再解决兼容问题。
十、这次实际故障的完整逻辑
最初的旧配置是：
全局默认 Provider
↓
millionengine
↓
https://millionengine.com
因此即使已经登录 Plus，Work / Codex仍可能受到旧 Provider 配置影响。
把旧 config.toml 移开以后：
新的 ChatGPT / Work / Codex
↓
当前 Plus 环境
↓
正常
但是历史聊天仍然保存着：
model_provider = millionengine
所以打开旧聊天时：
找不到 millionengine
↓
旧聊天无法恢复
重新加入旧 Provider 和旧 base_url 后：
旧聊天可以恢复
↓
发送消息
↓
再次访问旧 API
↓
stream disconnected
最终解决方法是：
保留：
provider ID = millionengine
删除：
旧 base_url
不设置：
全局 model_provider = millionengine
使用：
当前 ChatGPT 登录认证
这样历史对话和当前 Plus 环境之间就建立了一层兼容。
十一、最终结果
这个方案解决的并不是“如何导出旧聊天”。
而是更理想的问题：
如何让以前使用 API 创建的本地 ChatGPT / Codex 对话，在切换到 Plus以后仍然能够原地继续使用。
最终可以同时保留：
旧聊天记录。
旧项目。
旧 sessions。
本地文件。
skills。
新的 Plus 登录。
新的 Work / Codex。
不需要为了更换 Provider 而把过去的工作全部迁移到新对话。
对于长期使用 Codex、本地 Work、自定义 API Provider 的用户来说，这也是比“删除配置重新开始”更合理的处理方式。
十二、没耐心的看这里
解决方案： 1.修改.codex文件下的config.toml为config.toml.old
2.重启codex，找到.codex文件夹里新的config.toml
3.复制config.toml.old里的有用部分到config.toml（用记事本打开）
4.重启codex。
有用部分：五、一个完整的最小配置示例
