Codex 出现“thread not found”，不一定意味着历史记录已丢失。先确认：是只有发送失败，还是连会话也无法打开？
先看错误提示后面的具体信息
删除历史记录前，先区分症状
thread not found
os error 2 / 存储相关错误
Timeout / request expired
目录
1. thread not found 到底缺少了什么？
OpenAI 的 Codex在向已有任务发送后续指令时，可能显示下面这样的错误。ID 用于标识会话，此处已隐去。下面第一行是我们案例中日语界面提示的中文翻译示例。
发送消息时发生错误
thread not found: <会话 ID>本文讨论的是桌面应用中已有的本地任务。2026 年 9 月 21 日，我们将自己电脑上的发送失败日志与公开源代码、用户报告进行了交叉核对。重点是这次 Windows 案例，不代表已验证适用于所有环境的修复方法。
读取历史记录与发送消息，需要分开检查
已保存的历史记录
查看过去的对话
thread/read
读取已存储的数据
已加载、可执行的会话
接收新的指令
thread/resume → turn/start
恢复会话 → 开始处理下一条指令
如果执行所需的会话无法找到，仍可能发送失败，即使过去的历史记录依然可见。
官方 App Server 规范说明，thread/read读取保存的历史记录，但不会将会话加载到运行时内存。它与thread/resume的作用不同，后者用于恢复会话以继续工作。这些是内部通信方法，不是让你在聊天框里输入的命令。
我们还核对了这台电脑保存的元数据中记录的 CLI 版本 0.155.0-alpha.9 及其对应的发送处理公开源代码。turn/start 的入口会获取会话，查找失败时返回 thread not found。查找对象是内存中的会话列表，因此仅凭这个错误，不能判断已保存的文件已经消失。
notLoaded 本身并不是错误状态。它表示已保存的会话当前没有加载为可执行状态。真正的问题是：需要恢复时没有完成恢复，导致会话无法接收下一条指令。仅凭提示文字，无法区分正常卸载、已存储数据的查找问题、会话 ID 错误或其他原因。
2. 实际案例：未删除历史记录，发送恢复
在 AI Arte 的工作环境中，向另一个任务发送继续执行的指令时，Windows 应用版本 26.915.31029 出现了这个错误。下面按时间整理了 2026 年 9 月 21 日的应用日志。所有时间均为日本标准时间（JST）；会话 ID、工作内容和个人信息已省略。
从界面重试，到会话真正重新加载
发送失败，内部返回 thread not found
界面此前已将会话视为已恢复
重新打开任务后，仍出现同样的发送错误
仅切换到其他任务再返回，没有解决问题
观察到未加载状态 → 会话重新加载成功
notLoaded → needs_resume → thread/resume 成功
新指令被接受，发送成功
之后检查历史记录，两轮均已完成，且没有错误
保存的会话和工作目录都存在，历史记录读取成功，原任务也未被归档。我们仅以只读方式检查日志与保存的状态，没有修改会话数据库或设置。
这个案例确认了什么
- 历史记录仍然存在
- 重新加载后发送成功
- 调查没有改动历史记录或设置
这个案例不能证明什么
- 运行时会话为何不可用的确切原因
- 重启一定能解决问题
- 所有用户都遇到了同一种原因
界面的“已恢复”状态与内部状态不一致，是一个有力的解释。但我们没有复现问题来确定这种不一致究竟如何产生。检查最近几轮的状态，也不同于验证这些轮次所完成工作的正确性。这里的恢复确认仅限于发送和会话状态。
3. 只有发送失败时，可以尝试什么
先复制保存输入内容，避免丢失。连续点击发送之前，确认同一条指令是否已经出现在会话中，或是否已开始处理。不要重复提交只是回复较慢的请求，尤其是涉及发布、删除或购买的操作。
检查会话与此前的工作
确认过去的消息能否读取，最新指令显示为已完成、进行中还是出错。保存已修改的文件，并记下工作目录。会话显示异常，本身不代表工作文件已丢失。
等待加载，再重新打开同一任务
如果刚打开任务，先等历史记录加载完毕。切换到另一任务后再返回，做一次小范围检查。我们这次仅靠此操作没有恢复，因此反复重发同一请求并不是有效策略。
确认其他工作后，正常重启应用
如果其他任务正在运行，等待其完成，或保存必要内容后停止。随后退出应用、重新启动，再打开同一任务。切换任务页面与重启整个应用，是不同操作。
确认一条简短回复能完整结束
先不要立即重发原来的大任务，而是发送无需修改文件或调用工具的检查请求。等回复完成，检查此前的工作，再恢复正常操作。
例如，可将检查范围限定如下。这是给模型的指令，不是修复应用的命令。发送请求并收到模型回复，可能计入正常使用额度。
这是连接检查。不要继续此前的工作，不要读写文件，也不要调用工具。
仅回复“已收到回复”。OpenAI GitHub 仓库中的报告 #30710描述了一个 Windows 案例：刚打开会话后发送失败，重启后有所改善。官方故障排查文档针对内置终端卡住的情况，建议等待运行中的任务完成后重启。这并非专门针对当前发送错误的恢复步骤。这两项来源都不保证重启能解决所有 thread not found 错误。
如果准备更新，先记录当前应用版本与症状。应用捆绑的 Codex 版本，可能与单独安装的 CLI 不同。只更新 CLI，不能证明桌面应用的问题已解决。我们尚未确认哪个版本能永久解决这一症状。
4. 提示相似，原因与处理方式可能不同
不要只看“发送失败”这样的标题，还要看后面的错误文字，确认是哪一步操作失败。下表整理了公开报告与我们的观察，并不是各类问题发生频率的排名。
| 可见症状 | 检查方向 | 不能直接推断 |
|---|---|---|
| 历史记录可读，但发送失败 | 重新加载后能否发送 | 历史记录可读，不代表能发送 |
| os error 2 / 归档也失败 | 保存的文件与引用的位置 | 单靠重启可能无法解决 |
| Timeout / request expired | 响应停滞、排队以及其他操作 | 不要与立即返回 thread not found 混为一谈 |
| 继续与停止都失败 | 工作是否实际运行，还是显示未更新 | 不要只依赖界面的运行中标识 |
对于历史记录仍可读取的情况，可参阅#30710 中 macOS 用户的补充报告。界面把会话视为已恢复，但发送反复失败；之后新的界面实例成功重新加载了会话。这是一种不能仅用“刚打开时发生竞态”解释的状态不一致。它与我们的案例相似，但尚未证明原因相同。
相比之下，Windows 报告 #39179描述了发送与归档同时失败，重启后仍未解决的情况。#39575还包含涉及保存文件名中的时间戳及查找过程的诊断。不过，这些是用户自己的调查。仅有路径前缀或时区差异，不足以证明你的数据已损坏。
等待后才失败的情况，可参阅#27395 的发送超时报告；连停止也失败的情况，可参阅#42604 的历史记录与运行状态不一致报告。相似错误提示的报告，并不能证明问题在全部用户中频繁发生。本次调查没有找到以用户数或发送次数为分母统计的发生率。
5. 仍未恢复时的检查与交接
如果重启无效，先检查保存的历史记录能否读取。如果你的环境允许从另一个正常的 Codex 任务检查故障任务，先做只读检查。确认目标 ID 无误，不要仅凭相似名称选择任务。
请以只读方式调查目标任务。
目标 ID：在此粘贴错误提示中的会话 ID
报告历史记录能否读取、最后一轮的状态，以及是否有错误。
不要向其他任务发送消息、继续旧工作、创建分支任务或归档。
不要修改设置或数据库，也不要移动或删除历史记录文件。
如果没有任务管理工具，请说明这一限制。这是具备任务管理工具的环境下的请求示例。这些工具并非每个界面或 CLI 都有。如果找不到相应能力，无需猜测并运行名称相似的内部命令。
根据检查结果，选择下一步
- 历史记录可读 / 此前工作已完成
- 可考虑再次检查发送，或创建继承历史记录的分支任务。保留原任务。
- 历史记录可读 / 运行状态不明
- 先检查运行状态与文件变更。不要在不同任务中重复执行同一工作。
- 历史记录不可读 / 出现存储错误
- 保留备份，并附日志报告问题。不要为了恢复读取而删除原始数据。
#39179 的一条补充报告描述了从另一个正常任务发送简短检查的情况；检查回复完成后，普通对话也恢复了。不过，另一条补充报告指出，同类发送操作仍然失败，而继承已完成历史记录的分支任务接受了新指令。面对这个反例，此前的报告者明确说明，这不是通用解决方案。
创建分支任务是将已完成的历史记录交接到另一任务的选项，并非修复原任务。不要假定未完成的工作会原样重现。交接后，检查工作目录、修改过的文件以及最后完成的步骤。公开报告中“新指令被接受”，也不保证后续工作已正确完成。
会话历史与工作文件也彼此独立。即使会话打不开，项目修改仍可能存在；反过来，历史记录可读，也不保证文件是最新状态。对于 Git 项目，继续工作前先检查变更，确认哪些操作已经执行。
6. 求助时应记录的信息
不要只说“发不出去”，应将成功与失败的操作分开记录。应用版本、操作系统、时间及时区、会话 ID 和此前的操作，有助于区分故障类型。不必一开始就公开整段对话。
问题报告模板
- 环境
- 应用版本 / 操作系统 / 本地或远程等执行目标
- 发生情况
- 时间与时区 / 完整错误文字 / 此前的操作
- 哪些可用、哪些失败
- 查看历史记录 / 发送 / 停止 / 归档的结果
- 已尝试的步骤
- 重新打开或重启前后的变化
如果能查看日志，请检查失败请求附近的记录。method=turn/start 表示一条指令的开始，thread/resume 用于恢复会话，errorCode 则有助于了解内部响应。成功的日志也要保留，并区分“同一次失败出现在多行日志中”与“多次请求实际失败”。
我们这台 Windows 电脑的应用日志位于 %LOCALAPPDATA%\Codex\Logs。这是在此机器上核实的位置，不保证所有发行方式都相同。官方文档给出的会话位置是 $CODEX_HOME/sessions，默认是 ~/.codex/sessions。设置或执行目标不同，可能只是相关数据不在你正在查看的文件夹里。搜索未找到，不能证明数据已被删除。
官方故障排查文档介绍了在输入框键入 / 后发送反馈的方法。日志与截图可能包含对话内容、邮箱地址、其他项目名称和本地路径。公开问题报告中只放必要且已匿名化的部分。分享完整 ID 等信息前，先确认接收方及提交内容的可见范围。
7. 用一次简短回复确认恢复
不要一开始就删除历史记录，而应分别检查三件事：能否读取、能否恢复、能否完成一条新指令？我们这次重新加载后发送成功，但这不能说明同一方法也能解决无关的存储错误。
简短回复完成后，检查原指令执行到了哪里，再从合适的步骤继续。若问题仍在，优先进行只读调查并保留日志。错误提示消失，或成功创建分支任务，都不足以宣布已完全恢复。
Claude Code 用户还可能遇到涉及输入容量的 Prompt is too long，或需要检查外部工具连接的 MCP error -32000: Connection closed。这些是另一款产品中的不同错误。即使表面症状都是“无法给 AI 发指令”，也应根据产品名称与完整错误信息选择处理方式，不要直接把相应排查命令套用到 Codex 会话中。
常见问题
Q. thread not found 表示会话被删除了吗？
A. 不一定。用于接收消息的运行时会话未加载时，保存的历史记录仍可能可读。不过，存储引用或文件本身也可能有问题，因此应实际检查历史记录能否读取。
Q. notLoaded 是错误吗？
A. 仅凭状态名称不能判断出错。它也可能只是表示已保存的会话当前未加载为可执行状态，这是正常情况。应检查继续时能否恢复，以及简短回复是否完成。
Q. 重启一定能解决吗？
A. 不能保证。有报告称重启后改善，也有存储或归档错误在重启后仍存在的报告。我们自己的电脑上观察到的是会话重新加载后发送成功，没有进行重启验证实验。
Q. 更新到最新版就能解决吗？
A. 截至本次检查，尚未核实有哪个特定版本能解决这一整类症状。请记录更新前后的应用版本与结果。单独安装的 CLI 与应用捆绑的 Codex 版本并不一定相同。
