[Windows Desktop 26.908.70816] Follow-up messages disabled after first completed turn; existing threads cannot send (CLI unaffected)

Summary

On Windows, Codex Desktop 26.908.70816 consistently stops allowing follow-up messages after a turn has completed.

The issue affects both existing and newly created conversations:

• Existing conversations can be opened and typed into, but the Send button remains disabled/gray.
• In a new conversation, the first message can be sent normally and receives a complete response, but the second and later messages cannot be sent.
• The same affected conversation can be resumed and continued successfully from the standalone Codex CLI.

This looks very similar to #44102 and may also be related to #45371 and #40872, but I am still reproducing it on the newer 26.908.70816 Windows Desktop build.

Environment

• Codex Desktop: 26.908.70816

• Desktop bundled Codex CLI / app-server: codex-cli 0.154.0-alpha.6.2

• Platform: Windows x64

Steps to reproduce

1. Launch Codex Desktop on Windows.
2. Create a new conversation.
3. Send a first message.
4. Wait until the assistant response finishes completely.
5. Type a second message.
6. Attempt to send it.

Alternatively:

1. Open an existing conversation whose previous turn is already completed.
2. Type a new message.
3. The Send button remains disabled/gray.

Actual behavior

• The first message in a new conversation usually works.
• After the first completed turn, follow-up messages cannot be submitted.
• Existing conversations are also stuck with a disabled Send button.
• Windows Repair made the app launch again after one startup failure, but did not fix the disabled composer / follow-up issue.

Expected behavior

After the previous turn reaches completed, the composer should return to an enabled/idle state and allow a new turn/start.

CLI control test

The same conversation can be resumed from the standalone CLI with:

codex resume --all

When Codex Desktop is still open, the CLI reports:

This conversation is open in another app
Close it there and press R to continue here.

After fully exiting Codex Desktop and pressing R, the CLI successfully takes over the same thread and can continue the conversation normally. This suggests the stored session itself is valid and the model/backend path is working.

Relevant Desktop log evidence

For an affected conversation, Desktop logs show successful resume ownership and a completed last turn:

maybe_resume_success
assignedStreamRole=owner
latestTurnStatus=completed
markedStreaming=true
turnCount=1

The same pattern appears across multiple conversations, including conversations with multiple turns:

assignedStreamRole=owner
latestTurnStatus=completed
markedStreaming=true
turnCount=5

Earlier logs also show successful turn/start routing with no app-server error:

method=turn/start
errorCode=null
hadPending=true

There are also renderer routing errors such as:

Received turn/started for unknown conversation

and in another occurrence:

Received turn/completed for unknown conversation

I am not claiming that the markedStreaming=true or unknown conversation entries are necessarily the root cause, but they may be useful for correlating this failure with the renderer/conversation state issues described in the related reports.

Additional notes

• New conversations are not a reliable workaround because they also become unable to send after the first completed turn.
• The standalone CLI remains usable for multi-turn interaction and for resuming the same sessions.
• I did not delete .codex or session data because the same sessions are confirmed to work correctly in the CLI.

Related issues: #44102, #45371, #40872.

Start by reproducing the Windows Desktop flow and correlating logs around maybe_resume_success, turn/start, and the renderer messages for unknown conversations; compare with the working codex resume --all CLI path. Done means completed turns return the composer to an enabled state and existing conversations can submit follow-up messages without those routing errors.