[Windows Desktop] Second message stalls after first turn completes #44295

Codex version

• Codex Desktop: 26.903.8094.0 (Microsoft Store/AppX, x64)
• Bundled Codex CLI/app-server: codex-cli 0.153.4
• VS Code extension used for comparison: 26.903.61454
• Windows 11 x64, native Windows/PowerShell (WSL is not installed)

What issue are you seeing?

In Codex Desktop on Windows, a new local conversation usually answers the first message, but the second message in the same conversation stalls indefinitely. The send control remains a stationary circular indicator.

The first turn is recorded as completed in both the session transcript and thread_history_1.sqlite. When the second message is submitted, Desktop logs:

[IpcClient] Received broadcast but no handler is configured method=thread-queued-followups-changed

No second turn/start or turn/steer request is observed, and no second user message is added to the session transcript. queue_1.sqlite contains no queued item for the affected thread, and the persisted queued-follow-ups object is empty.

Older conversations can be worse: sending a message may stall immediately without creating any turn/start.

The same account, configuration, network, and runtime support multi-turn conversations normally through Codex CLI and the VS Code extension.

Steps to reproduce

1. Launch Codex Desktop on Windows.
2. Create a new local conversation.
3. Send a short message such as reply with 1 only.
4. Wait until the reply is visibly complete.
5. Send a second short message such as reply with 2 only.
6. Observe that the composer/send control stalls and no second turn begins.

Reproduced repeatedly across multiple new conversations.

Expected behavior

After the first turn completes, submitting the second message should create a new turn/start and return a response.

Actual behavior and correlation

Representative test (UTC):

20:16:17.776  method=turn/start ... errorCode=null
20:16:49.914  Received broadcast but no handler is configured
              method=thread-queued-followups-changed

The first turn is completed in the thread-history database. There is no second turn/start, no persisted queued item, and no backend/model error corresponding to the stalled send.

This suggests Desktop retains or derives an incorrect “turn still active” state after completion and routes the next submission into follow-up handling, where it is not dispatched.

Troubleshooting performed

The issue persists after:

• Fully quitting and reopening Desktop
• Rebooting Windows
• Windows Repair and Reset
• Checking for updates (the app reports current)
• Creating fresh conversations
• Switching away from and back to the conversation
• Changing follow-up behavior from Queue to Steer
• Moving Chromium Cache and Code Cache aside so they are rebuilt
• Running with VS Code fully closed
• Temporarily disabling the bundled Computer Use and Unified Computer Use plugins

Additional checks:

• Codex doctor previously reported database integrity, authentication, backend, CDN, WebSocket, and sandbox checks healthy, with zero failures.
• The queue database is empty for affected threads.
• CLI supports multiple turns in the same session.
• Resetting Desktop/global UI state has provided temporary relief in the past, but the problem returns after reboot.
• All temporary plugin/config changes were restored after testing.

Notes

Some logs also contain Received turn/started for unknown conversation, but those IDs differ from the user conversation and correlate with successful ephemeral thread-title generation. They do not explain the missing second user turn.

Raw logs and full transcripts are not attached because they contain local paths, session metadata, and unrelated conversation context. Sanitized excerpts or a feedback session can be provided if needed.