Codex 任务没做完就停了？状态核对、继续执行与完成验证

Codex 说“接下来我会修改”，随后没有动作；只完成了第一项，就问“要继续吗”；已经回复“完成”，约定的文件或验证结果却没交付。先确认当前回合是否真的结束，再查实际做到了哪一步，最后继续明确的剩余工作。回合结束、命令退出和整个任务完成，是三个不同的判断。

本文处理 Codex 任务没做完就停、一直要你说继续，以及 codex stops before finishing、codex keeps asking to continue。这些描述不对应一个统一根因：等待输入、工具失败、限额、上下文问题和提前给出最终回复，都可能让人觉得“它不做了”。没有观察到原因时，先记为未知，不直接判定模型故障。

先按你看到的状态分流

当前现象	先做什么
还有运行状态，工具或命令输出仍在更新	第 1 步确认进度与后台命令，不重复提交同一任务
等待批准，或正在问一个必须回答的问题	第 2 步核对具体请求，处理这一项输入
明确出现额度、连接、压缩或工具错误	第 2 步按错误阶段处理，重试前核对已发生的操作
最终回复只有方案、“下一步会做”或“要继续吗”	第 3、4 步核原任务范围与未完成项，再明确继续什么
说已完成，但文件、测试或交付物对不上	第 3、5 步直接核成果，口头完成标志不能替代验收
用户取消了回合，但担心命令或改动仍在	第 1、3 步分别核后台工作与磁盘状态；停止不等于撤销

1. 先确认执行端和回合状态，不靠 Git 判断有没有停

适用条件： 只看到一段回复、输出暂时不更新，或 App、CLI、IDE 的表现不同。

先留在出问题的聊天中，记录客户端与版本、执行位置、当前项目／worktree，以及最近一次可见动作。查看该客户端实际提供的状态：

1. 回合仍显示运行，还是已经结束、失败或取消？
2. 有没有待审批的动作、必须回答的问题、错误原文？不要把普通进度说明当成待回答问题。
3. 工具调用或后台命令是否还在执行？记录最后输出与观察时间，不凭“几十秒没新字”给出统一超时结论。

对支持这些命令的 CLI 会话，可在输入框分别查看：

/status
/ps

CLI 官方命令参考说明，/status 可核当前模型、权限、目录和 token 使用；这里的上下文使用不能直接当套餐窗口余额。/ps 查看当前会话的后台终端及近期输出，后台终端列表依赖 unified_exec，空列表不能证明所有外部进程都已退出。

桌面端与 IDE 应使用各自实际可见的状态、工具记录和终端；先在 / 菜单确认支持的命令。按桌面端命令说明，命令会随环境和访问能力变化，不把 CLI 的 /ps 套到所有界面。

预期结果： 能区分“仍在运行”“等待输入”“已结束”或“状态尚未确认”。git status、空 diff、一个已经生成的文件都只能提供成果线索，不能单独证明回合已经停止。

如果还不清楚： 保留状态和最后动作，先检查现有终端或错误记录。若确实需要停止，使用该客户端的停止入口，并继续核对后台工作。CLI 的 /stop 会停止当前会话的所有后台终端，不适合只为观察状态而执行；也不能把它视为撤销文件或外部操作的命令。

2. 有输入或错误时，先处理那个阻塞

适用条件： 已观察到待审批、待答问题、明确错误或取消状态。以下是分流线索，可以同时存在，并非互斥的根因表。

• 待审批： 核对请求的命令、路径、目标和用途。原任务需要且你有权批准时，再处理这一项；不为“让它继续”统一开启全部权限或自动批准。若自动审查拒绝，先读理由，评估能否在现有边界内换用允许的方法；管理策略限制应交给有权的人处理。
• 待回答问题： 只补缺少的信息，例如目标分支、需要保留的方案或缺失输入。若目标早已清楚，只是反复问“要继续吗”，转第 4 步把原授权和剩余步骤写清楚。
• 明确限额错误： 核当前账号、计划和实际限额窗口，按界面指示等待或处理；拆小任务有助于安排后续工作，不能绕过已耗尽的限制。参见额度窗口与重置排查。没有限额证据时，不把早停都归因额度。
• 传输或工具错误： 保存错误原文及发生阶段。先确认命令、写入或远端操作是否已经发生，再决定是否重试。任务命令联网按网络排查处理；CLI 非交互输出与退出按exec 排查处理。传输断开不证明刚才的操作没有完成。
• 明确上下文／压缩错误： 留存目标、约束、已完成和未完成项，核当前文件，再决定是否交接到新聊天。/compact 用摘要替换较早上下文，不是恢复丢失文件或增加模型真实容量的方法；新聊天也不保证治好所有早停。找原聊天可参考恢复会话指南。
• 用户取消或环境断开： 分开核对回合、后台命令与实际产物；不要把取消后的文件变化当成必然已回滚。

预期结果： 明确“哪个已观察到的阻塞、需要什么输入、谁能处理、之后验证什么”。官方卡住恢复建议也先要求检查审批、用基本命令核状态，再考虑更小、更聚焦的新聊天；它没有承诺所有提前结束都属于同一个故障。

如果没有已知阻塞： 转下一步检查真实成果。不要仅因没看到错误，就声称是已确认的模型 bug。

3. 核对真实已做、未做与已有修改

适用条件： 回合已结束，但你不确定做到了哪里，或“完成”与实际结果不符。

先把原请求拆成可检查的结果，例如“修改输入校验、补一个相关测试、运行项目检查”，逐项对照文件、工具记录和产物。记录检查的是哪台主机、哪个目录、哪个版本，以及结果时间；旧文件、上一次日志或另一个 worktree 的成功结果不能直接算本次完成。

在实际任务所在的 Git 仓库中，可分别运行以下查看命令。不在 Git 仓库就直接检查目标文件和产物，不必为排障新建仓库。

git rev-parse --show-toplevel
git --no-optional-locks status --short --branch --untracked-files=all
git --no-pager diff --no-ext-diff --no-textconv --
git --no-pager diff --cached --no-ext-diff --no-textconv --

两份 diff 分别查看未暂存与已暂存的已跟踪内容；未跟踪文件从 status 单独找出，再查看实际内容。按 Git status 与 Git diff 的范围，普通检查不会完整展示忽略文件或所有历史提交。大文件、二进制文件和非 Git 产物也需要按原任务另验。

预期结果： 每项能标为“已有可核对结果”“尚未完成”“已尝试但失败”或“证据不足”。Git 干净可能是改动已提交、目录选错或没有改动，不能单独判成功；有 diff 也不能证明全是 Codex 改的、或目标已经正确实现。

已有用户修改时，先保全当前文件、未保存缓冲区和必要的改前资料，不使用 reset、clean 或整文件还原来“重新开始”。同一文件混有用户和 Codex 改动且无法分离时，保留现状、人工核对；参见保留原有修改的检查与还原边界。找不到改动先查worktree 位置，不要对另一个目录重复修改。

需要让 Codex 帮忙核对时，可先发一个只读请求；这仍是任务调用，不代表零额度消耗：

先只读核对，不修改文件，不重跑写入或远端操作。
原任务与完成条件：[填写具体要求]
当前项目、执行位置与分支/worktree：[填写]
请结合当前文件、已有工具结果和产物，逐项列出：
已完成的证据、未完成步骤、已知阻塞、仍未知的部分。
不要把最终回复、旧日志或计划文本当成已执行结果。

4. 一直要你说继续：明确继续哪项，而不是无限重试

适用条件： 已确认本轮结束、没有必须由你解决的输入，原任务仍有已授权但未完成的步骤。

先判断上一条是计划还是执行结果。如果原请求只要求分析或方案，给出方案后结束可以是正常完成；若你已经要求实施，回复“接下来会做”则仍需核实际修改。计划模式排查可用于确认当前交互与原授权是否一致。

把第 3 步查到的剩余项写回同一聊天；任务范围清楚时，可以使用：

继续原任务中已经授权的剩余工作。
已核对完成：[结果及证据]
还需完成：[具体步骤及各自验收条件]
保留现有用户修改，不重复已完成的写入或远端操作。
按现有权限执行；遇到缺信息、审批、错误或范围外动作时，
说明具体阻塞和需要我做什么，不自行扩大权限。
结束时逐项给出实际结果与验证证据；未做、失败或无法验证的如实标明。

预期结果： 出现针对剩余工作的实际动作和新证据，或得到一个可以处理的具体阻塞。“好的，我继续”本身不是进展。约定完成条件能减少歧义，但不能保证修复模型或服务故障；完成标志、勾选清单和模型自报也仍要对照真实结果。

如果又在同一点结束： 保存两次的状态、原始回复和证据差异，先缩小到一个可以独立验收的剩余目标，不连续发送无内容的 continue。确需新聊天时，交接目标、约束、当前目录、用户修改、已做证据和下一步，先核项目现状，再继续；不要复制整段聊天后假定所有状态都已保留。

5. 怎样确认这次真的做完？

适用条件： Codex 再次回复完成，或你准备结束、提交或交付任务。

按原任务验收，不为所有任务套同一组命令：

• 修改代码或文件： 打开正确路径的当前内容，审查目标行为、改动范围及未涉及内容。新文件要实际存在，不能只看计划中的路径；无法分离的原有修改仍需单独核对。
• 运行检查或测试： 核准确命令、目录、退出状态与新输出，确认运行了预期检查。退出 0 仍可能没有收集到测试或大量跳过；失败、未运行与无法验证要分开报告。不要为凑全绿削弱断言或忽略原失败。
• 生成文档或其他产物： 确认本次文件可打开、内容符合需求、交付链接可用，不以一句“已生成”或旧文件名代替。
• 提交、推送或创建 PR： 本地修改、提交、远端分支和 PR 分别验收；只有原任务确实包含且已授权时才继续。参见推送与 PR 完成验证，不要因为回复停了就重复创建。

成功标准： 所有约定项都有对应结果和适用的验证；用户修改与原范围得到保留；没有把失败或未验证项写成完成。若还有阻塞，应明确交接“完成到哪、剩什么、需要谁处理”，而不是声称全部成功。

长期复用的完成条件可以审阅后写进项目规则，参考 AGENTS.md 模板。这有助于表达需求，不是让 Codex 忽略审批、绕过限制或无限运行。

仍反复提前结束时，提交什么信息？

保留客户端／版本、执行环境、观测时间与时区、最小任务及完成条件、回合状态、最后动作、错误原文、已完成／未完成证据，以及是否在新的小任务中仍出现。通过客户端支持的反馈入口提交必要材料；发送前去掉令牌、邮箱、私有代码、客户内容和无关路径，不默认公开完整聊天或日志。

社区的旧版本报告能提供排查线索，不能证明你当前遇到相同根因。本文于 2026-10-19 核对官方状态恢复与命令资料，并在独立 Git 仓库核验查看命令的范围。未调用真实模型、复现所有客户端早停或验证某句提示词能修好故障；具体任务是否恢复，仍以执行端的新状态和真实成果为准。