发布日期：2026-10-13 | 适用范围：Codex 桌面端与 CLI

Codex 长会话断流，是使用 Codex 处理持续性任务时，界面突然停止输出、显示重连，或恢复后无法判断上一轮是否完成的现象。截至 2026 年 10 月，OpenAI 官方源码分别处理响应流重试、客户端重连和上下文压缩；它们不是同一种故障。看到“断流”时，先保留工作区和未发送的输入，再确认任务状态、检查服务与网络，最后恢复原会话。只有原会话反复无法继续时，才把已确认的进度交接到新会话，避免重复执行不确定是否已经提交的操作。

先把“断流”分成三件事

“输出停了”并不能证明任务已经停止，更不能单凭会话很长就认定是上下文耗尽。

  • 响应流中断：模型响应尚未结束，界面出现 Reconnecting... 或 stream disconnected before completion。OpenAI 的响应流重试实现会根据错误类型尝试重连，重试耗尽后才把错误返回。

  • 客户端连接中断：桌面端或终端与承载会话的服务失去连接。Codex 的重连实现会重新附着已有会话、读取历史；对于无法确认是否已提交的消息，不会自动重发。

  • 上下文压缩：长会话的历史被整理成摘要，以继续容纳后续工作。OpenAI 的压缩实现会替换当前使用的历史并保留摘要；这是上下文管理，不是网络修复。

这三个状态也可能接连出现。例如压缩期间连接断开，界面同时出现“压缩”和“重连”提示。此时应先确认连接和任务状态，再考虑整理上下文。

第一件事：保存现场，别急着重发

最需要防范的是“上一条指令到底有没有送达”。官方重连代码对这类不确定消息采取保留、提示用户的处理方式，而不是自动再次提交。涉及改文件、运行脚本或发布动作时，手动重复发送也可能造成重复执行。

先记下会话 ID、最后一条已确认的回复，以及界面显示的错误原文；保留输入框里的草稿。若任务在 Git 仓库中，可在独立终端查看当前变更：

git status --short
git diff --stat

这两条命令只读取工作区状态。它们不能证明后台任务已经结束，但能帮助你辨认哪些文件已经落盘。对于非 Git 项目，直接检查本次任务涉及的文件和输出目录即可。

再查服务状态与本地连接

先打开 OpenAI 官方状态页，看是否有正在发生的服务事件。状态页正常，也不能排除本机网络、代理、公司防火墙或特定会话的问题；它只是第一道排除项。

如果多个会话同时重连，优先检查网络切换、代理是否仍在运行，并尝试在稳定连接下重新打开 Codex。若只有一个旧会话出问题、同一环境下新会话可以响应，则优先检查这个会话的恢复状态及任务负载。不要仅凭这种对照就给出“长上下文导致断流”的结论。

恢复原会话，先看历史再继续

Codex CLI 的官方命令定义支持 codex resume 打开会话选择器，也支持用会话 ID 指定原会话。在原项目目录执行：

codex resume
codex resume <SESSION_ID>

第二行的 <SESSION_ID> 要换成真实 ID，不要连尖括号一起输入。桌面端则从会话列表重新打开同一会话。恢复后先看最后一轮的状态、已生成的文件和未发送草稿，再决定是否继续；不要把“重新看到聊天记录”理解为“上一轮操作一定完成”。

如果重连仍失败，记录错误提示和发生时间，检查客户端版本及网络环境。向维护者反馈时，提供可复现步骤、是否只影响旧会话，以及去除令牌和私人路径后的日志，比只写“长会话卡住了”更有用。

只有连接恢复后，才处理长上下文

如果原会话已经能继续，但历史过长、目标反复被误解，可以在 CLI 中用 /compact 整理上下文。OpenAI 官方源码显示，压缩会生成摘要并替换当前使用的历史；其代码也提醒，长线程和多次压缩可能降低模型准确性。因此压缩前应把关键要求、已做决定和待验证事项留在项目文件中。

若同一个会话反复无法稳定推进，建立新会话时只交接已确认的事实。下面的交接文字可直接改写使用：

当前目标：……；项目目录：……；已经确认完成：……；工作区现有变更：……；上一轮未确认是否执行：……；下一步先检查……，确认后再继续。不要重复执行未确认的写入或发布操作。

这段交接的重点是标出“不确定”，而不是替旧会话补一个看似完整的结论。会话历史、任务执行和文件状态要分别核对。

一个可靠的恢复顺序

Codex 长会话断流时，先保留草稿与文件状态，再查官方服务和本地连接，随后恢复原会话并核对上一轮结果；压缩或新建会话放在最后。这个顺序对应 OpenAI 官方源码中的响应重试、会话重连与历史压缩机制，能减少重复操作。本文信息核验截至 2026 年 10 月 13 日。

参考资料