Codex 重连 5/5 到底代表什么？

Codex 的 1/5 到 5/5 是一次连接恢复流程的重试计数，不是“模型已经思考了五次”，也不是“五次额度”。

OpenAI Codex 仓库 issue #7378 的维护者回复称，客户端把一般的暂时性错误统一显示为 Reconnecting...，因此会最多重试五次；该 issue 当时的具体故障后来被判断为某个服务 pod 的错误路由并完成缓解。这个案例说明：相同的 UI 文案可以来自不同底层原因，不能只凭 5/5 反推单一故障。

截至 2026 年 8 月 20 日，官方 Changelog 显示 Codex CLI 0.148.0 已加入“在临时 provider outage 中保持 turn 并重连”的修复。也就是说，新版改善了恢复能力，但并不意味着所有断网、代理握手失败或服务端错误都会自动恢复。

先判断：是服务故障还是本地连接问题？

最省时间的做法是把同一请求放到三个维度交叉验证：服务状态、客户端形态和网络路径。

GitHub issue #28295（2026 年 6 月）记录过中国大陆用户持续重连且任务没有进展的情况；issue #14209 则记录过欧洲用户在桌面端集中遇到重连。它们只能证明问题具有真实用户报告，不能替代你当前环境的诊断。

最短排查路径：五分钟确认故障层级

以下步骤不会修改项目文件，适合先执行并记录结果。

1. 记录版本与运行形态

CLI 用户要区分 npm 全局安装、Homebrew 或其他来源；桌面端和 IDE 扩展则记录 About 页面版本。版本信息决定你是否已经包含对应的重连修复。

2. 用短任务做最小复现

新建一个空目录，发送不涉及工具调用的短请求，例如“只回复 OK”。如果短请求也在 5/5 失败，优先查连接与认证；如果短请求成功、长任务失败，再检查上下文长度、MCP、工具调用或长连接稳定性。

3. 对比另一条网络路径

在不改变账号和项目的前提下，用手机热点或另一条可信网络复测一次。结果只用于定位：网络切换后恢复，说明本地出口、代理、VPN、DNS 或防火墙值得优先检查；两条网络都失败，则继续检查服务状态、版本和认证。

4. 看状态与反馈入口

用 CLI 的 /status 查看当前会话状态；在问题仍可复现时使用 /feedback 上传日志，并保留 thread ID。不要把访问令牌、Cookie 或完整环境变量贴到公开 issue。

5. 记录失败时间和错误原文

Reconnecting 5/5 只是外层提示。若后续出现 websocket closed、stream disconnected before completion、401、403、429、502 或 timeout，这些附加信息比重连计数更有诊断价值。

常见原因与对应修复

服务端或 provider 临时故障

当多个用户在相近时间出现相同表现时，最合理的动作是查看官方状态页并短暂等待，而不是连续重试几十次。重试风暴会让日志更难读，也可能把一个已恢复的请求变成多个重复任务。

官方 Changelog 还记录了“response stream 在连接失败时保持存活”和“任务在 reconnecting 后不再消失”等修复方向。升级客户端有价值，但应先确认新版本是否已正式发布到你的安装渠道。

VPN、代理、防火墙或 WebSocket 握手失败

OpenAI Codex 仓库维护者在 issue #14209 中表示，已调查的大量案例与不稳定网络、VPN、代理和防火墙有关。企业网络尤其容易允许普通 HTTPS，却拦截 WebSocket、长连接或特定域名。

可按以下顺序验证：

1. 临时关闭会改写流量的 VPN 或代理，重新执行最小复现。
2. 若必须经过企业代理，让网络管理员确认 Codex 所需域名、TLS 检查和长连接策略，而不是只测试首页能否打开。
3. 对比手机热点；若热点可用，将故障证据交给网络管理员。
4. 不要为了“绕过重连”随意把所有流量改成未知第三方中转，先确认数据合规与凭证风险。

认证、会话或工作区状态异常

如果错误伴随 401、403、反复跳转登录或“未授权”，应优先完成官方登录流程并重新启动客户端。远程连接场景还要检查是否仍使用同一 ChatGPT 账号和 workspace；官方 Remote 文档要求主机在线、已登录且具备 Codex 访问权限。

如果只有一个旧会话失败，可以先新建短会话验证，不要立刻删除所有本地数据。会话能新建但旧线程无法恢复时，保存 thread ID 和 /feedback 日志，比清空目录更容易让问题得到定位。

工作区、MCP 或长任务触发的断线

当空目录短任务正常、某个仓库失败时，问题可能来自项目路径、Git 状态、MCP server 启动、工具调用或超长上下文，而不是网络本身。

建议依次做三次缩减：

• 暂时关闭非必要 MCP，只保留内置能力。
• 换到干净 Git 仓库，发送同样短请求。
• 将一个长任务拆成可恢复的小步骤，并在每一步保存变更。

这样可以区分“连接断了”和“某个工具或上下文让 turn 进入异常状态”。

CLI、桌面端和 IDE 扩展应该怎么处理？

不同客户端的修复动作不同，不能把 CLI 命令原样套到桌面端。

Codex CLI

先升级到当前渠道提供的稳定版本，再重启一个短会话验证。不要在网络不稳定时直接运行会产生大量文件改动的长任务；使用 /status 和 /feedback 保留证据。

ChatGPT 桌面端 Codex

确认桌面应用没有被冻结、主机没有睡眠、账号仍处于登录状态。官方 Remote 文档明确指出：主机休眠、失去网络或关闭应用都会让远程访问停止，恢复前应先让主机保持唤醒、在线和已登录。

VS Code 或其他 IDE 扩展

先在独立 CLI 中做最小复现。如果 CLI 正常而扩展持续 5/5，优先重启扩展宿主、检查扩展版本与登录状态，再把同一错误提交给扩展维护渠道。不要同时升级多个组件，否则无法知道是哪一步改变了结果。

是否应该强制 HTTP、降级版本或重装？

这些操作有时能绕过特定传输或缓存问题，但不应作为无证据的第一选择。

如果你通过应用层统一接入多款主流大模型，七牛云AI可以作为调用层对照，用于区分“应用请求链路正常、Codex 客户端异常”还是“整个网络出口都不稳定”；这类对照只能辅助定位，不能替代 Codex 官方日志。

什么时候应提交 issue？

满足以下条件时，提交 issue 比继续盲目重试更有价值：

1. 两条独立网络都能稳定复现。
2. 空目录短任务也失败。
3. 已记录客户端版本、操作系统、时间、错误原文和是否使用代理/VPN。
4. 已在 /feedback 中上传日志，并删除了 token、Cookie、私有代码和个人路径。
5. 能提供最小复现步骤，而不是只写“很卡”。

参考 issue #7378 的历史经验，官方可能将一次故障判定为已缓解；但如果新版本、地区或客户端形态再次出现相同现象，应创建带新时间线和环境信息的新报告，不要把旧 issue 当作永久解决方案。

常见问题

Q：重连 5/5 是不是账号被封了？

不是。它只是客户端对暂时性错误的重试计数。账号问题通常还会伴随明确的认证或权限状态码；仅看到 5/5 不足以判断封禁。

Q：为什么我还能看到 Codex 偶尔回复，但随后又重连？

因为连接可能在一个流式响应完成前中断，或某次工具调用的长连接失败。部分内容已到达并不代表整个 turn 成功完成，应查看后续错误原文并保留 thread ID。

Q：换网络后恢复，是否说明 Codex 服务端没有问题？

不能完全这样推断。换网络只说明两条路径的表现不同，可能是本地代理、DNS、出口策略，也可能是区域路由差异。应把时间、地区和网络变化记录下来。

Q：可以直接删除 ~/.codex 解决吗？

不建议。该目录可能包含会话、配置和诊断线索。先导出必要信息、确认异常范围，再针对单个会话或明确损坏的缓存处理；全量删除是最后手段。

Q：新版本仍然重连，是否说明升级无效？

不一定。升级只能覆盖客户端已修复的问题，无法修复服务端临时故障、企业代理策略、网络抖动或错误的工作区配置。升级后要用短任务和另一条网络做可重复验证。

结论

Codex “重连 5/5”表示一次暂时性错误的重试窗口结束，不是模型质量、额度或账号状态的独立诊断码。官方资料和 Codex 仓库历史 issue 共同表明，根因可能来自 provider outage、网络/代理/WebSocket、认证、远程主机状态、MCP 或特定会话。

最稳妥的处理顺序是：记录版本和错误原文，做空目录短任务，换一条网络，对照 CLI 与桌面端，最后再升级、重新登录或清理单个会话。本文内容基于 2026 年 8 月 20 日可见的 OpenAI Developers 文档、Codex Changelog 和公开 issue，客户端提示与故障分类可能随版本更新。