Codex 旧对话无法打开：Model provider OpenAI not found 的排查与修复

j6lfijk

55人浏览 · 2026-09-17 18:06:54

j6lfijk · 2026-09-17 18:06:54 发布

Codex 旧对话无法打开：`Model provider OpenAI not found` 的排查与修复

最近将 Codex 桌面应用升级到新版 ChatGPT 桌面应用后，我遇到了一个比较隐蔽的问题：新对话可以正常使用，但以前创建的 Codex 对话无法继续。

打开旧对话时，应用提示：

ChatGPT 无法加载 config.toml，因此此对话串无法继续。
请修复 config.toml：Model provider `OpenAI` not found。
保存文件后，重新打开此对话串。

一开始我以为是对话记录丢失，后来发现实际原因是：旧对话保存的模型 Provider 名称，与新版 Codex 当前使用的 Provider 名称不一致。

一、问题背景

新版桌面应用将 ChatGPT、Work 和 Codex 整合到了同一个程序中，但它们仍然是相对独立的工作区。

ChatGPT：用于普通问答、写作和资料分析。
Work：用于研究、文档、表格和演示文稿等任务。
Codex：用于本地项目、代码、终端和 Git 操作。
ChatGPT 与 Codex 的历史记录仍然分开管理。

因此，升级后如果看不到原来的编程对话，首先需要确认左上角当前是否处于 Codex，而不是 ChatGPT 或 Work。

不过，我遇到的不只是历史记录入口发生变化。切换到 Codex 后，旧对话虽然存在，但打开时会提示 Provider 不存在。

二、直接原因：Provider ID 区分大小写

Codex 的用户级配置文件位于：

C:\Users\<用户名>\.codex\config.toml

当前配置中只有模型设置：

model = "gpt-5.6-sol"
model_reasoning_effort = "xhigh"

并没有旧对话需要的 Provider 定义。

Codex 官方配置中，内置 OpenAI Provider 的 ID 是小写：

openai

但旧对话保存的 Provider ID 是：

OpenAI

这两个名称只有大小写不同，但 Codex 会将它们视为两个不同的 Provider。

项目	旧对话	当前配置
Provider ID	`OpenAI`	`openai`
类型	以前配置的自定义 Provider	Codex 内置 Provider
认证方式	可能是外部 API	当前 ChatGPT Plan 登录
当前状态	定义已经不存在	可以正常使用

旧对话会保存创建时使用的模型和 Provider 信息。当 Codex 尝试恢复对话时，会查找名为 OpenAI 的 Provider。由于当前配置中只有内置的 openai，恢复过程会直接失败。

这并不代表对话内容被删除，只是 Codex 无法重建旧对话所需的运行配置。

三、为什么不能直接恢复原来的外部 API

最直接的解决思路，是重新加入原来的外部 Provider：

[model_providers.OpenAI]
name = "OpenAI"
base_url = "某个外部 API 地址"
env_key = "OPENAI_API_KEY"
wire_api = "responses"

这种配置确实可能让旧对话重新打开，但后续请求会继续发送给外部 API，并按照外部服务商的规则运行和计费。

而我现在使用的是官方 ChatGPT Plan，希望旧对话恢复后也继续使用当前的官方额度，因此不能填写以下配置：

base_url = "..."
env_key = "..."
experimental_bearer_token = "..."

否则就可能重新切换到外部 API。

四、正确修复：增加官方 Provider 兼容别名

解决办法是在 config.toml 中增加一个大写 OpenAI 的兼容定义，但不配置任何外部 API 地址或密钥。

修改前，建议先备份原配置文件：

config.toml -> config.toml.bak

然后在 config.toml 最末尾加入：

[model_providers.OpenAI]
name = "OpenAI"
requires_openai_auth = true
wire_api = "responses"
supports_websockets = true
supports_standalone_web_search = true

保存后，彻底退出 ChatGPT/Codex，再重新打开旧对话。

这段配置的含义如下：

[model_providers.OpenAI]：补回旧对话需要的大写 Provider ID。
name = "OpenAI"：将其识别为 OpenAI Provider。
requires_openai_auth = true：使用当前 ChatGPT/OpenAI 登录凭据。
wire_api = "responses"：使用当前 Codex 支持的 Responses API。
不填写 base_url：不指定第三方或外部 API 地址。
不填写 env_key：不读取外部 API Key。

Codex 官方源码中，使用 ChatGPT 登录且没有指定 base_url 时，会选择官方 Codex 后端：

https://chatgpt.com/backend-api/codex

因此，这个兼容配置会让旧对话继续使用当前 ChatGPT Plan，而不会转到以前的外部 API。

需要特别注意：不要在配置顶部添加下面这一行：

model_provider = "OpenAI"

旧对话本身已经保存了大写 OpenAI。我们只需要补充兼容定义，不需要改变所有新对话的默认 Provider。

新的对话仍然可以继续使用内置的小写 openai。

五、排查过程中遇到的第二个问题

排查时还遇到了另一个报错：

failed to spawn code-mode host
C:\Users\<用户名>\AppData\Local\OpenAI\Codex\bin\<版本哈希>\codex-code-mode-host.exe

系统找不到指定的文件

这个问题与 Provider 丢失不是同一个故障。

Model provider OpenAI not found：导致旧对话无法恢复。
codex-code-mode-host.exe 缺失：导致 Codex 无法运行本地命令、读取文件或自动修改配置。

后者通常意味着桌面应用升级不完整，或者当前窗口仍在引用升级前的旧运行目录。

可以按以下顺序处理：

从系统托盘彻底退出 ChatGPT/Codex。
在任务管理器中结束残留的 ChatGPT 或 Codex 进程。
重新启动应用，必要时重启电脑。
打开“Windows 设置 -> 应用 -> 已安装的应用”。
找到 ChatGPT，进入“高级选项”。
优先执行 Repair/修复。
在备份 .codex 目录之前，不要直接执行 Reset/重置。

Repair 会尝试补齐程序文件，并尽量保留设置和本地数据。Reset 则可能清除应用的本地状态，两者不能混为一谈。

六、修复后的验证方法

重新启动应用后，可以按照下面的清单检查：

左上角已经切换到 Codex。
旧对话不再提示 Model provider OpenAI not found。
model_providers.OpenAI 中没有 base_url。
没有配置 env_key 或外部 API Key。
当前账号仍然通过 ChatGPT Plan 登录。
新建 Codex 对话仍然可以正常使用。
旧对话可以继续发送消息和操作项目。

如果 Provider 报错消失，但随后出现“模型不可用”，说明 Provider 已经修好，只是旧对话保存的模型已经下线，或者当前账号无法继续使用该模型。

此时将旧对话切换为当前支持的模型，例如 gpt-5.6-sol 即可。

七、问题总结

这次故障看起来像“旧对话丢失”，实际包含三个层次：

新版 ChatGPT 桌面应用把 ChatGPT 和 Codex 放进了同一个程序，但历史记录仍然分开。
旧对话保存了自定义 Provider ID，并且 Provider ID 区分大小写。
恢复外部 Provider 虽然能打开对话，但可能改变请求去向和计费方式。

因此，修复前必须先明确自己的目标：

如果希望继续使用原外部 API，就恢复原来的 base_url 和密钥配置。
如果已经改用官方 ChatGPT Plan，就使用 requires_openai_auth = true 的兼容别名，并且不要填写外部 API 地址。

最终使用的配置是：

[model_providers.OpenAI]
name = "OpenAI"
requires_openai_auth = true
wire_api = "responses"
supports_websockets = true
supports_standalone_web_search = true

它的作用不是重新启用外部 API，而是为旧对话提供一个能够使用当前官方登录的兼容入口。