Windows Desktop 26.715.4045.0: completed threads remain “thinking”; new messages queue locally and cannot start a turn

What version of the Codex App are you using?

26.715.4045.0 (Microsoft Store/AppX, x64)

The same issue was also reproduced before updating, on 26.715.2305.0.

What subscription do you have?

ChatGPT paid account (exact tier omitted).

What platform is your computer?

Windows, x64, Codex Desktop local-project threads.

What issue are you seeing?

Across multiple unrelated local projects, a thread finishes successfully on the backend but Codex Desktop continues to show “Thinking” and a spinner indefinitely.

This is not only a stale visual indicator. After the stale state appears:

• a follow-up message can remain as a local queued-message card instead of creating a new turn;
• switching to another thread and back does not recover it;
• restarting Codex does not reliably recover it;
• Windows Repair and Windows Reset were already tried;
• updating from 26.715.2305.0 to 26.715.4045.0 did not fix it;
• a thread read reports the last turn as completed with error: null, while the thread itself is idle or notLoaded;
• an attempted programmatic follow-up can fail with no active turn to steer, even though the Desktop UI still shows the thread as actively thinking.

The issue occurred repeatedly throughout the day and across unrelated projects, so it does not appear to be caused by one repository, prompt, or workspace.

Representative evidence

Examples observed through the local thread API:

1. Thread 019e9980-c152-7c82-9286-d870c61e2d87

• backend thread status: notLoaded
• latest turn: completed
• error: null
• Desktop UI still displayed “Thinking”

1. Thread 019f6a26-ed92-7c82-975c-5a4db657432e

• backend thread status: idle
• latest turn: completed
• error: null
• sidebar/UI continued to indicate activity

1. Thread 019f74e7-5b61-71b0-b2fd-21fc43e1b609

• backend thread status: idle
• latest turn: completed
• error: null
• UI activity state did not clear reliably

1. Thread 019f3672-c542-7be2-8858-b4afade51de9

• backend thread status: notLoaded
• latest turn: completed
• a new follow-up remained queued locally
• programmatic follow-up returned no active turn to steer

A control thread that was genuinely running reported active + latest turn inProgress, showing that the backend can distinguish real execution from these stale UI states.

Steps to reproduce

The trigger is frequent but not tied to one exact command:

1. Open several local project threads in Codex Desktop on Windows.
2. Run normal multi-step tasks, including tool calls and file work.
3. Wait until a thread produces its final answer.
4. Observe that the sidebar spinner and/or central “Thinking” state remains.
5. Inspect the thread through the local thread API: the latest turn is already completed with no error, and the thread is idle or notLoaded.
6. Send a follow-up message.
7. In some affected threads, the follow-up stays in a queued-message card and no new backend turn is created.
8. Restart, switch threads, or reopen the affected thread; the state may remain broken.

Expected behavior

• Once a turn reaches completed, Desktop should clear the thinking/spinner state.
• A completed thread should accept a new follow-up and create a new turn.
• On startup/recovery, Desktop should reconcile UI state against the backend thread/turn state.
• If a queued message cannot start, the UI should show an explicit error and provide a safe retry/recovery action.
• A thread must not simultaneously appear active in the UI while the backend reports idle/notLoaded and rejects follow-ups because there is no active turn.

Actual behavior

• Completed turns remain visually active.
• New input can be trapped in a local queue.
• The affected thread may become unusable until a new recovery thread is created.
• The bug repeats across projects and survives app update, Repair, Reset, switching threads, and restart.

Troubleshooting already attempted

• Waited well beyond normal completion time.
• Switched to another thread and back.
• Restarted Codex.
• Windows app Repair.
• Backed up local task records and performed Windows app Reset.
• Updated Codex Desktop to 26.715.4045.0.
• Avoided repeated Stop/Send actions.
• Verified backend status using thread list/read APIs.

None provided a durable fix.

Impact

This makes the Desktop execution state unreliable and can block continuation of completed project work. Users cannot tell whether a task is genuinely active, completed, or disconnected, and may accidentally duplicate work or create fragmented recovery threads.

Related issues

• #14127 — permanently stuck “thinking” with queued input
• #27395 — turn/start/sidecar stall and missing turn completion
• #32948 — inactive Desktop runs appearing to still be working

The distinguishing detail here is cross-project recurrence on Windows Desktop 26.715.4045.0 with direct evidence that the latest turns are already completed while the UI remains thinking, plus follow-up rejection/queueing.

Screenshots showing the stale “Thinking” state and queued message cards are available if maintainers request them.