Codex Desktop stuck after “Error submitting prompt/message”; delayed duplicate prompts became steered and Stop did not work
What version of the Codex App are you using (From “About Codex” dialog)?
Version 26.422.62136 (2176)
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Darwin 25.2.0 arm64 arm
What issue are you seeing?
I am seeing a Codex Desktop issue where prompt submission, conversation creation, queued/steered prompt handling, model display, and cancellation all behaved inconsistently.
Feedback ID:
019dd332-3bb6-7cf2-b06d-a231fded25b4
Current status:
The affected Codex session is still stuck/running. Clicking “Stop” does not appear to stop it, so usage/tokens may still be consumed. I was forced to wait since another existing conversation of mine was still running, and I would not like to interrupt it...
<img width="826" height="329" alt="Image" src="https://github.com/user-attachments/assets/43b4dc8b-a61c-4fcd-8447-57c16121d7f3" />
What steps can reproduce the bug?
During running another conversation in progress; I need to create a new conversation for a separate task:
- I submitted a prompt, but the app got stuck and did not start any conversation.
- The model selection area showed “Custom,” which was confusing.
- I submitted the prompt again.
- An empty/idle conversation was created, but it showed an error similar to “error submitting the prompt/message.”
- In that session, the actual model shown was “5.3 Codex Medium,” not “Custom.”
- I submitted again in the same conversation, but nothing happened at first.
- I also tried to start another conversation, but nothing happened at first.
- After a delay, the original session suddenly started working.
- My repeated prompt became a “steered” message.
- The later attempt to start another conversation also eventually created another running conversation.
- I clicked “Stop,” but nothing happened.
- The session is still stuck/running, and I am concerned that usage/tokens are being consumed unnecessarily.
What is the expected behavior?
- Prompt submission should either start a conversation promptly or fail clearly.
- Failed/retried prompt submissions should not later start unexpectedly as duplicate tasks.
- Queued or repeated prompts should not unexpectedly become “steered.”
- The model selector/display should consistently show the actual model being used.
- The Stop button should reliably cancel the running session and prevent further usage consumption.
Additional information
This appears to be app/session/queue/cancellation behavior rather than a normal model response issue, because the failure happened around submission, conversation creation, delayed retry behavior, and the Stop button.
- #19249: delayed/failed message submission, duplicated messages, eventual delayed execution
- #19831: stuck thinking loop, Stop not working, usage drain
- #17876: queued prompts unexpectedly becoming steered
- #12852: Codex Desktop stuck on Thinking and Stop not working
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Fresh macOS reproduction with a stronger UI/backend state split:
26.721.41059(build5848)0.146.0-alpha.3.126.5(25F71)019f9d39-2721-7372-bc26-df6020e58980After “Context automatically compacted”, the task stayed at Reconnecting 2/2. The Stop button remained active but did not reset or stop the task. A later prompt stayed in the queued/steered row instead of sending.
At the same time, Codex’s task-list metadata reported this exact thread as idle. This appears to be a lifecycle/UI state divergence, rather than simply a slow active turn.
Additional local evidence:
667,190,009bytestokens_used:1,591,327,355(clearly pathological metadata, not asserted billable usage)3,375characters and included delegation markupcodex doctor --jsoncapture had a successful WebSocket HTTP 101 handshake, provider reachability passed, and auth configuredExpected: an idle backend task should clear the spinner/Stop state; Stop should cancel/reset; queued prompts should send or fail clearly; compaction should not corrupt title/token metadata.
Safe recovery was to verify the clean worktree/commits plus a canonical SQLite lane receipt, then start a fresh task from live files. I deliberately did not fork or replay the 667 MB history.
A screenshot was captured showing the final response, “Context automatically compacted”, “Reconnecting 2/2”, the queued prompt, and active Stop button.