Skip to content

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

Open

Description

@SamZebrado

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

Image

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.

Activity

  1. added
    appIssues related to the Codex desktop app
    on Apr 28, 2026
  2. added
    bugSomething isn't working
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on Apr 28, 2026
  3. kyledempster7 commented on Jul 26, 2026

    @kyledempster7

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archiving

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions