Codex reconnecting 5/5 怎么办？config.toml 强制 HTTP 修复重连

用 Codex 写代码，对话窗口突然卡住，底部一直显示 reconnecting...，Codex 反复重试 5 次都连不上，严重时完全无法使用。退出重进能好一阵子，下次开对话又来。

这个 reconnecting 错误不少人遇到过，尤其是每次 Codex 更新之后特别容易出现。根源在 Codex 的连接方式上——默认走 WebSocket，但很多网络环境下 WebSocket 不稳定，就会反复重连，最后才退回 HTTP。

下面给你三种解决办法，从最快的临时修复到一劳永逸的自动修复。

相关教程推荐：

Codex 新手？先看 Codex App 完整使用指南

Codex 额度不够用？查看 Codex 额度详解与省流攻略

Codex CLI 新版本功能？查看 Codex 新版本实测

需要 ChatGPT Plus？查看 ChatGPT Plus 国内充值教程

Codex reconnecting 是什么原因？

Codex 和服务器通信有两种方式：WebSocket 和 HTTP。默认情况下 Codex 会优先尝试 WebSocket。

WebSocket 是一种长连接，理论上是更好的选择。但实际使用中，很多因素会让 WebSocket 连接不稳定：

公司或校园网络对 WebSocket 协议有限制或干扰
代理软件（Clash、V2Ray 等）或 VPN 没有正确转发 WebSocket 升级请求
防火墙规则阻断了 WebSocket 端口
Codex 软件更新后，连接配置被重置回 WebSocket 优先

当 WebSocket 连不上时，Codex 会反复重试——你看到的 reconnecting 1/5、reconnecting 2/5 就是这个过程——最后才退回 HTTP。每次对话开头都走一遍这个流程，卡半天才能开始干活。

如果你在日志里看到 transport="responses_websocket"，说明当前走的就是 WebSocket。解决办法很简单：把连接方式锁定为 HTTP，不让它走 WebSocket。

修改 config.toml 强制 HTTP（最快）

打开 ~/.codex/config.toml，加入或修改以下内容：

model_provider = "openai_http"

[model_providers.openai_http]
supports_websockets = false

改完保存，退出 Codex 重新打开，reconnecting 问题应该立刻消失。

注意：如果你的 config.toml 里已经有 model_provider = "openai_responses" 这一行，把它替换成 "openai_http"，不要直接追加，否则 TOML 会报 duplicate key 错误。

这个方法的缺点很明显：Codex 每次更新，配置都可能被覆盖回去。 今天改好了，下次更新完又得重来。不想反复手动改的话，继续往下看。

脚本自动修复重连（推荐）

既然问题是「更新后配置被重置」，那就写个脚本来自动检查和修复。

脚本只做一件事：检查 config.toml 里的 provider 是不是 HTTP，不是就改回来。

把脚本放在 ~/.codex/patches/codex-force-http-provider.sh：

#!/usr/bin/env bash
set -euo pipefail

CONFIG="$HOME/.codex/config.toml"

# 配置文件不存在就创建
mkdir -p "$(dirname "$CONFIG")"
touch "$CONFIG"

# 已经是 HTTP 就退出，不做任何操作
if grep -q 'model_provider = "openai_http"' "$CONFIG"; then
  exit 0
fi

# 写入前先备份
cp "$CONFIG" "$CONFIG.bak.$(date +%s)"

# 删除旧的 model_provider 行（兼容 macOS 和 Linux）
grep -v '^model_provider' "$CONFIG" > "$CONFIG.tmp" || true
mv "$CONFIG.tmp" "$CONFIG"

# 追加 HTTP provider 配置
cat >> "$CONFIG" << 'EOF'
model_provider = "openai_http"

[model_providers.openai_http]
supports_websockets = false
EOF

echo "Codex provider 已修复为 HTTP"

加执行权限：

chmod +x ~/.codex/patches/codex-force-http-provider.sh

手动跑一次确认没问题：

~/.codex/patches/codex-force-http-provider.sh

脚本设计遵循三个原则：

幂等：重复执行不会把配置越改越乱，已经是 HTTP 就直接退出
先备份再写：每次修改前复制一份带时间戳的备份，出问题随时回滚
只碰目标字段：不锁死整个 config.toml，你的其他配置照常改

macOS LaunchAgent 永久生效

脚本写好了，但它自己不会跑。在 macOS 上可以用 LaunchAgent 让系统在特定时机自动触发。

创建文件 ~/Library/LaunchAgents/com.user.codex-force-http-provider.plist：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.user.codex-force-http-provider</string>

    <key>ProgramArguments</key>
    <array>
        <string>/bin/bash</string>
        <string>/Users/你的用户名/.codex/patches/codex-force-http-provider.sh</string>
    </array>

    <key>RunAtLoad</key>
    <true/>

    <key>StartInterval</key>
    <integer>300</integer>

    <key>WatchPaths</key>
    <array>
        <string>/Applications/Codex.app</string>
        <string>/Users/你的用户名/.codex/config.toml</string>
    </array>
</dict>
</plist>

把 你的用户名 替换成实际用户名（终端打 whoami 查看）。

触发条件设了三个：

RunAtLoad：登录时跑一次
StartInterval 300：每 5 分钟检查一次
WatchPaths：Codex.app 或 config.toml 有变化时触发——这正是更新覆盖配置的瞬间

加载 LaunchAgent：

launchctl load ~/Library/LaunchAgents/com.user.codex-force-http-provider.plist

用 LaunchAgent 而不是普通 cron 任务的原因很简单：WatchPaths 能在文件变化的瞬间触发。Codex 更新包一落地，脚本就被唤起执行，等你下次打开 Codex 时配置已经修好了。cron 只能定时扫，中间有时间差。

Codex 用户推荐

ChatGPT Plus/Pro 国内充值

Codex 需要 ChatGPT Plus 或 Pro 订阅，支付宝微信即可开通

立即充值 ChatGPT

Codex 无法使用？Windows 和 Linux 修复方法

LaunchAgent 是 macOS 专属。其他系统用同样的思路，换一个触发工具就行。

Windows：打开「任务计划程序」，创建一个基本任务，触发器选「当用户登录时」和「按计划（每 5 分钟）」，操作选「启动程序」，指向你的 bash 脚本（通过 Git Bash 或 WSL 运行）。

Linux：用 systemd timer 或 cron。cron 最简单，编辑 crontab -e 加一行：

*/5 * * * * /home/你的用户名/.codex/patches/codex-force-http-provider.sh

如果你是通过 npm 全局安装的 Codex CLI（而不是桌面应用），更新覆盖配置的问题通常没桌面版那么严重——npm 更新频率低，手动跑一次脚本基本就够用了。

核心思路不变：写幂等脚本检查配置 → 用系统工具自动触发。

怎么验证 reconnecting 已修复

改完别急着关，至少验证四步：

检查配置：打开 ~/.codex/config.toml，确认 model_provider = "openai_http" 和 supports_websockets = false 都在。
手动跑脚本：终端执行脚本，退出码应该是 0（打 echo $? 查看）。
检查 LaunchAgent：launchctl list | grep codex 能看到你的任务。
故意改坏一次：把 model_provider 临时改成别的值，等 5 分钟（或手动触发脚本），看它能不能自动修回来。

第四步最关键。配置没偏的时候脚本什么都不做，证明不了它能修。只有故意改坏看它恢复，才算验证通过。

Codex reconnecting 常见问题

改了 config.toml 后 Codex 报错怎么办？

先检查 TOML 格式有没有写错。最常见的问题是引号缺失或 model_provider 出现了两遍（一个文件里不能有两个同名的顶层键）。改之前养成备份习惯，出问题直接恢复 .bak 文件。

为什么每次更新后 reconnecting 又出现了？

Codex 更新时会替换应用包，连接配置可能被重置回 WebSocket 优先。解决办法三（LaunchAgent）就是专门处理这个的——监听 Codex.app 变化，更新完自动修复。

用 HTTP 模式会影响 Codex 功能吗？

不会。HTTP 和 WebSocket 只是传输方式的区别，对 Codex 的功能和模型能力没有影响。实际使用中感知不到差异。

脚本会不会改坏 config.toml 其他配置？

不会。脚本只处理 model_provider 和 supports_websockets 两个字段，不碰 config.toml 里的其他内容。每次写入前都会备份。

Codex 一直重试、无法使用怎么办？

如果改了 config.toml 后 Codex 还是一直重试、无法使用，说明问题可能不在 WebSocket，而是网络环境本身对 OpenAI 服务器有限制。检查 Codex 是否支持 HTTP_PROXY 或 HTTPS_PROXY 环境变量，或者换一个网络环境试试。

Codex CLI 和 App 都会遇到 reconnecting 吗？

都会。两者共用同一份 ~/.codex/config.toml 配置，所以修改一次两边都生效。Codex App 更新频率更高，被覆盖的概率也更大，更建议用自动修复方案。

总结

Codex reconnecting 错误的核心原因是 WebSocket 连接不稳定。解决办法是把连接方式锁定为 HTTP：

方法	适合谁	效果
手动改 config.toml	所有人，立刻要修	即时生效，更新后可能被覆盖
脚本自动修复	经常遇到这个问题	手动跑一次就修好，幂等安全
LaunchAgent 永久生效	macOS 用户	更新后自动修复，一劳永逸

Windows 和 Linux 用户用系统自带的定时任务工具跑同一个脚本即可，思路完全一样。