Codex "thread not found": Troubleshooting and a Recovery Case

1. What "thread not found" means

When you send a follow-up to an existing task in OpenAI's Codex, you may see an error like this. The ID at the end identifies the target conversation and is redacted below.

メッセージの送信中にエラーが発生しました
thread not found: <conversation ID>

In apps displayed in English, the first line reads Error submitting message (#30710).

Error submitting message
thread not found: <conversation ID>

This article covers existing local tasks in the desktop app. It is based on logs from an example we encountered in our environment (Windows), public source code, and user bug reports, and reflects the situation as of September 21, 2026.

Displaying history and accepting new instructions are separate mechanisms. For a task you haven't used in a while, history may load while the conversation isn't loaded on the side that accepts instructions. Sending as-is then produces this error.

2. Case study: sending recovered with the history intact

This is an example from our environment. This error appeared when we sent a continuation instruction on a task in the Windows app 26.915.31029. Below, app logs from September 21, 2026 have been converted to UTC and organized with conversation IDs and task details omitted.

The saved conversation and working directory remained, and the operation to read history also succeeded. The original task had not been archived.

The likely cause is a mismatch: the screen treated the conversation as resumed, but internally it had not been loaded. After sending recovers, also check that the work done in that turn is correct.

3. The order to try when only sending fails

First, save your input locally so you don't lose it. Before clicking Send again, check whether the same instruction has already been added to the conversation or processing has already started. Especially for instructions involving publishing, deleting, or purchasing, it's important not to stack requests that were delayed in responding.

For example, you can narrow the scope of the check message like this. Because it is sent as an ordinary instruction to the model, it may count toward your usage as usual.

This is a connection check. Do not resume previous work.
Without reading or writing files or making any tool calls,
reply only with "Response received."

The report to OpenAI's GitHub repository #30710 includes a case in which a send failure right after opening a conversation on Windows was resolved by fully restarting the app. The official troubleshooting guidance to "wait for a running task to finish before restarting" applies to cases where the built-in terminal freezes; it is not guidance for this send error.

If you try updating, first record your current app version and symptoms. According to the official troubleshooting guide, the Codex bundled with the desktop app and a separately installed CLI may be different versions. Updating the CLI does not mean a bug in the app has been fixed.

4. The same message can have different causes and fixes

Don't decide based on the "error submitting message" line alone; look at the wording that follows it and at the operation that failed. The table below separates examples from public reports and our environment by symptom.

For cases where history remains, the macOS user's follow-up in #30710 is useful. The screen treated the conversation as resumed, but sending kept failing; later, reloading in a new screen succeeded. This is a report of a state mismatch that can't be explained by a "race only at the moment of opening," and its course is very similar to the case here.

On the other hand, the Windows report #39179 describes history that could be read while sending and archiving failed, and in the reporter's environment this continued after restarting. A later follow-up also reports that after fully restarting the app, the user could continue, but the archiving failure was not reliably fixed. #39575 contains diagnostics about the timestamps in saved file names and the reference process. All of these are user investigations, so don't conclude that your own data is damaged just because there is a path prefix or a time difference.

The type that waits is shown in the send-timeout report #27395, which includes logs in which turn/start was cut off at 30 seconds (timeoutMs=30000) and failed as Timeout. In a follow-up to #23644, a request that a send depends on waited in the queue for about 30 seconds (queueWaitMs=30001) before failing with App server request expired while queued. The type where stopping also fails can be seen in the history and execution-state mismatch report #42604.

5. When it still won't work: checks and handoff

If it still doesn't work after restarting, check whether you can read the saved history. If you have a function that lets a working Codex task read the target task, start with a read-only check. It's also important not to confuse the target ID with a task that has a similar name.

Please investigate the target task in read-only mode.
Target ID: the conversation ID shown in the error

Report whether the history can be read, the state of the last turn, and any errors.
Do not send messages to other tasks, resume previous work, fork, archive,
change settings, edit the database, or move or delete history files.
If no task-management function is available, please say so.

This sample is for environments where task-management functions are available. If you can't find such a function, don't guess at internal commands with similar names; go to the report in Section 6.

A follow-up on #39179 describes a case where a short check message was sent from another working task, and after the response completed, the regular conversation was also recovered. However, another follow-up reports a similar send failing, and a new instruction being accepted by forking a completed history. In response to this counterexample, the original reporter added that it is not a general solution.

A fork is an operation that carries over completed history to a separate task; the original task is not fixed. Don't assume that unfinished work will simply continue. After the handoff, check the working directory, changed files, and the last step that finished.

History data and working files are also separate. Even if a conversation won't open, project edits may still be there. Conversely, even if you can read the conversation, the files may not be up to date. If your project uses Git, review the list of changes and work out what has already been run before continuing.

6. Information to keep when asking for an investigation

When reporting, separate not just "it won't send" but what succeeded and what failed. Including the app version, OS, time of occurrence and time zone, the target conversation ID, and the operation just before makes it easier to trace without mixing in unrelated failures. You don't need to publish the full conversation from the start.

If you can examine the logs, it helps to look at the lines before and after the failed request. method=turn/start marks the start of an instruction, thread/resume marks resuming a conversation, and errorCode is a clue to the internal response. Keep the successful lines too, and distinguish whether the same failure simply appears in several log lines or whether it actually failed several times.

For app log locations, the official troubleshooting guide lists ~/Library/Logs/com.openai.codex/YYYY/MM/DD for macOS. On Windows, in our environment they were in the following two places.

• PC where the error occurred: %LOCALAPPDATA%\Codex\Logs
• Microsoft Store version on another PC (logs from March 2026): %LOCALAPPDATA%\Packages\OpenAI.Codex_<ID>\LocalCache\Local\Codex\Logs (this PC did not have the %LOCALAPPDATA%\Codex folder itself)

According to Microsoft's explanation, files that a packaged app newly creates in AppData are written to a location private to the app, and may appear to the app as if they are in the normal location. If you can't find them in one place, search the other too. The official guidance says session data is stored in $CODEX_HOME/sessions (default ~/.codex/sessions). If your settings or execution location differ, the target may simply not be in the folder you're looking at, so don't conclude it has been deleted just because "search doesn't return it."

The official troubleshooting guide explains how to send feedback by typing / in the input field. Logs and screenshots may contain conversation text, email addresses, other project names, and local paths. In a public issue, include only the necessary parts after anonymizing them, and when sharing full IDs or similar, check the recipient and who can see it.

7. Confirm recovery with a short reply

The first response to this error is not to delete history, but to check separately whether you can read it, whether you can resume it, and whether a new instruction completes. In this case, sending recovered after reloading the conversation. If a storage error appears, it is a different path, so go to the checks in Section 5.

Once a short response completes, check how far the original instruction got, and resume from the step that is needed. If it still isn't fixed, prioritize a read-only investigation and preserving logs. It's important not to treat recovery as complete just because the error message disappeared or because a fork could be created.

A record of where things are after moving Codex data (CODEX_HOME) or the app itself to another drive is summarized in Moving ChatGPT and Codex to a different drive.

Related articles:

• Codex capacity errors vs. running out of usage limits, and how to fix them (when you see "Selected model is at capacity")
• Remote connection requirements and checks after disconnection (execution location and PC sleep)
• Similar errors in Claude Code: Prompt is too long (input size) and MCP error -32000: Connection closed (connection to external tools)

FAQ

Q. If I see "thread not found," has the conversation been deleted?
A. Not necessarily. Saved history may still be readable while the conversation needed as the send target for execution has not been loaded. On the other hand, the storage reference or the files themselves may have a problem, so check whether you can actually read them.

Q. Is notLoaded an error?
A. That state itself is normal. It means a saved conversation is not currently loaded for execution. It becomes a problem only when it isn't resumed when you continue and even a short response doesn't complete.

Q. Will restarting always fix it?
A. Not always. There are reports that a full restart fixed it (#30710), and reports that sending and archiving kept failing even after restarting (#39179). In our example, sending recovered after the conversation was reloaded.

Q. Will updating to the latest version solve it?
A. As of September 21, 2026, we found no fixed version that explicitly states it resolves this symptom overall. When updating, record the app versions before and after and the results. The separately installed CLI and the Codex bundled with the app are not necessarily the same version.