Codex error submitting message: timeout or missing queued message

Before you press Send again

Save the draft somewhere private. Check both the conversation and any visible queued message: a failed-looking submission leaves you uncertain whether the work was accepted. Repeated sends can turn one unclear state into several.

Read the entire error rather than just its first line:

Error or situation	Start with	Do not assume
Submission times out before a reply starts	The timeout branch below	That the model has already started reasoning
The message mentions a queued follow-up that no longer exists	The queue-editing branch below	That your entire conversation was deleted
A new task itself cannot be created	Task creation timeout	That it is the same submission failure
A reply started and then disconnected	Stream disconnected	That the original prompt was never accepted

Fixes, by branch

If submitting a prompt times out

First inspect whether the existing task is still running or awaiting an action. If the previous turn has completed, check for your new message in the transcript before making another attempt.

If the prompt is clearly absent and nothing is running, retry it once. If it times out again, stop resending and compare with a fresh task in the same project using a short request that does not change files. Keep the original conversation intact.

• Fresh task responds, old task fails: the difference points toward the affected task or its live state. It does not prove that context length is the cause. If you continue elsewhere, carry over a concise summary of unfinished work and verify the files before resuming edits.
• Both fail: the issue may extend beyond that conversation. Record the errors and their timestamps before changing settings. A normal restart after saving drafts and completing other work can provide another controlled comparison.
• Original message appears later: do not send it again. Check whether it started the requested work and whether any duplicate prompt remains queued.

The original timeout report describes intermittent failure followed by later success. Its proposed internal explanation is the reporter’s analysis. A separate commenter found a fresh task responsive while an older one remained slow. Neither establishes a waiting time that will fix every account.

If a queued follow-up no longer exists

This branch applies when the full message names a missing queued follow-up, especially after editing a prompt queued during another turn.

1. Save the intended follow-up outside the composer so you can recover its text.
2. Inspect the current queue and conversation for that prompt. Do not assume the edit was accepted or that the original was removed.
3. Leave the project chat and return to it, without deleting or archiving the task. This is a reported workaround from the queue-editing thread, not a verified universal fix.
4. Recheck the queue. If the prompt is absent, wait until the running turn finishes and submit the saved text once as a new follow-up. If it is already present, avoid adding a duplicate.

If the same error persists, retain the original task and record whether the failure occurs only after editing queued text. That detail is more useful than reporting simply that sending is broken.

If the suffix is different

Do not apply a queue-editing workaround just because the first line matches. Record the suffix and the operation immediately before it. For example, authentication, file attachments and task creation can fail at different stages and require separate evidence.

How to tell it worked

The intended prompt should appear once, start a turn and receive a response. Disappearance of the error alone is insufficient. If you were editing queued work, also check that the remaining queue represents what you still want done.

What to include in a bug report

Record the app build, OS, full error, timestamp and time zone, whether another turn was running, and whether the message was new or an edited queued follow-up. Include the fresh-task comparison when relevant. Redact private prompts and credentials from screenshots and logs.

These reports do not establish database corruption. Deleting local databases, account credentials or task history would discard evidence and is not a repair recommended by this guide.