真正完成并可交付的任务，必须同时通过三重验证：有可验证的执行证据、文件改动与初始目标严格一致、且没有 handoff 标记或待确认项；否则一律按未完成处理。

想快速判断 Codex 历史任务里哪些已经真正落地、哪些仍停留在中途，不能只看最后一句“已完成”，而要结合文件改动、执行结果和 handoff 状态进行三重核验。

看任务结尾有没有带验收证据

查看历史 thread 时，先直接定位到最后一条 Codex 回复。若回复内容只是“已修改 login.js”或“任务完成”，【这不算完成】。符合标准的完成回复，必须附带至少一项可验证证据，例如：diff 片段、运行命令输出、生成文件的首尾行，或截图中的关键状态（如“登录后跳转至 /dashboard”）。如果缺少证据，所有“完成”表述都应默认视为未完成。

这一步其实很容易，直接滚动到底部扫一眼即可。但很多人会忽略这一点——因为 Codex 的表达方式容易让人误以为“说完成了”就代表真的完成了。

查文件列表是否匹配初始目标

方法一：用 Codex 自带的文件摘要功能
点击 thread 右上角「⋯」→ 选择「Show file changes」。系统会列出所有被读取、新建或修改的文件名。对照你最初下达的任务指令，确认：新增或修改的文件是否完全落在你指定的范围内？有没有多出 config.yaml、test_helper.py 这类未提及的文件？

方法二：手动检查 diff 标题行
在改动详情里，每个文件块开头都有一行类似 --- a/src/auth/login.js 的路径标识。重点核对 a/（原文件）和 b/（新文件）的路径是否一致，并且都在你给定的项目子目录内。如果出现 --- a/../secrets.json，说明它已经越界，任务实际上并未完成。

识别未完成任务的三大手写标记

第一步：找 handoff 段落
在 thread 中搜索关键词 handoff、next step、waiting for、pending、blocked。只要出现其中任意一个，该任务通常就处于未完成状态。Codex 不会主动标注“未完成”，但它往往会在中断处留下交接线索。

第二步：确认 handoff 是否包含可执行动作
有效的 handoff 必须带有明确、可落地的指令，例如：“请运行 npm test -- --testPathPattern=auth” 或 “等待你提供 API_KEY 后继续”。如果只写“后续再处理”“等你确认”这类表述，【这不是 handoff，是放弃】，此类任务应判定为失败，而不是未完成。

第三步：检查是否有悬而未决的待确认项
翻看 Codex 最后一次回复中带编号的提问，例如“① 是否允许删除旧日志表？”“② 预约发布时间统一设为 UTC+0 吗？”。只要存在未答复的编号问题，任务就处于暂停状态，不算真正完成。