Codex CLI、VS Code 扩展或桌面端反复出现 Reconnecting... 时，很多人会把问题归结为“网络不好”。这个判断并不完整：登录会话过期、客户端版本不一致、代理协议配置错误、TLS 连接被中途关闭，以及服务端短时异常，都可能出现类似界面。

本文围绕codex reconnecting error 常见现象，给出一套 Windows 下可以复现的检查方法。目标不是反复点击重试，而是确认请求到底卡在认证、基础连接，还是持续响应阶段。

一、Reconnecting 画面背后可能发生了什么

Codex 发起一次任务，至少要经过认证、建立 HTTPS 请求、接收响应流几个阶段。Reconnecting... 1/5 只是客户端正在重试，并没有直接告诉根因。

实际排查时，可以把现象分成三组：

• 每个短提示词都失败，重试后出现 401 Unauthorized 或 unauthorized，更接近登录或认证问题。
• curl.exe 能收到响应，但 Codex 仍然反复重连，重点看客户端版本、代理变量和应用层配置。
• 简单请求可以完成，读取项目、调用工具或运行较长任务时才断开，重点检查响应流、代理超时和工具进程。

浏览器能打开网页只说明浏览器自身的路径可用。命令行、VS Code 扩展和桌面端可能使用不同的环境变量、证书存储和登录会话，不能用浏览器结果替代客户端测试。

二、版本和登录状态先做一次确认

官方仓库提供了 Codex CLI 的安装方式，官方文档也把“运行 codex 并完成登录”作为基本使用流程。排查时应记录实际调用的版本和路径，避免终端与编辑器调用了不同的二进制文件。

codex --version
where.exe codex

通过 npm 安装的 CLI，可以查看全局包版本：

npm list -g @openai/codex --depth=0

不要在没有确认安装来源的情况下，同时使用安装脚本、npm 和独立二进制进行覆盖安装。多个版本并存时，最常见的结果是：PowerShell 中能运行一个版本，VS Code 集成终端却调用了另一个版本。

认证失败通常伴随明确的 401 文本，或者重新打开终端后表现发生变化。此时完成一次正常的重新登录即可验证方向。使用 ChatGPT 账户登录与使用 API key 是不同的认证路径，不能把某一种路径的配置问题直接套到另一种路径上。

三、用三个命令检查基础连接

不要直接拿完整项目反复测试。先用 DNS、TCP 443 和 HTTPS 三个检查把故障范围缩小：

Resolve-DnsName chatgpt.com
Test-NetConnection chatgpt.com -Port 443
curl.exe -I -L --connect-timeout 5 --max-time 15 https://chatgpt.com/

结果可以这样理解：

• Could not resolve host 或 DNS 查询超时，说明解析环节还没有完成。
• TcpTestSucceeded : False，说明 TCP 443 没有建立，需要检查出口、防火墙或代理端口。
• 出现 Schannel、证书链或 TLS 错误，检查系统时间、根证书和企业网络的 TLS 检查策略。
• 收到 401、403、404 等 HTTP 状态码，说明请求已经进入 HTTP 层，不能再简单描述为“网络完全不通”。

curl.exe -I 只验证一次短请求，不能证明长时间响应一定不会被中间设备关闭。它的作用是建立一个清晰的对照基线。

四、HTTP 代理配置要看“启动 Codex 的进程”

命令行客户端可能读取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，而 VS Code 扩展和桌面端不一定继承同样的变量。查看启动 Codex 的那个终端：

Get-ChildItem Env:HTTP_PROXY,Env:HTTPS_PROXY,Env:ALL_PROXY -ErrorAction SilentlyContinue

若企业网络要求通过 HTTP CONNECT 代理，可以在当前 PowerShell 会话临时测试：

$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
Test-NetConnection 127.0.0.1 -Port 7890
codex

127.0.0.1:7890 只是格式示例，端口必须替换为实际监听端口。访问 HTTPS 目标时，代理地址并不必然写成 https://；许多 HTTP 代理通过 CONNECT 建立加密目标的隧道，具体格式应以当前客户端和企业代理规范为准。

如果出现 Proxy URL scheme not supported，检查协议头、主机、端口和认证方式，不要把带密码的代理地址直接放进截图或公开工单。测试完成后可以清除当前会话变量：

Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:ALL_PROXY -ErrorAction SilentlyContinue

五、短请求正常，长任务仍然断开

这是 codex reconnect 中比较容易误判的一类。短请求只建立一次连接，而长任务可能持续接收响应流，还可能读取文件、调用工具或等待子进程。代理、终端安全软件和企业网络设备如果有连接空闲时长、响应缓存或 TLS 检查策略，就可能在请求开始后关闭连接。

可以用同一台机器做三次对照：

1. 空目录中发送“只返回 OK，不读取和修改文件”。
2. 进入项目目录，发送同样的只读请求。
3. 最后运行原本容易失败的长任务。

第 1 步就失败，优先查看认证、版本和基础连接；前两步正常、长任务失败，则把注意力放到响应流、工具进程和中间网络设备，不要继续修改提示词。

六、常见错误信息怎么读

Reconnecting... 1/5 到 5/5

这是重试过程，不是根因。结合 DNS、TCP、HTTPS 和最小请求的结果判断。若基础 HTTPS 都失败，处理网络；若 HTTPS 有响应而 Codex 失败，检查认证、版本、代理和客户端日志。

stream disconnected before completion

表示响应流在完成前中断。认证可能已经通过，问题更接近长连接、代理超时、TLS 检查、客户端版本或服务状态。它不等同于项目代码出错。

401 Unauthorized

优先处理登录会话、账户权限和当前客户端使用的认证路径。重新登录后若仍复现，记录版本、发生时间、请求 ID 和完整错误文本。

429

更接近限流、配额或账户使用限制，不能直接判断为代理失效。查看账户用量和服务状态，并避免短时间重复提交同一任务。

七、VS Code、CLI 和 WSL 不要混在一起测

VS Code 集成终端、原生 PowerShell 和 WSL 可能使用不同的环境变量、DNS 和证书。每个环境都应分别执行：

codex --version
Get-ChildItem Env:HTTP_PROXY,Env:HTTPS_PROXY,Env:ALL_PROXY -ErrorAction SilentlyContinue

WSL 内部则使用 Linux 命令检查：

printenv | grep -iE '^(http|https|all)_proxy='
curl -I -L --connect-timeout 5 --max-time 15 https://chatgpt.com/

PowerShell 中设置的变量不会自动代表 WSL 内部配置。只有在各环境的版本、DNS、代理和 HTTPS 结果都可解释时，比较不同客户端才有意义。

八、反馈前保留这些信息

官方 Codex 问题讨论中，维护者曾建议通过 /feedback 上传日志并提供 thread ID。提交反馈前应保留：客户端版本、操作系统、发生时间、最小复现步骤、是否使用代理、DNS/TCP/HTTPS 结果、完整错误文本和请求 ID。

API key、Cookie、认证文件、代理密码、私有代码和业务数据不要上传。重试前还要确认原任务没有继续运行，避免重复提交产生副作用。

九、总结

Codex 一直 Reconnecting，不应只按“换网络”处理。401 更接近认证，DNS/TCP/TLS 错误属于基础链路，stream disconnected before completion 则要检查持续响应和中间设备。把短请求、长任务、CLI、VS Code 和 WSL 分开验证，通常能快速缩小范围。

参考资料

• OpenAI Codex 官方仓库
• Codex CLI 官方文档
• Codex CLI Reconnecting 问题讨论
• Codex stream disconnected 问题讨论