Codex 报错 stream disconnected before completion

Codex 报 stream disconnected before completion: error sending request for url (https://example/v1/responses)

问题现象

Codex 运行时可能先出现 Reconnecting... 1/5、Reconnecting... 2/5 之类的重连提示，最后停在类似下面的错误：

stream disconnected before completion: error sending request for url (https://example/v1/responses)

也可能是官方 ChatGPT 登录态对应的地址：

stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)

如果你看到的是 https://api.openai.com/v1/responses，说明 Codex 正在走 OpenAI API。如果你看到的是某个中转站域名，说明请求正在走自定义入口，重点看这个入口的 Responses API 和流式连接是否稳定。

先盯住报错里的 URL。很多人一上来就换账号、改模型，这是低效排查。这个错误首先是“请求或流断了”，不是“模型不会写代码”。

这个错误是什么意思

stream disconnected before completion 表示 Codex 预期拿到一个完整的流式响应，但连接在完成前断开了。

error sending request for url 表示更底层的问题发生在发请求或建立连接阶段。它可能是 DNS、代理、公司网关、VPN、TUN 模式、WebSocket/HTTPS 回退、SSE 长连接，或上游接口自身不稳定。

所以它不是一个单一根因错误。它更像一个外层包装：Codex 只知道 Responses 请求没有正常完成，但真正原因通常藏在网络路径、代理模式或中转站的流式链路后面。

先看 URL，判断你在哪条链路上

如果 URL 是 https://chatgpt.com/backend-api/codex/responses，通常表示你在用 Codex 的 ChatGPT 登录态。优先排查本机到 chatgpt.com 的终端网络和代理，而不是 OpenAI API Key。

如果 URL 是 https://api.openai.com/v1/responses，说明你走的是 OpenAI API。优先排查 OPENAI_API_KEY、终端代理、网络连通性和 API 侧状态。

如果 URL 是 https://example/v1/responses 或某个中转站域名，说明你走的是自定义入口。重点看中转站是否兼容 Responses API、是否支持 Codex 所需的流式响应，以及模型名是否被正确映射。

只有当 URL 明显不是你想用的地址，比如旧中转域名、已废弃域名或拼错的路径，才需要回头查环境变量和配置污染。正常情况下，Base URL 不是这个错误的主因。

常见原因

1. 终端没有继承代理。浏览器能打开 ChatGPT，但 Codex CLI 所在的 shell、VS Code Remote、SSH 会话或桌面应用子进程没有走代理。
2. 代理模式不适合长连接。普通网页可以打开，但 Responses 的流式连接容易被代理、路由器、公司网关或透明代理中途切断。
3. 中转站不完整兼容 Responses API。部分中转只对 /v1/chat/completions 兼容较好，对 /v1/responses、SSE、工具调用或长上下文支持不稳定。
4. 上游流式响应超时或断开。高峰期、长上下文、工具调用、模型容量不足、服务商账号池抖动，都可能让流在完成前断掉。
5. 极少数情况下是 URL 指到了旧入口。只有报错里的域名明显不是你预期的入口时，才优先查 Base URL 配置。

快速排查步骤

按这个顺序走，不要一上来换账号或改模型：

1. 复制报错里的 URL，先判断是官方 chatgpt.com、OpenAI API，还是中转站域名。
2. 在同一个终端里跑 curl -v，确认终端本身能连上这个地址。
3. 看代理变量：如果终端没走代理，Codex 大概率也没走。
4. 如果 URL 是中转站域名，重点问服务商是否完整支持 /v1/responses 和 SSE 流式响应。

curl -v https://chatgpt.com/backend-api/codex/responses
env | grep -i proxy

如果报错里的 URL 明显不是你预期的入口，再查 Base URL 配置：

env | grep -E 'OPENAI|CODEX|BASE_URL|API_BASE'

curl -v 不要求业务成功，重点看 DNS、代理连接和是否很快断开。

按场景修复

终端代理没生效

在当前终端显式设置代理，然后重新启动 Codex：

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890

端口要换成你本机真实代理端口。不要照抄 7890 后就以为解决了，很多客户端端口是 7897、1080、2080 或其他值。

如果你在 VS Code Remote、SSH、tmux、systemd、launchctl 或桌面 App 里跑 Codex，要确认那个进程也拿到了同样的代理环境。只在一个普通终端里设置变量，不等于所有 Codex 入口都生效。

中转站 Responses 流式不稳定

如果报错 URL 是中转站域名，先确认它是否真的支持 /v1/responses。只支持 /v1/chat/completions 的中转，不等于能稳定跑 Codex。

你可以让服务商确认四件事：

1. /v1/responses 是否被完整转发。
2. SSE 流式响应是否会被缓冲、截断或超时关闭。
3. Codex 使用的模型名是否正确映射到可用上游。
4. 长上下文和工具调用是否有更短的超时限制。

如果中转站只能靠重试硬扛，说明它的流式链路不够稳。继续把大型代码任务压上去，只会制造更多中断。

推荐排查顺序

1. 复制报错里的完整 URL，判断官方 ChatGPT、OpenAI API 还是中转站。
2. 用同一个终端运行 curl -v 测试 URL 的 DNS 和代理连接。
3. 检查 env | grep -i proxy，确认 Codex 进程真的走代理。
4. 如果 URL 是中转站域名，确认 /v1/responses、SSE、模型映射和超时策略。
5. 只有 URL 明显不是预期入口时，再查 OPENAI_BASE_URL、CODEX_BASE_URL 等配置污染。
6. 以上都排除后，再考虑升级 Codex、换网络线路或换 provider。

一句话结论

stream disconnected before completion: error sending request for url 不是一个“重试几次就懂了”的错误。它在提醒你：Codex 到 Responses 接口之间的链路不稳定。

先看 URL，再测终端网络，再查代理和中转站流式链路，最后才看模型和服务商。反过来做，就是在黑箱里乱敲。