Codex 提示 stream disconnected before completion，断流原因怎么查？

stream disconnected before completion 表示 Codex 响应没有按预期完成，但这句话不能直接定位唯一原因。继续读后面的报错，确认使用的是 SSE 还是 WebSocket，再区分明确的额度或上下文错误，以及完成事件到达前连接就关闭的情况。

重试之前，先检查智能体改过的文件和工具执行过的操作。响应断开，不代表之前的命令已经回滚。本文面向 Codex 用户，以及使用兼容 Responses 端点的开发者。内容依据 2026 年 9 月 14 日核对的官方文档和源代码；我们没有复现你当前这次故障。

看完整报错，别只看开头

当前 Codex SSE 解析器会区分未完成的流和已经记录到的具体错误。连接在完成前关闭时使用的通用兜底错误，不能证明一定是用户网络出了问题。

一段能读懂的部分回答，不代表整个响应已经完成。流式响应文档区分了文字事件和响应生命周期事件。response.output_text.done 表示一段文字结束，不能替代整个响应完成的信号。

再次执行前，先保住已有进展

检查当前 diff、终端输出，以及已经启动的外部操作。工具可能已经执行完，只是模型最后的回应没有送到界面。对于会改变外部状态的动作，要求智能体重做之前，应先检查目标状态或执行记录。

不要假设自动重试保证“只执行一次”，也不要因为界面显示失败就认为不会产生费用。这些规则取决于操作本身和提供商。继续编程任务时，说明哪些结果已经核实、哪些仍不确定，避免下一次把所有步骤盲目重跑。

需要控制变量排查时，新建会话，使用一个简短的只读任务，暂时保持模型和路由不变。如果新会话成功、原会话失败，就值得继续检查历史长度、压缩记录和工具调用序列。但这一结果本身还不能证明某个客户端缺陷。

明确的错误要分别处理

官方 API 错误指南区分了身份验证、访问权限、速率限制和服务端错误。应检查响应正文，而不是把所有失败的流都当成能靠重试恢复的网络问题。

模型不存在或路由不正确，可按模型找不到的排查指南（英文）处理。订阅额度、API 账单余额和按时间窗口计算的速率限制也不同。账户额度窗口问题可查看 Codex 额度指南。报错已经点明额度问题时，反复调大网络超时没有针对性。

同样，context_length_exceeded 指向上下文限制，与连接空闲超时不同。应使用客户端支持的方式减少或管理相关上下文，并保留重要任务状态。新建空会话可以帮助区分原因，但仍需要理解原请求究竟带了哪些历史。

检查真正经过的网络链路

记录端点域名、代理配置、客户端版本和传输方式。SSE 与 WebSocket 是不同路径；能处理普通 HTTPS 请求的代理，对连接存活时间或 WebSocket 可能有不同处理。能访问相关日志时，对比客户端、网关和上游记录。

如果有组织允许使用的标准网络路径，可以作为对照。不要关闭 TLS 验证或安全控制来让测试通过。证书错误应排查证书链，而不是使用不安全的绕过方式。

观察故障是否总在一段没有事件的固定时间后出现、是否仅影响某条路由，或是否只出现在工具调用密集的回合。这些规律可以决定下一步测试，但还不足以直接归责模型提供商、代理或客户端。

分清空闲超时和重试设置

当前 Codex 配置参考分别定义了自定义提供商的 stream_idle_timeout_ms、stream_max_retries 和 request_max_retries。截至核验日期，文档默认值依次为 300,000 毫秒、5 次流重试和 4 次请求重试。流相关设置在文档中针对 SSE，不要假设它们控制所有 WebSocket 故障。

空闲超时衡量的是等待相关流中下一个事件的时间，不是整个任务允许执行的最长时间。调大它，不能阻止服务器或中间层因其他原因关闭连接。只有证据指向这项超时，且上游允许等待更久时，调整才有意义。

可以用现有 config.toml 指南（英文）定位实际生效的配置。写在未使用 profile 里的参数，不会改变当前会话。也不要复制未经核实、声称适用于所有 Codex 版本的“禁用 WebSocket”开关。

留下能用于定位的故障记录

记录开始和失败时间、操作系统、客户端版本、传输方式、端点域名、完整错误后缀，以及 request ID 或 response ID。补充新会话是否成功、工具是否已经执行，以及能复现问题的最短无副作用任务。

分享日志前，移除密钥、cookie、认证文件和私人仓库内容。历史 issue 可以作为对照，但要检查日期和处理状态。例如 Codex issue 4302是已经关闭的历史报告，不能用来证明相同旧缺陷今天仍未修复。

常见问题

这句报错一定意味着我的网络坏了吗？

不是。这个前缀涵盖未完成的响应流程。需要结合完整后缀、生命周期事件和提供商错误，区分连接故障与明确的请求失败。

可以直接让 Codex 全部重做吗？

先检查已经发生了什么。文件修改和外部工具动作可能在断流之前就已完成，重做可能产生重复工作或副作用。

应该一直加大超时时间吗？

只有确实观察到相关空闲超时导致故障时才考虑。更大的客户端超时不能修复无效凭据、模型不可用、额度耗尽或上游连接策略。