Windows Desktop 26.903.61454: follow-up messages cannot be sent after the first completed turn

What version of the Codex App are you using (From “About Codex” dialog)?

Windows Desktop 26.903.61454

What subscription do you have?

plus

What platform is your computer?

Microsoft Windows NT 10.0.22631.0 x64

What issue are you seeing?

After updating ChatGPT Desktop for Windows to version 26.903.61454 on September 9, 2026, I can no longer send follow-up messages in a conversation.

The issue affects both existing and newly created conversations:

In existing conversations, I can type into the composer, but the Send button remains disabled/gray. Clicking it changes the button to a spinner, but the message is never added to the conversation.
In a newly created conversation, the first message sends normally and receives a response, but any subsequent message in the same conversation cannot be sent.
The problem started immediately after updating to version 26.903.61454.

The web version of ChatGPT is not showing the same composer behavior, so this appears to be specific to the Windows Desktop client.

What steps can reproduce the bug?

Launch ChatGPT Desktop on Windows.
Create a new conversation.
Send the first message.
Wait until the assistant finishes responding.
Type a second message.
Click the Send button.

Alternatively:

Open an existing conversation whose previous response has already completed.
Type a new message.
Click Send.

What is the expected behavior?

Once the previous turn has completed, the composer should return to an idle/enabled state and allow another message to be submitted normally.

Additional information

Relevant Log Evidence

There appear to be two related state inconsistencies.

1. Completed turns are restored as still streaming

When existing conversations are resumed, the Desktop client logs states such as:

latestTurnStatus=completed
markedStreaming=true

This happens across multiple conversations.

This suggests that the app-server considers the latest turn completed, while the Desktop renderer still restores the conversation as streaming/busy.

That would explain why the composer remains disabled after the response has already completed.

2. No second turn/start is generated

For a newly created conversation, the first turn is submitted normally:

method=thread/start
...
Conversation created conversationId=01a08531-3ff4-78f1-b9f3-a652dd06a48c
...
method=turn/start
errorCode=null

However, after reproducing the issue by attempting to send the second message, there is no second method=turn/start entry anywhere later in the log.

This suggests that the second Send action is getting stuck in the Desktop UI / renderer state before the request reaches the local app-server.

3. Unknown conversation lifecycle events

The same session also contains:

Received turn/started for unknown conversation
conversationId=01a08531-419b-7e92-9ba0-e40c7138e4cf

and later:

Received turn/completed for unknown conversation
conversationId=01a08531-419b-7e92-9ba0-e40c7138e4cf

The visible conversation created at the same time was:

01a08531-3ff4-78f1-b9f3-a652dd06a48c

I am not certain whether the 419b... conversation is an auxiliary/ephemeral thread, but it may be relevant to the renderer/conversation routing issue.

Additional Notes
The local app-server initializes successfully.
Authentication succeeds.
The first turn/start succeeds.
This does not appear to be a general connectivity failure.
The failure is highly deterministic: first message works, follow-up messages do not.
The regression started immediately after updating to 26.903.61454.

I can provide the full Desktop logs from the reproduction session if needed.

Reproduce the failure in the Windows Desktop UI and inspect the renderer/app-server logs around thread/start, turn/start, turn/started, and turn/completed. Trace why a completed turn leaves the composer disabled and why the second send does not generate turn/start; done means follow-up messages send normally after the first response in existing and new conversations.