· reAPI Team
stream disconnected before completion: stream closed before response.completed
Codex 读到了响应流末尾，却没有成功接收完成事件。先区分流提前结束、传输错误、空闲超时与限流，再核对事件和端点协议，不能仅凭断流就确定故障原因。
“stream disconnected before completion: stream closed before response.completed” 表示 Codex 读到了响应流的末尾，却没有成功接收完成事件。 它说明处理停在哪一步，不能单独确定是哪台机器出了问题。2026 年 10 月 22 日检查的 Codex SSE 源码，把这条消息用作流结束时的兜底错误；传输失败、空闲超时和此前收到的服务端错误各有处理分支。[1]
调整设置前，先读完整错误后缀。流提前关闭需要检查事件记录，空闲超时需要检查时间间隔，限流则要确认服务限制的是哪个维度。如果正在评估 reAPI，先看 GPT-6 Astra 请求文档：该文档描述的是 Chat Completions。Chat Completions 请求成功，并不能证明它兼容 Codex 使用的 Responses 协议。[2][3]
先做这些检查
- 重试前保留完整错误、客户端版本、时间和请求 ID。共享报告不要包含凭证或私有提示词。
- 流提前结束时，检查收到的 SSE 数据是否包含有效且被接受的终止事件，不能只看 HTTP 成功或已经显示的文字。[1]
- 出现
idle timeout waiting for SSE时，测量事件之间的间隔。空闲等待设置与请求、流的重试次数是不同控制项。[2] - 临时限流时按服务给出的重试提示等待，并减少对应负载。配额或账单错误需要先处理账户问题。[4]
stream disconnected before completion: stream closed before response.completed
源码能给出的结论比“网络坏了”更具体，也更有限。SSE 循环读取事件、反序列化 JSON，再交给 Responses 事件处理器。处理器返回完成响应时，循环成功结束。如果输入流先结束，则优先返回此前保存的响应错误；没有这类错误时才返回 closed-stream 消息。[1]
检查记录时可以据此区分：
| 观察结果 | 能确定什么 | 下一步 |
|---|---|---|
| 已收到文字，随后流结束 | 部分输出到达客户端 | 查找终止事件及其 JSON 内容 |
| HTTP 成功，但没有被接受的完成事件 | HTTP 层请求成功 | 检查事件序列，不把任务当作已经完成 |
| 日志中有看起来像完成事件的内容 | 类似完成事件的字节已到达 | 核对事件类型、必需字段与当前版本解析器 |
| EOF 前保存了服务端失败事件 | 服务已经提供错误 | 优先诊断该错误，不直接归因为另一次网络故障 |
这些结论来自对解析器的阅读，并非 reAPI 实际调用结果。本文固定引用源码版本 c2d5ea52，便于与所安装的客户端比较，而不是假设每个 Codex 版本的行为都相同。[1]
格式错误的数据需要单独检查。在该版本中，初次 JSON 反序列化失败的事件会被记录后跳过；已经识别为完成事件、但内部响应对象无效时，会走另一条错误路径。因此，在日志中找到 response.completed 字符串，不等于 Codex 已经接受这个事件。反过来，流关闭本身也不能证明服务器没有发送完成事件，需要对照服务端发送记录与客户端接收记录。[1]
自定义端点应先核对协议，再考虑增加重试。当前配置文档将 responses 列为受支持的 wire_api 值，WebSocket 支持则是独立的 provider 能力。某端点接受 OpenAI 风格的 Chat Completions JSON，并不因此成为可用的 Responses 端点。[2]
建议按小范围复现：先发一个纯文本请求，再测试对应的流式请求，最后测试原来失败的工具交互。各步保持端点、密钥和模型一致，记录每次变化。这是一种诊断方法，不保证所有服务都支持这三种测试。如果测试会产生用量费用，只执行该账户已获准的测试。
stream disconnected before completion: transport error: network error: error decoding response body
这条查询描述传输或读取响应体时的失败。Codex SSE 读取器可能在下一个有效事件到来前收到输入事件流的错误，这与前面正常读到流末尾的分支不同。[1]
把相关组件当作排查位置，不要当作已经确认的原因。记录最终端点主机、客户端版本、可获取的 HTTP 状态、耗时，以及是否收到过任何事件。随后每次只改变一个条件，例如比较另一个获准的网络路径，或在受影响客户端之外测试同一个端点。浏览器能打开网站，不代表那个失败的鉴权流式请求已经通过测试。
OpenAI 的连接错误指南建议检查网络设置、代理配置、SSL 证书和防火墙规则。这些是待检查项，不能直接诊断你环境中的这条错误。[5] 保持证书验证开启；由组织管理的网络应使用其批准的配置，不要套用无关的代理修复教程。
向网关维护者报告时，附上脱敏后的请求结构和最后收到的事件类型。只截取“disconnected”会丢掉关键区别。完整记录留在本地，共享版本删去 Authorization 请求头、私有输入和工具输出。
stream disconnected before completion: idle timeout waiting for sse
空闲超时表示等待下一个 SSE 事件的时间超过了配置值。它与整个响应耗时很长不同：持续产生事件的长响应，与一直没有事件的流，时间特征并不一样。[1]
2026 年 10 月 22 日核查的配置文档区分了三个设置：[2]
| Provider 设置 | 文档定义的作用 |
|---|---|
stream_idle_timeout_ms | 等待 SSE 事件的空闲时间，单位为毫秒 |
stream_max_retries | SSE 流中断后的重试次数 |
request_max_retries | 向 provider 发起 HTTP 请求的重试次数 |
提高空闲等待值，只会延长客户端等待时间，不能让不兼容的端点生成 Responses 事件，也不能找回已经丢失的字节。提高重试次数，只会改变尝试次数，不会改变首次失败的原因。
调整前记录响应开始时间、各事件到达时间和错误出现时间。如果观察到的边界是客户端超时，再结合服务文档评估该设置。如果连接更早关闭，应调查提前关闭。不要根据一次失败，为所有模型、网络和网关指定一个通用超时时间。
rate limit exceeded: upstream rate limit exceeded, please retry later
这条消息报告请求链路上某处触发了限制，但仅凭文字无法确定相关账户、限制维度或重置时间。不要根据“upstream”推断某个供应商，也不要认为充值一定能修复所有限流错误。
OpenAI 的直接 API 文档区分请求速率、token 速率、临时过载，以及配额或支出限制。文档列出了限流响应头，并说明临时情况附带的 Retry-After 表示最短等待时间；需要账户处理的错误不能靠重试解决。[4] 这是 OpenAI 的文档语义；实际使用时，应以所调用端点的文档与响应头为准。
| 实际端点返回的证据 | 对应处理 |
|---|---|
| 临时限流并给出重试提示 | 至少等待指定时间，再按有上限的策略重试 |
| 请求速率额度用尽 | 降低共享该限制的各 worker 总请求速率 |
| token 速率额度用尽 | 同时检查 token 需求与请求数量 |
| 配额、账单或支出上限问题 | 先处理账户条件，再重新提交负载 |
| 仅有通用消息，没有限制维度 | 保留请求 ID，让服务维护者确认限制来源 |
没有合适的等待提示时，OpenAI 建议使用带随机抖动的指数退避，并指出失败请求也可能计入限流。增加应用层重试前，先把 SDK 的重试计算在内。[4] 策略必须有停止条件，不能让一次被拒任务变成无限的新请求。
Agent 任务还要检查此前已经完成的操作。要求它重复中断任务前，先看工作区 diff 和工具历史。最终响应失败，不代表此前所有工具操作也失败。这是避免重复工作的操作建议，不表示 Codex 能自动回滚外部动作。
Why does my Codex stream disconnect before completion and the stream closed before the response is completed?
在所检查的 SSE 路径中，客户端到达输入末尾，没有成功返回完成事件，也没有更具体的已保存错误可以返回。需要对照客户端与服务端记录，确定终止事件是未发送、格式无效，还是在途中丢失。单凭该消息无法选择其中一个解释。[1]
Why does Codex keep disconnecting?
重复失败需要可重复比较：固定客户端版本、模型与端点，保存完整错误，每次只改变一个条件。先区分提前关闭、传输失败、空闲超时与服务拒绝。在此之前增加重试，可能只是在重复同一种失败，并未增加有效证据。
codex request timed out
先确定由哪个组件报告超时。Codex provider 配置提供 SSE 空闲等待值，而 API 客户端也可能报告请求超时。OpenAI 的错误指南列出网络与服务端相关排查因素，并没有把超时等同于某个唯一原因。[2][5]
resume stream unavailable
不要把它理解为响应一定可以续传，也不要据此认定已完成的工作全部丢失。记录版本与完整错误，保留会话并检查已完成的工具操作。本文查阅的来源没有为这条错误提供通用恢复命令，因此不编造这样的命令。
如果下一步要更换模型或端点，GPT-6 Astra 迁移指南说明了如何分别验证模型发现、协议变更与工具行为。模型页展示当前 reAPI 产品。型号名称或价格列表，都不能替代一次成功的 Codex 端到端兼容测试。
来源核查日期：2026 年 10 月 22 日