最近使用 Codex Desktop 时，可能会遇到这样一种比较奇怪的问题：

每次新建任务、打开已有任务，或者第一次发送消息时，界面都会连续出现：

Reconnecting... 1/5
Reconnecting... 2/5
Reconnecting... 3/5
Reconnecting... 4/5
Reconnecting... 5/5

奇怪的是，等这些重连全部结束之后，Codex 又能够正常工作。

也就是说：

它并不是完全无法连接，而是每次开始任务之前都需要等待一轮重连。

如果你的情况也是如此，那么问题很可能出在 WebSocket 连接阶段。

本文介绍一种比较简单的处理方式：为 Codex 单独创建一个 仅使用 HTTP/SSE 的 Provider，绕过不稳定的 WebSocket 连接。

一、问题表现

典型情况是：

打开 Codex Desktop；
创建一个新任务，或者恢复之前的任务；
输入第一条消息；
Codex 开始显示 Reconnecting；
从 1/5 一直尝试到 5/5；
等一段时间后，又突然恢复正常；
后续任务仍然能够正常执行。

所以很多人第一反应会认为：

网络断了；
OpenAI 服务不可用；
VPN 或代理节点有问题；
Codex 登录状态异常。

但如果 每次重连结束之后都可以正常回答，情况往往并没有这么简单。

二、为什么会反复 Reconnecting？

Codex 在与 Responses 服务通信时，可以使用不同的传输方式。

其中一种方式是：

WebSocket

另一种则是：

HTTP / SSE

发生问题时，大致过程可以理解成：

启动任务
   ↓
尝试建立 WebSocket
   ↓
WebSocket 连接超时 / 失败
   ↓
重新连接
   ↓
继续重试
   ↓
Reconnecting 1/5 → 5/5
   ↓
放弃 WebSocket
   ↓
切换到 HTTP/SSE
   ↓
请求成功

因此才会出现一个非常有迷惑性的现象：

前面一直提示正在重新连接，但最后任务还是成功了。

真正浪费时间的并不是模型生成，而是 WebSocket 建连失败以及多次重试的过程。

在部分网络、代理、公司网络、防火墙或者特殊网络环境中，普通 HTTPS 请求可能完全正常，但 WebSocket 长连接却不够稳定。

这种情况下，与其每次等待 WebSocket 失败之后自动回退，不如直接让 Codex 使用 HTTP/SSE。

三、解决方法：让 Codex 使用 HTTP/SSE

操作之前，建议先备份配置文件。

整个过程主要分为四步：

备份 config.toml
      ↓
创建 HTTP Provider
      ↓
切换默认 Provider
      ↓
重启 Codex 验证

四、找到 Codex 配置文件

Windows 下 Codex 的用户配置通常位于：

%USERPROFILE%\.codex\config.toml

例如你的 Windows 用户名为：

Nico

那么实际路径可能类似：

C:\Users\Nico\.codex\config.toml

其中：

%USERPROFILE%

就是 Windows 当前用户的主目录。

如果不知道配置文件在哪里，也可以进入 Codex 的设置页面，通过配置相关入口直接打开：

config.toml

五、第一步：备份 config.toml

强烈建议修改之前先复制一份配置。

这样即使修改后出现问题，也可以随时恢复。

PowerShell

打开 PowerShell，执行：

Copy-Item "$env:USERPROFILE\.codex\config.toml" "$env:USERPROFILE\.codex\config.toml.bak"

执行成功后：

config.toml

旁边应该会多出：

config.toml.bak

Git Bash

如果习惯使用 Git Bash，也可以直接执行：

cp ~/.codex/config.toml ~/.codex/config.toml.bak

备份完成以后再继续操作。

六、第二步：修改默认 Provider

打开：

config.toml

找到类似下面的配置：

model_provider = "openai"

将它修改为：

model_provider = "openai_http"

这里的意思很简单：

原来使用 Codex 内置的：

openai

Provider。

现在改为我们自己创建的：

openai_http

Provider。

七、第三步：添加 HTTP Only Provider

接下来需要在 config.toml 中添加一个新的 Provider。

加入：

[model_providers.openai_http]
name = "OpenAI HTTP only"
base_url = "https://chatgpt.com/backend-api/codex"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false

这里最关键的一项是：

supports_websockets = false

它表示：

当前 Provider 不使用 WebSocket。

这样 Codex 就不需要先尝试 WebSocket、失败、重试多次，然后再回退 HTTP。

而是直接通过 HTTP/SSE 与服务通信。

八、一个完整配置示例

假设你原来的配置类似：

model = "gpt-5"
model_provider = "openai"

修改以后可以变成：

model = "gpt-5"
model_provider = "openai_http"

[model_providers.openai_http]
name = "OpenAI HTTP only"
base_url = "https://chatgpt.com/backend-api/codex"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false

如果你的配置下面还有：

[projects.xxx]

或者：

[plugins.xxx]

之类的 TOML 配置段，建议把：

[model_providers.openai_http]

放在这些配置段之前。

不要随意删除自己已有的模型、项目、插件以及其他 Codex 配置。

九、第四步：彻底重启 Codex

修改并保存 config.toml 后，不要只关闭当前聊天页面。

建议：

完全退出 Codex Desktop；
确认后台 Codex 进程也已经退出；
重新启动 Codex Desktop；
创建一个新的任务；
发送第一条消息测试。

重点观察是否还会出现：

Reconnecting... 1/5
Reconnecting... 2/5
...
Reconnecting... 5/5

如果第一条消息能够直接开始处理，那么说明配置已经生效。

十、使用 Codex Doctor 检查

如果当前版本支持，可以在 PowerShell 或终端执行：

codex doctor --summary --ascii

主要检查以下几件事：

配置文件是否成功加载
当前 Provider 是否正常
HTTP Endpoint 是否能够访问
WebSocket 是否已经关闭

不过需要注意：

Codex Desktop 自带的 Codex 版本和终端中安装的 Codex CLI 不一定完全相同。

所以最可靠的判断方式仍然是：

新建一个 Codex 任务并发送消息。

如果不再出现连续的：

Reconnecting 1/5 → 5/5

就说明问题基本解决。

十一、为什么不直接修改内置 openai Provider？

可能有人会想到直接写：

[model_providers.openai]
supports_websockets = false

但不同 Codex 版本对于内置 Provider 的配置覆盖存在限制。

因此更加稳妥的方法通常是：

不要修改内置 openai

而是创建一个新的：

openai_http

然后：

model_provider = "openai_http"

通过新的 Provider 禁用 WebSocket。

十二、修改后历史任务不见了怎么办？

这个问题值得特别说明。

Codex 的部分版本会把任务与：

model_provider

关联起来。

因此从：

openai

切换到：

openai_http

之后，可能会遇到：

部分旧任务不显示；
Resume 列表发生变化；
新旧 Provider 下的会话列表不同；
某些旧任务恢复时出现认证问题。

这并不一定意味着历史数据真的被删除了。

更可能只是：

当前 Provider 与原任务创建时使用的 Provider 不一致。

所以不建议为了处理 Reconnecting 问题去删除：

.codex

目录或者 Codex 的状态数据库。

十三、如果修改以后出现 401

如果切换 HTTP Provider 以后出现：

401 Unauthorized

首先检查配置里面有没有：

requires_openai_auth = true

完整配置应该包含：

[model_providers.openai_http]
name = "OpenAI HTTP only"
base_url = "https://chatgpt.com/backend-api/codex"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false

同时确认 Codex Desktop 当前已经正常登录 ChatGPT/OpenAI 账号。

如果是之前使用旧 HTTP Provider 创建的历史任务出现 401，而新建任务正常，则还可能与旧会话保存的 Provider 信息有关。

十四、如何恢复原来的 WebSocket 配置？

如果后续网络环境恢复正常，或者 Codex 新版本已经解决相关问题，可以随时切换回默认设置。

将：

model_provider = "openai_http"

改回：

model_provider = "openai"

然后可以删除：

[model_providers.openai_http]
name = "OpenAI HTTP only"
base_url = "https://chatgpt.com/backend-api/codex"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false

保存配置并重新启动 Codex 即可。

使用备份恢复

如果前面已经备份：

config.toml.bak

也可以直接使用备份文件恢复。

PowerShell 示例：

Copy-Item "$env:USERPROFILE\.codex\config.toml.bak" "$env:USERPROFILE\.codex\config.toml" -Force

然后重新启动 Codex。

十五、哪些情况适合使用这个方法？

这个办法主要适合下面这种情况：

适合

Codex 每次第一条消息都 Reconnecting；
经常从 1/5 一直重试到 5/5；
重试结束以后又能够正常使用；
HTTP 请求本身没有问题；
WebSocket 在当前网络环境中不稳定；
使用代理后依然存在相同问题。

不一定适合

如果你的情况是：

Reconnecting 结束以后仍然无法使用

或者直接出现：

那么原因可能完全不同。

例如：

OpenAI 登录失效；
Token 问题；
网络完全无法访问服务；
DNS 问题；
代理配置错误；
API Endpoint 无法访问；
Codex 客户端自身 Bug；
OpenAI 服务异常。

这种情况下，不建议看到 Reconnecting 就直接套用本文配置。

十六、简单判断是不是 WebSocket 问题

可以用下面的逻辑快速判断。

如果你的情况是：

Reconnecting 1/5
↓
Reconnecting 2/5
↓
……
↓
Reconnecting 5/5
↓
等待
↓
Codex 最终正常回复

那么非常符合：

WebSocket 建连失败
↓
多次重试
↓
自动回退 HTTP/SSE
↓
请求成功

这种情况。

而如果是：

Reconnecting
↓
最终报错
↓
始终无法生成

则应该优先继续排查网络、认证以及服务状态。

十七、总结

Codex Desktop 反复出现：

Reconnecting... 1/5 ～ 5/5

但等待之后又能继续正常使用时，问题很可能不是“完全无法联网”，而是：

WebSocket 连接阶段失败，Codex 重试数次后自动切换到了 HTTP/SSE。

因此一个比较直接的解决思路就是：

建立 openai_http Provider
↓
关闭 supports_websockets
↓
让 Codex 直接使用 HTTP/SSE

核心配置如下：

model_provider = "openai_http"

[model_providers.openai_http]
name = "OpenAI HTTP only"
base_url = "https://chatgpt.com/backend-api/codex"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false

对于 WebSocket 经常超时，但 HTTPS 本身能够正常访问的网络环境，这种方案可以省掉每次任务开始时等待多轮 Reconnecting 的时间。

不过需要注意，自定义 Provider 属于一种规避 WebSocket 问题的配置方案，不代表所有 Codex 版本都会拥有完全相同的行为。Codex 更新以后，Provider、会话恢复以及网络传输机制都有可能发生变化。

因此修改前最好始终：

先备份 config.toml

如果未来 Codex 官方解决了相关 WebSocket 问题，再切换回：

model_provider = "openai"

即可。

参考资料

OpenAI Codex GitHub：Recoverable reconnect loop before HTTP fallback
OpenAI Codex GitHub：WebSocket transport / HTTP fallback 相关 Issue
OpenAI Codex GitHub：HTTPS-only Transport 相关讨论
AtomGit AI 社区 / CSDN：Codex / ChatGPT Reconnecting 问题相关文章

本文根据公开问题记录与实际配置方案重新整理。Codex 更新速度较快，如果新版客户端已经修复 WebSocket 连接问题，建议优先使用最新版 Codex。

目录CONTENT

Codex / ChatGPT 一直 Reconnecting 1/5～5/5？HTTP/SSE 解决方法