Codex Desktop stuck after “Error submitting prompt/message”; delayed duplicate prompts became steered and Stop did not work

Open 💬 2 comments Opened Apr 28, 2026 by SamZebrado
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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:

  1. I submitted a prompt, but the app got stuck and did not start any conversation.
  2. The model selection area showed “Custom,” which was confusing.
  3. I submitted the prompt again.
  4. An empty/idle conversation was created, but it showed an error similar to “error submitting the prompt/message.”
  5. In that session, the actual model shown was “5.3 Codex Medium,” not “Custom.”
  6. I submitted again in the same conversation, but nothing happened at first.
  7. I also tried to start another conversation, but nothing happened at first.
  8. After a delay, the original session suddenly started working.
  9. My repeated prompt became a “steered” message.
  10. The later attempt to start another conversation also eventually created another running conversation.
  11. I clicked “Stop,” but nothing happened.
  12. 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

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #19249
  • #18810
  • #19831
  • #18474
  • #19690

Powered by Codex Action

kyledempster7 · 1 month ago

Fresh macOS reproduction with a stronger UI/backend state split:

  • Codex Desktop: 26.721.41059 (build 5848)
  • Codex CLI: 0.146.0-alpha.3.1
  • macOS: 26.5 (25F71)
  • affected thread: 019f9d39-2721-7372-bc26-df6020e58980

After “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:

  • rollout JSONL: 667,190,009 bytes
  • recorded tokens_used: 1,591,327,355 (clearly pathological metadata, not asserted billable usage)
  • stored title length: 3,375 characters and included delegation markup
  • a redacted codex doctor --json capture had a successful WebSocket HTTP 101 handshake, provider reachability passed, and auth configured

Expected: 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.