先看错误后面的文字
删除历史记录前，先区分症状
thread not found
存储位置引用错误（历史记录通常仍能读取）
Timeout / App server request expired while queued
目录
1. “thread not found”到底找不到什么
在 OpenAI 的 Codex 中向已有任务继续发送消息时，可能会出现如下错误。末尾的 ID 用于标识目标对话，以下内容已隐去。
メッセージの送信中にエラーが発生しました
thread not found: <对话ID>在英文界面的应用中，第一行会显示为 Error submitting message（#30710）。
Error submitting message
thread not found: <对话ID>本文针对的是桌面应用中已有的本地任务。我们依据在自身环境（Windows）中遇到的一个案例的日志、公开源代码以及用户的故障报告进行整理，信息截至 2026年9月21日。
“能读取”与“能发送”是两项不同的确认
已保存的历史记录
读取过去的往来内容
读取已保存的数据
为执行而加载的对话
接收新的指令
恢复对话 → 下一条指令
如果找不到用于执行的对话，即使能显示过去的历史记录，发送也可能失败。
显示历史记录与接收新指令是两套不同的机制。对于一段时间没有使用的任务，历史记录虽然能读取，但接收指令一侧可能并未加载该对话，此时直接发送就会出现这个错误。
机制详情（应用内部的通信名称）
根据官方 App Server 规格，thread/read是读取已保存历史记录的操作，并不是把对话加载到执行内存中的操作。它与用于继续对话的thread/resume作用不同。这些都是应用内部的通信名称，并不是要在聊天框中输入的命令。
与我们环境保存的元信息中所示的 CLI 版本0.155.0-alpha.9相对应的发送处理的公开源代码中，turn/start的入口会获取对话，获取失败时返回thread not found。获取的来源是内存中的对话列表，因此这个错误并不意味着保存文件丢失。
notLoaded是已保存的对话当前未被加载用于执行的正常状态。根据官方 App Server 规格，最后一个订阅者离开的对话，若在无订阅者且无任何活动的状态下持续30分钟，就会被卸载，并变为notLoaded。问题在于：从这种状态出发，没有进行必要的恢复处理，因此无法接收下一条指令。在我们的例子中，失败也是发生在上一次成功发送之后超过一小时的时候。
2. 实例：保留历史记录后发送恢复了
这是我们环境中出现的例子。在 Windows 版应用26.915.31029的一个任务中，发送继续执行的指令时出现了此错误。以下是将2026年9月21日的应用日志统一换算为 UTC 时间，并省略对话 ID 与任务内容后整理的结果。
从屏幕上的重试到实际重新加载
发送失败（内部响应为 thread not found）
界面端已将其视为已恢复
重新打开后，仍是同样的发送错误
仅切换界面并没有改善
确认为未加载状态 → 对话重新加载成功
未加载 → 判断需要恢复 → 恢复成功
接收下一条指令，发送处理成功
之后检查历史记录时，两个轮次均为 completed，且无 error
已保存的对话和工作目录都还在，读取历史记录的操作也成功了。原任务并未被归档。
本例中确认的事项
- 历史记录仍然存在
- 重新加载后发送成功
- 排查过程中未更改历史记录或设置
本例无法说明的事项
- 对话在内部脱离加载状态的确切原因
- 对所有用户都通用的原因
推测原因是界面将对话视为“已恢复”，而内部实际上并未加载该对话，二者不一致。发送恢复之后，还请确认该轮次的工作内容是否正确。
3. 只有发送失败时的尝试顺序
首先，把输入的内容记在手边，以免丢失。在反复点击发送按钮之前，请先确认同样的指令是否已被添加到对话中，或者处理是否已经开始。特别是包含发布、删除、购买等操作的指令，重要的是不要叠加发送那些响应延迟的请求。
确认对话与刚才的工作
确认能否读取之前的发言，并看最后一条指令是显示为已完成、进行中还是出错。如果列表中没有该任务，也请打开设置中的“Archived chats”（参见官方故障排除指南的说明）。如果有编辑过的文件，请先保存并记下工作位置。对话显示的异常和工作文件的丢失要分开看待。
等待加载后，重新打开同一任务
如果刚打开，请等待历史记录显示稳定。切换到其他任务再切回来，然后试着发一条小的确认消息。在我们的例子中，仅靠这一步没有解决，因此与其反复重发同一条消息，不如进入下一步。
检查其他工作，然后彻底重启应用
如果有其他任务在运行，请等它完成，或保存必要内容后停止。然后退出应用，重新启动，并打开同一任务。切换任务视图与重启整个应用是两种不同的操作。
确认简短的回复能否完成
不要立刻重发原来的大任务。发送一条不涉及文件修改和工具调用的确认消息。回复完成后，核对刚才的工作内容，再回到正常的工作流程。
确认消息可以像下面这样限定范围。由于它是作为普通指令发送给模型的，可能会和平常一样消耗用量。
这是连接确认。请不要恢复之前的工作，
也不要读写文件或调用工具，只需回复“已成功响应”。OpenAI GitHub 仓库中的报告 #30710里，有一个例子：在 Windows 上刚打开对话后出现的发送失败，通过完全重启应用得到了解决。官方故障排除指南中“等待运行中的任务完成后再重启”的步骤，是针对内置终端卡死时的指引，并不是针对这种发送错误的。
如果要尝试更新，请先记录当前的应用版本和症状。根据官方故障排除指南，桌面应用内置的 Codex 与单独安装的 CLI 版本可能不同。更新 CLI 并不代表应用端的问题已被修复。
4. 同样的提示，原因和处理方法并不唯一
不要只凭“发送消息时出错”这一行标题来判断，要看其后的文字和失败的操作。下表按症状区分了公开报告及我们环境中的例子。
| 可见症状 | 需要确认的内容 | 不要急于下结论的地方 |
|---|---|---|
| 历史记录能读取，但无法发送 | 重新加载后能否发送 | 能读取历史记录，并不代表能发送 |
| 归档也失败/os error 2 | 已保存文件及其指向位置的状态（历史记录通常仍能读取） | 重启后发送恢复了，归档仍可能持续失败 |
| Timeout/App server request expired while queued | 是否等待了约30秒、是否停止响应、排队状态如何 | 不要与立即返回的 thread not found 混为一谈 |
| 继续失败，停止也失败 | 是真的在运行，还是显示的是旧状态 | 不要只相信界面上的运行中标识 |
历史记录仍然保留的例子中，#30710 中 macOS 用户的追加说明很有参考价值。界面将其视为已恢复，但发送仍反复失败；之后在新的界面中重新加载就成功了。这是一个状态不一致的报告，无法用“仅在打开的瞬间出现的竞态条件”来解释，其经过与本文的案例非常相似。
另一方面，Windows 报告 #39179中，历史记录可以读取，但发送和归档都失败，而在报告者的环境中，即使重启后问题仍在持续。后续的补充中还有报告称：完全重启应用后可以继续对话，但归档失败并未被确实修复。#39575中有关于已保存文件名中的时间戳及引用处理的诊断信息。这些都是用户自己的调查，因此即使只是路径前缀或时差不同，也不要断定自己的数据已经损坏。
会等待的类型可见于#27395 中的发送超时报告，其中的日志显示turn/start在30秒（timeoutMs=30000）时被中断，并以Timeout失败。在#23644的补充中，发送所依赖的请求在排队中等待了约30秒（queueWaitMs=30001），最后以App server request expired while queued失败。停止也失败的类型，可以在#42604 中关于历史记录与执行状态不一致的报告中看到。
5. 仍然无法恢复时的确认与交接
如果重启后仍然无法恢复，请确认能否读取已保存的历史记录。如果有一个功能，可以让正常运行的 Codex 任务读取目标任务，请从只读确认开始。同时要注意，不要把目标 ID 与名称相近的任务混淆。
请以只读方式调查目标任务。
目标 ID：此处填入错误中显示的对话 ID
请报告：历史记录能否读取、最后一个轮次的状态以及错误信息。
请勿向其他任务发送消息、恢复之前的工作、分叉、归档、更改设置、
编辑数据库，或移动、删除历史文件。
如果没有可用的任务管理功能，请说明这一点。此示例适用于可以使用任务管理功能的环境。如果找不到这类功能，请不要猜测名称相近的内部命令去执行，而是转到第6章的报告。
根据确认结果选择下一步
- 历史记录可以读取，且之前的工作已完成
- 可以考虑发送额外的确认消息，或使用分叉来延续历史记录。保留原任务。
- 历史记录可以读取，但不确定工作是否仍在运行
- 先确认运行状态和文件变更。不要在其他任务中重复执行同一工作。
- 出现存储错误（如 os error 2）
- 保留备份，并附上日志进行报告。不要为了修复加载而删除原件。
#39179 的补充中，有一个例子：从另一个正常的任务发送了一条简短的确认消息，待回复完成后，普通对话也恢复了。不过，另一条补充中报告了类似的发送失败，而对已完成的历史记录进行分叉后，新指令被接受了。针对这一反例，先前的报告者也补充说明，这并非通用的解决方法。
分叉是将已完成的历史记录交接到另一个任务的操作；原任务并不会因此修复。不要认为未完成的工作会直接继续。交接后，请确认工作目录、已变更的文件以及最后完成的步骤。
历史数据与工作文件也是分开的。即使对话打不开，项目的编辑结果也可能还在。反过来，即使能读取对话，文件也未必是最新的。如果项目使用 Git，请先查看变更列表，整理已执行的内容后再继续。
6. 请求调查时需要保留的信息
报告时，不要只写“发不出去”，还要区分哪些操作成功了、哪些失败了。注明应用版本、操作系统、发生时间与时区、目标对话 ID 以及刚进行的操作，便于在不混入其他故障的情况下追查。不必一开始就公开完整的对话内容。
报告备注模板
- 运行环境
- 应用版本/操作系统/运行位置（本地、远程等）
- 发生情况
- 时间与时区/完整错误文本/刚才进行的操作
- 能做与不能做的事
- 历史记录显示/发送/停止/归档各自的结果
- 尝试过的操作
- 重新打开、重启前后有什么变化
如果可以查看日志，建议关注失败请求前后的内容。method=turn/start表示指令开始，thread/resume表示恢复对话，errorCode是内部响应的线索。成功的日志行也要保留，并区分同一失败只是在多行日志中重复出现，还是确实失败了多次。
关于应用日志的位置，官方故障排除指南列出了 macOS 的~/Library/Logs/com.openai.codex/YYYY/MM/DD。在 Windows 上，我们的环境中有以下两个位置。
- 出现错误的电脑：
%LOCALAPPDATA%\Codex\Logs - 另一台电脑的 Microsoft Store 版本（2026年3月的日志）：
%LOCALAPPDATA%\Packages\OpenAI.Codex_<ID>\LocalCache\Local\Codex\Logs（该电脑上并没有%LOCALAPPDATA%\Codex这个文件夹本身）
根据Microsoft 的说明，打包应用在 AppData 中新建的文件会写入应用专用的位置，应用中看起来可能像在常规位置。如果在一个位置找不到，请也搜索另一个位置。会话的保存位置在官方说明中是$CODEX_HOME/sessions（默认值~/.codex/sessions）。如果设置或运行位置不同，可能只是所查看的文件夹中没有该目标，因此不要仅因为“搜索不到”就判定其已被删除。
关于将 Codex 的数据（CODEX_HOME）或应用本体移至其他驱动器后各项内容的位置，我们整理了核对记录，参见将 ChatGPT·Codex 移至其他驱动器。
官方故障排除指南中介绍了在输入框中输入/来发送反馈的方法。日志和截图可能包含对话正文、电子邮件地址、其他项目名称和本地路径。在公开的 Issue 中，请只附上必要的部分并进行匿名化处理；提供完整 ID 等信息时，请确认发送对象与公开范围。
7. 用简短回复确认是否已恢复
对此错误的第一步处理，不是删除历史记录，而是分别确认：能否读取、能否恢复、新指令能否完成。本例中，重新加载对话后发送恢复了。如果出现存储位置错误，则属于另一条路径，请转到第5章的确认步骤。
简短回复完成后，请确认原指令执行到了哪一步，然后从需要的步骤处继续。如果仍然无法恢复，请优先进行只读调查并保留日志。不要因为错误提示消失了，或者只是能创建分叉，就认为已经恢复。
相关文章：
- Codex 容量错误与用量额度耗尽的区别及处理方法（出现“Selected model is at capacity”时）
- Remote 的连接条件与断开后的确认步骤（运行位置与电脑休眠）
- Claude Code 的类似错误：Prompt is too long（输入容量）、MCP error -32000: Connection closed（与外部工具的连接）
FAQ
Q. 出现 thread not found 时，对话是否已经消失？
A. 不一定。已保存的历史记录可能仍可读取，但作为执行发送目标所需的对话可能尚未加载。另一方面，存储位置的引用或文件本身也可能存在问题，因此要确认能否实际读取。
Q. notLoaded 是错误吗？
A. 该状态本身是正常的。它表示已保存的对话目前未被加载用于执行。只有在继续时没有恢复、连简短回复也无法完成的情况下，才会成为问题。
Q. 重启一定能解决吗？
A. 不一定。既有完全重启后得以解决的报告（#30710），也有重启后发送与归档仍持续失败的报告（#39179）。在我们的例子中，是在重新加载对话后发送恢复的。
Q. 更新到最新版本就能解决吗？
A. 截至 2026年9月21日，我们没有找到明确表示已整体修复此症状的修正版本。更新时，请记录更新前后的应用版本和结果。单独安装的 CLI 与应用内置的 Codex 版本未必相同。
