Codex “thread not found”: Troubleshooting and a Recovery Case

Codex’s “thread not found” error does not necessarily mean your history is gone. First, check whether only sending fails or whether you cannot open the conversation either.

1. What is missing when Codex says thread not found?

OpenAI’s Codex may show an error like the following when you send a follow-up to an existing task. The ID identifies the conversation; it is redacted here. The first line below translates the Japanese message observed in our case.

An error occurred while sending the message
thread not found: <conversation ID>

This article covers existing local tasks in the desktop app. On September 21, 2026, we cross-checked failed-send logs from our own computer against public source code and user reports. The focus is our Windows case, not a repair method demonstrated to work in every environment.

The official App Server specification explains that thread/read reads saved history without loading the conversation into runtime memory. Its role differs from thread/resume, which resumes a conversation so work can continue. These are internal communication methods, not commands to type into chat.

We also checked CLI version 0.155.0-alpha.9, recorded in our computer’s saved metadata, against the corresponding public source code for sending. The entry point for turn/start retrieves the conversation and returns thread not found if that lookup fails. It looks in the in-memory list of conversations, so this error alone does not show that saved files have disappeared.

notLoaded is not inherently an error state. It means a saved conversation is not currently loaded for execution. The problem arises when the required resume step does not happen and the conversation cannot accept the next instruction. The wording alone cannot distinguish normal unloading, a problem locating stored data, an incorrect conversation ID, or other causes.

2. A real case: sending recovered without deleting history

In AI Arte’s working environment, this error appeared when we sent a continuation instruction to another task in Windows app version 26.915.31029. The timeline below summarizes the app logs from September 21, 2026. All times are Japan Standard Time (JST); conversation IDs, work details, and personal information have been omitted.

The saved conversation and working directory existed, and reading the history succeeded. The original task was not archived. We inspected logs and stored state on a read-only basis, without changing the conversation database or settings.

A mismatch between the interface’s “resumed” state and the internal state is a strong explanation. However, we did not reproduce the problem to identify exactly how that mismatch arose. Checking the latest turns’ status is also different from verifying the correctness of the work done in those turns. Our recovery checks cover sending and conversation state only.

3. What to try when only sending fails

First, keep a copy of your input so you do not lose it. Before repeatedly pressing send, check whether the same instruction has already appeared in the conversation or processing has started. Avoid duplicating a request whose response is merely delayed, especially if it involves publishing, deleting, or buying something.

For example, keep the check narrowly scoped as below. This is an instruction to the model, not a command that repairs the app. Sending it and receiving a model response may count toward normal usage.

This is a connection check. Do not resume earlier work, read or write
files, or call tools. Reply only with “Response received.”

Report #30710 in OpenAI’s GitHub repository describes a Windows case where restarting improved sending failures immediately after opening a conversation. The official troubleshooting guide recommends waiting for active tasks to finish and restarting when the built-in terminal is stuck. That guidance is not a recovery procedure specifically for this send error. Neither source guarantees that restarting fixes every thread not found error.

If you try an update, first record your current app version and symptoms. The Codex version bundled with the app may differ from a separately installed CLI. Updating only the CLI does not establish that the desktop app’s issue is fixed. We have not identified a version that permanently resolves this symptom.

4. Similar messages, different causes and remedies

Look beyond a heading saying that sending failed: read the remaining error text and identify the operation that failed. The table below groups public reports and our observations; it is not a ranking of how often each problem occurs.

For an example where history remained available, see the macOS user’s follow-up in #30710. The interface treated the conversation as resumed, but sending repeatedly failed; a new interface instance later reloaded it successfully. This describes a state mismatch that cannot be explained solely by a race immediately after opening. It resembles our case, but the cause has not been proven identical.

By contrast, Windows report #39179 describes failures in both sending and archiving that persisted after restarting. #39575 also includes a diagnosis involving timestamps in saved filenames and the lookup process. These are user investigations, however. A path prefix or time-zone difference alone is not proof that your own data is damaged.

For failures after a wait, see the send-timeout report in #27395; for failures that also affect stopping, see the history/runtime-state mismatch report in #42604. Reports of similar messages do not establish that the problem occurs frequently across all users. Our investigation found no incidence rate measured against a denominator of users or send attempts.

5. Checks and handoff options if the problem persists

If restarting does not help, check whether saved history can be read. If your environment provides a way to inspect the affected task from another working Codex task, start with a read-only check. Make sure the target ID is correct rather than selecting a similarly named task.

Investigate the target task on a read-only basis.
Target ID: paste the conversation ID shown in the error here

Report whether its history is readable, the last turn’s status, and any errors.
Do not send messages to another task, resume earlier work, fork, archive,
change settings, edit the database, or move or delete history files.
If no task-management tools are available, report that limitation.

This is an example request for an environment with task-management tools. Those tools are not available in every interface or CLI. If you cannot find the capability, there is no need to guess and run similarly named internal commands.

A follow-up in #39179 describes a short check sent from another working task; after its response completed, normal conversation also recovered. However, another follow-up reports that the same kind of send failed, while a fork of completed history accepted a new instruction. In response to this counterexample, the earlier reporter clarified that this was not a general solution.

Forking is an option for carrying completed history into another task, not a repair of the original task. Do not assume unfinished work will be reproduced as it was. After the handoff, check the working directory, changed files, and the last completed step. A public report that a new instruction was accepted also does not guarantee that the subsequent work finished correctly.

Conversation history and working files are separate, too. Project edits may remain even if the conversation will not open. Conversely, readable history does not guarantee that files are current. In a Git project, review the changes and establish what has already run before continuing.

6. What to record when requesting help

Separate what succeeded from what failed, rather than reporting only “I cannot send.” The app version, OS, time and time zone, conversation ID, and preceding action help distinguish different kinds of failure. You do not need to publish the entire conversation at the outset.

If you can inspect logs, look around the failed request. method=turn/start marks the start of an instruction, thread/resume resumes a conversation, and errorCode provides a clue to the internal response. Keep successful entries too, and distinguish one failure appearing in several log lines from multiple actual failed requests.

On our Windows computer, app logs were in %LOCALAPPDATA%\Codex\Logs. That is the location we verified on this machine, not a guarantee for every distribution. The official documentation places sessions in $CODEX_HOME/sessions, with a default of ~/.codex/sessions. Different settings or execution targets may simply mean the relevant data is not in the folder you are looking at. Failure to find it in a search does not establish that it was deleted.

The official troubleshooting guide explains how to send feedback by typing / in the composer. Logs and screenshots can contain conversation text, email addresses, other project names, and local paths. Include only the necessary, anonymized parts in a public issue. Before sharing full IDs or similar details, check the recipient and who can view the submission.

7. Confirm recovery with a short response

Instead of starting by deleting history, check three things separately: can you read it, can you resume it, and can a new instruction complete? Sending succeeded after reloading in our case, but that does not show that the same method resolves unrelated storage errors.

Once a short response completes, check how far the original instruction got and resume from the appropriate step. If the issue persists, prioritize read-only investigation and preserving logs. A disappearing error message or a successfully created fork is not enough to declare recovery complete.

Claude Code users may also encounter Prompt is too long, which concerns input capacity, or MCP error -32000: Connection closed, which calls for checking the connection to external tools. These are different errors in another product. Even when the symptom looks like “I cannot give the AI instructions,” choose your response using the product name and full error message. Their troubleshooting commands should not simply be reused in a Codex conversation.

FAQ

Q. Does thread not found mean the conversation was deleted?
A. Not necessarily. Saved history can remain readable even when the runtime conversation needed to receive a message is not loaded. However, there can also be problems with references to stored data or the files themselves, so check whether you can actually read the history.

Q. Is notLoaded an error?
A. The state name alone does not establish an error. It can describe a normal situation where a saved conversation is not currently loaded for execution. Check whether it resumes when you continue and whether a short response completes.

Q. Will restarting always fix it?
A. No. Some reports describe improvement, while others describe storage or archiving errors that persisted after a restart. On our own computer, we observed successful sending after the conversation reloaded; we did not run an experiment to test restarting.

Q. Will updating to the latest version solve it?
A. At the time of our review, we had not verified a specific release that resolves this entire class of symptoms. Record the app version and results before and after updating. A separately installed CLI and the Codex version bundled with the app are not necessarily the same.