GPT88 / API Docs

Codex 一直重新连接 5/5：HTTP / Responses 连接排障

整理 Codex 出现 Reconnecting 1/5 到 5/5、Thinking... 的连接层排查方法，说明 WebSocket、HTTP / Responses、config.toml、provider 配置和回滚验证。

先给结论

当 Codex 长时间卡在重连时，建议按这个顺序处理：停止旧会话 → 备份用户级config.toml → 使用 HTTP / Responses provider → 完全重启 Codex → 先验证普通文本，再验证最小只读工具 → 最后恢复原任务。

这个顺序的重点是把“模型能力问题”和“连接 / 协议问题”分开。只要最小 HTTP 请求都没有稳定返回， 就不应该先继续调提示词、换复杂模型或重放长任务。

你看到的现象说明什么

codex-output.txttext
Reconnecting... 1/5
Reconnecting... 2/5
Reconnecting... 3/5
Reconnecting... 4/5
Reconnecting... 5/5
Thinking...

WebSocket 适合实时、持续的长连接和工具调用，但它对代理、网络节点、公司防火墙和中间网关的支持更敏感。 如果连接建立失败，客户端可能经历“尝试 → 重连 → 回退”的过程，所以终端中的 5 次重连不一定代表模型进行了 5 次深度推理。

这里的判断是排障假设，不是单凭一段终端文字就能确认的根因。只有在切换网络或 provider 后明显恢复， 并且普通请求与工具请求都能复现对照结果，才能把连接层问题的可信度提高。

最快恢复路径

  1. 停止卡在重连中的 Codex 进程，保留工作区，不要删除项目目录。
  2. 找到用户级 config.toml，确认是否使用了 CODEX_HOME。
  3. 复制一份备份，再新增 provider；不要先删除原配置。
  4. 把 provider 的协议设置为 responses；仅当当前版本识别时才使用 supports_websockets = false。
  5. 完全关闭旧 Codex，会话和终端都重新打开。
  6. 先发送一句话测试，再做一个只读工具测试。
  7. 两个最小测试都成功后，才恢复原来的长任务。

第一步：找到用户级 config.toml

Codex 的用户级配置通常位于 ~/.codex/config.toml。如果设置了CODEX_HOME，应以该目录为准。Windows 通常对应%USERPROFILE%\.codex\config.toml。

locate-config.shbash
# macOS / Linux
printf '%s\n' "${CODEX_HOME:-$HOME/.codex}/config.toml"

# Windows PowerShell
if ($env:CODEX_HOME) {
  Join-Path $env:CODEX_HOME "config.toml"
} else {
  Join-Path $HOME ".codex/config.toml"
}

# 也可以让 Codex 只定位文件，不修改文件：
请帮我定位当前 Codex 的 config.toml 配置文件路径，只告诉我路径，不要修改文件。

第二步：备份配置

先备份再改动。除了复制文件，也建议保留当前 Codex 版本、使用的 profile、模型名和当前网络环境， 这样回滚后才知道恢复了什么。

backup-config.shbash
# macOS / Linux
cp ~/.codex/config.toml ~/.codex/config.toml.bak

# Windows PowerShell
Copy-Item "$HOME\.codex\config.toml" "$HOME\.codex\config.toml.bak"

第三步：配置 HTTP / Responses provider

原帖给出的配置是 OpenAI / ChatGPT 登录模式的 provider 示例。它表达的核心是： provider 使用 Responses 协议，并尝试关闭 WebSocket 优先路径。

source-provider.tomltoml
# 原帖给出的 OpenAI / ChatGPT 登录模式示例
model_provider = "openai_http"

[model_providers.openai_http]
name = "OpenAI HTTP"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false

如果你是通过 gpt88.cc API Key 使用 Codex，不要把原帖的requires_openai_auth = true 直接复制过来。API Key 模式应使用env_key，并把 provider 指向 gpt88.cc 的兼容入口：

gpt88-provider.tomltoml
# gpt88.cc API Key 模式示例
model = "YOUR_MODEL_ID"
model_provider = "gpt88_http"

[model_providers.gpt88_http]
name = "gpt88 HTTP / Responses"
base_url = "https://api.gpt88.cc"
env_key = "OPENAI_API_KEY"
wire_api = "responses"

# 只有当前 Codex 版本识别该字段时才添加：
# supports_websockets = false
set-api-key.shbash
# 当前终端临时设置 API Key
export OPENAI_API_KEY="sk-你的-gpt88-api-key"

# Windows PowerShell
$env:OPENAI_API_KEY = "sk-你的-gpt88-api-key"

model_provider 的值必须和 [model_providers.<id>] 中的 provider id 完全一致。例如 provider id 是 gpt88_http，顶部就不能写成openai_http 或 chatgpt_http。

第四步：重启并验证

保存配置后，退出当前 Codex 和终端，重新打开一个终端，再启动全新会话。不要只在旧会话里继续发送消息， 因为旧会话可能已经保留了旧 provider、旧连接状态或失败上下文。

verify-connection.shbash
# 重新打开终端后验证 Codex 版本
codex --version

# 启动一个全新会话
codex

# 先发最小测试，不要立即重放原来的长任务：
请用一句话回复：Codex 连接测试成功。

# 再验证一次最小工具任务：
请列出当前目录中的文件，只告诉我文件名，不要修改任何文件。
  1. 普通文本请求成功：说明认证、模型和基础 HTTP 通路至少可用。
  2. 只读工具请求成功：说明 Agent 能继续接收工具结果，连接问题没有在第一轮工具调用处复现。
  3. 原任务成功：才可以认为这次配置对你的真实工作流有效。

API Key、OAuth 和字段选择

你的目标优先配置不要混用
通过 gpt88.cc 调模型base_url + env_key + wire_api = "responses"不要同时设置 requires_openai_auth = true
使用 OpenAI / ChatGPT OAuthrequires_openai_auth = true，按官方登录方式授权不要在同一个 profile 中残留 gpt88 API Key 环境变量
排查 WebSocket 兼容性先用最小 HTTP / Responses 请求做对照不要把一次成功就当成所有长任务都稳定

如果你还需要完整的 gpt88.cc Codex CLI 配置流程，可以继续阅读 Codex CLI 接入 gpt88.cc； 如果目标是 ChatGPT 插件或 OAuth 能力，请阅读 Codex 插件 OAuth 登录。

仍然卡住时的排查顺序

  1. 确认版本。先运行 codex --version。如果是旧版本，按当前安装方式升级； npm 安装可以参考 npm install -g @openai/codex@latest。
  2. 确认 provider 配置生效。检查 model_provider 与 provider id 是否完全一致， 并确认当前读取的是用户级 config，而不是另一个 CODEX_HOME 目录。
  3. 确认网络链路。换一个网络、代理节点或线路做对照；如果只在公司网络、防火墙或特定节点失败， 重点检查 WebSocket 和长连接支持，而不是先换模型。
  4. 开新会话。关闭旧会话，重新进入项目目录启动 Codex。旧会话中的失败连接和上下文不能作为新配置的验证结果。
  5. 区分错误类型。401 / 403 更像认证或权限，404 更像 Base URL 或模型名，524 更像网关没有及时得到可用上游响应； 仍需结合完整错误、时间和 request id 判断。
  6. 检查工具状态。普通文本成功但工具调用失败时，继续看 shell、hook、MCP、子进程和工具恢复， 不要把所有问题都归因到 WebSocket。
diagnose.shbash
# 1. 确认 provider 名称完全一致
model_provider = "gpt88_http"
[model_providers.gpt88_http]

# 2. 确认当前使用的配置文件
printf '%s\n' "${CODEX_HOME:-$HOME/.codex}/config.toml"

# 3. 确认当前环境没有覆盖旧地址或旧 Key
env | grep -E '^(OPENAI_API_KEY|OPENAI_BASE_URL|CODEX_HOME)='

# 4. 更新 Codex（如果你的安装方式是 npm）
npm install -g @openai/codex@latest

失败时如何回滚

如果 Codex 启动时报配置解析错误、模型列表异常或连接行为更差，先恢复备份，再重新启动。回滚只针对配置文件， 不会自动撤销已经写入项目的文件，因此项目改动仍要单独检查。

rollback-config.shbash
# macOS / Linux
cp ~/.codex/config.toml.bak ~/.codex/config.toml

# Windows PowerShell
Copy-Item "$HOME\.codex\config.toml.bak" "$HOME\.codex\config.toml"

配置恢复后，重新运行最小文本测试。如果文本恢复但工具仍失败，可以转到 Codex 工具恢复 和 Windows Codex 524 与 PowerShell 7继续分层排查。

发布前验收清单

acceptance-checklisttext
□ 已记录原始错误、时间、模型和当前网络环境
□ 已找到用户级 config.toml，并确认是否设置了 CODEX_HOME
□ 已备份原配置
□ provider id 与 model_provider 完全一致
□ wire_api = "responses"
□ gpt88 API Key 模式使用 env_key，不与 requires_openai_auth 混用
□ supports_websockets 字段已按当前 Codex 版本验证
□ 已完全退出旧会话，并重新启动 Codex
□ 普通文本请求成功
□ 最小只读工具请求成功
□ 再恢复原任务前，已确认工作区文件状态

来源与参考

下一步阅读