Codex 报 stream disconnected before completion 怎么办？先查是不是模型没解锁

2026-08-08

codex login 之后发第一条消息，直接来一句：

stream error: stream disconnected before completion: stream closed before response.complete

对应 GitHub 上的 issue #1581（已关闭）。原报告者的环境是 codex-cli 0.7.0、模型 codex-mini-latest、Linux，复现步骤简单到只有一句：codex login 之后发送任何提示词。

「断流」这个词很容易把人引向网络方向——查代理、换 WiFi、关 VPN。但 issue 里有一条评论指出了完全不同的方向，而且给了可验证的路径。

一、先说证据状态

Codex 仓库里没有官方 troubleshooting 文档（用代码搜索按文件名找 + 遍历目录，都没找到）。所以本文全部是社区证据，来自 issue 评论区，官方未确认。

另外有一条说明：issue #1581 的评论区里有一条以 HTML 格式排版、带小标题和 emoji 的「根因分析」长文。本文不引用那条内容——它没有可验证的来源，形式上也不像一手的排查记录。遇到这类内容要格外小心，它读起来很权威，但没法核实。

本文只引用给出了可验证操作路径的那条评论。

二、社区线索：账号可能需要完成验证

issue #1581 里有一条评论给的排查路径是这样的：

需要先通过验证，才能使用默认模型。

那位评论者给的做法：

第一步，换一个模型试。 他用的是：

codex -m o3-mini

换了模型就能用——这一步是关键的判断依据。

第二步，去后台看失败请求的真实原因。 到 OpenAI 平台的 Logs 页面（platform.openai.com/logs），点进一条失败的消息，滚到最底部，那里会写明需要完成验证才能使用某些模型。

第三步，完成验证。 位置在 platform.openai.com/settings/organization/general。

完成之后，默认模型就能用了。

这条线索之所以值得认真对待，是因为它给的是一条可验证的路径，而不是一个结论。 你不需要相信他说的对不对——按第一步换个模型试一下，几秒钟就知道方向对不对；再按第二步去后台看，答案就写在那儿。

三、为什么会表现成「断流」

这里要诚实：公开信息里没有解释为什么权限问题会表现成流式断开，本文也不推测。

但从排查角度可以记住一个规律：「断流」是一种症状，不是一种成因。 流断了可能是网络问题、可能是服务端拒绝了、可能是客户端处理不了响应。看到断流就往网络查，是把症状当成因了。

判断方向的最快办法就是上面第一步：换个模型试。 换了就好，说明跟网络没关系。

四、完整的排查顺序

换一个模型试
```
codex -m o3-mini
```
（或者其他你确定有权限的模型。）
- 换了能用 → 是模型权限/可用性问题，走第 2 步
- 换了还是断 → 不是这条线索，走第 4 步
去 platform.openai.com/logs 看失败请求 点进失败的那条，滚到最底部看具体原因。
按提示完成验证 如果确实提示需要验证，去 platform.openai.com/settings/organization/general。
换模型也不行的话，再查这些
- 网络：能不能正常访问接口
- 版本：codex 版本是不是太旧（原报告里是 0.7.0，属于很早的版本）
- 认证状态：codex login 是不是真的成功了

第 1 步是整条路径的分水岭，几秒钟就能把「权限问题」和「网络问题」分开。

五、相关的另一条：远程压缩失败

Codex 里还有一条流式相关的报错，形态相似但成因不同：

Error running remote compact task: stream disconnected before completion: error sending request

对应 issue #15046（仍开放）与 #14860（已关闭，104 条评论）。

这条跟本文主题的区别是：它发生在 /compact 这个特定操作上，而不是普通对话。

issue #14860 里，原报告者给出的分析是：/compact 会在大约 150 秒后失败（30 秒超时 × 4 次重试），而报错消息掩盖了真实原因。issue 里有一段被引用的回复，明确表示不认可某个「打补丁式」的方案：

那不是个好办法，它掩盖了底层的延迟问题。我们一直在解决根本原因。

而 issue 后期有评论说「现在好了，感谢 OAI 的工作」，issue 也已关闭——说明这条后来是被修掉的。

对今天的你，这条的实际含义是：如果撞上 /compact 相关的断流，先升级版本。 一个已经修复的问题，用旧版本硬扛没有意义。

六、还有一条：VS Code 扩展初始化失败

顺带记一条形态不同但同属「一上来就用不了」的：

Error starting conversation

对应 issue #2841（已关闭，90 条评论），出现在新的 Codex VS Code 扩展里，一打开侧边栏想开新对话就失败。原报告者的环境是 Windows 10。

issue 里几条值得注意的评论：

有人援引 OpenAI 社区论坛的说法：「Windows 支持是实验性的」，并说在 Linux 上工作正常
有人在输出日志里看到的是 Error creating local task: Error: Timeout
有一条社区技巧：先发一条消息，趁它转圈加载的时候切换模型，就能正常回复

第三条是典型的「不知道为什么但有效」的绕过办法。可以试，但别当解释——公开信息里没有原理说明。

至于「重装了 Windows 之后好了」那条评论，本文不作为建议：重装操作系统的代价远大于这个问题本身，而且没有任何证据表明是操作系统的问题。

七、怎么判断一条社区评论值不值得信

本文特意跳过了 issue 里那条排版精美的「根因分析」，这个判断标准值得展开说——因为在报错类问题上，采信错误的信息比找不到信息代价更大。

值得信的评论通常有这些特征：

给的是可验证的操作，而不是结论。比如「换成 codex -m o3-mini 试试」——你几秒钟就能验证真假
说明了自己的环境：版本号、系统、模型、订阅类型
指出了怎么自己去看：比如「去后台 Logs 页面，点进失败请求，滚到最底部」——它把你引向一手信息，而不是让你相信它
承认了不确定的部分

要警惕的：

排版精美但没有来源。带小标题、emoji、分节的长篇「根因分析」，读起来很权威，但如果没有任何可核实的依据，它可能只是流畅的猜测
只有结论没有路径。「这是因为 XX 机制的问题」——你没法验证，也没法据此行动
代价极高的建议。比如「重装系统就好了」——即使真的有人这么做之后好了，那也不能证明因果关系，而代价大得离谱

一个简单的判断法：这条建议能不能在五分钟内验证真假？能，就值得试；不能，就先放一边，去试那些能验证的。

八、总结

stream disconnected before completion 是症状不是成因，别看到断流就往网络查。
最快的判断是换一个模型试（如 codex -m o3-mini），几秒钟分开「权限问题」和「网络问题」。
社区线索：账号可能需要完成组织验证才能用默认模型。去 platform.openai.com/logs 点进失败请求滚到最底部看原因，验证入口在 platform.openai.com/settings/organization/general。
/compact 相关的断流是另一条（issue #14860），已被修复，撞上先升级版本。
Error starting conversation（issue #2841）是 VS Code 扩展初始化失败，社区提到 Windows 支持为实验性；有个「发消息后趁加载切模型」的绕法，可以试但别当解释。
Codex 仓库内没有官方 troubleshooting 文档，以上全部是社区证据，官方未确认。
评论区里那种排版精美、带小标题和 emoji 的「根因分析」，没有可验证来源的不要采信。

本文引用的 issue 编号与内容来自 openai/codex 仓库 issue #1581、#14860、#15046、#2841 的公开评论，核对日 2026-08-08。均为社区经验，官方未在文档中确认。版本与平台支持状况会变化，以官方说明为准。