Repository navigation
Windows Desktop: follow-up messages hang indefinitely after first turn; clean reinstall only fixes it temporarily #46299
Description
Summary
Codex Desktop on Windows frequently becomes unable to send follow-up messages.
The first message in a new conversation usually works. After the first turn completes, the next message stays in the composer with an infinite spinner and is never sent.
A completely clean reinstall temporarily fixes the problem, but the bug comes back again later.
This is a serious regression and, frankly, embarrassing for a production desktop client. Codex becomes practically unusable for normal multi-turn work.
Environment
- Windows 10 Pro 22H2
- Codex Desktop tested:
- 26.908.9136.0
- 26.903.9818.0
- Codex CLI: 0.154.0
- ChatGPT authentication
- No proxy
Reproduction
- Start Codex Desktop.
- Create a new conversation.
- Send a message.
- Wait for Codex to finish responding.
- Send a second message in the same conversation.
Actual behavior
The second message remains in the input box.
The Send button shows an infinite spinner.
No response is produced and the message is not submitted.
Creating a new conversation may temporarily work for one message, after which the same problem occurs again.
Expected behavior
Follow-up messages should create a new turn and be sent normally.
Diagnostics
codex doctor reports:
- authentication configured successfully
- WebSocket connected successfully (
HTTP 101 Switching Protocols) - provider endpoints reachable
- Desktop app-server initialized successfully
- state databases healthy
The first request successfully reaches the app-server:
method=turn/start
errorCode=null
However, when the UI hangs on the next message, no corresponding second turn/start is sent.
The Desktop log has also shown errors such as:
Received turn/started for unknown conversation
and:
Received turn/completed for unknown conversation
There are also IPC warnings such as:
Received broadcast but no handler is configured method=thread-stream-following-changed
Troubleshooting already attempted
- Restart Codex Desktop
- Create new conversations
- Upgrade Codex CLI
- Downgrade Desktop from 26.908.9136.0 to 26.903.9818.0
- Remove malformed rollout session
- Verify session/state database integrity
- Completely uninstall Codex Desktop
- Move/remove
.codexuser state - Remove local Codex application data
- Reinstall Codex Desktop from a clean state
- Re-authenticate
A clean reinstall initially made multi-turn conversations work again.
The problem later returned.
This strongly suggests that some Desktop renderer/conversation state becomes corrupted or stuck over time rather than this being a network or authentication failure.
Impact
This makes Codex Desktop effectively unusable for sustained coding work, because normal multi-turn conversations stop functioning and require repeated resets/reinstalls.
Please prioritize this Windows Desktop regression.
Activity
github-actions commentedon Sep 17, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
luxinfan commentedon Sep 18, 2026
26.915.31029,最新版本又弄坏了,上个版本已修复,更新成 26.915.31029 就坏了
meibiae commentedon Sep 21, 2026
26.915.31945 again...
livery123 commentedon Sep 21, 2026
+1
vyga66 commentedon Sep 23, 2026
Windows 11, ChatGPT/Codex Desktop. I’m seeing the same recurring issue: the first message works, but later follow-up messages remain in the composer and never create a new turn. Switching to another chat and back shows the prompt was never submitted.
Codex CLI can resume and continue the same affected conversation normally.
I rebuilt %USERPROFILE%.codex from scratch and initially restored only durable data (config.toml, AGENTS.md, skills, rules, memories, memories_1.sqlite). The Desktop app then worked normally for hours, including newly added projects, but the issue eventually returned again without an obvious user action.
Starting a brand-new Desktop chat works as a temporary workaround. This makes the issue appear to be Desktop conversation/runtime state rather than project files or the underlying Codex session itself.