Windows: reopened chats cannot send follow-up prompts after app/system restart (26.915.4065.0)

Summary

On Codex Desktop for Windows, existing chats become unable to submit typed prompts after closing/reopening the app or shutting down/restarting the computer. The Send arrow appears dimmed/disabled. The user reports that a new chat may accept its first message, but subsequent prompts cannot be sent.

The user previously believed an update had resolved the problem, but reports that it has recurred. The exact earlier working version is unknown.

Environment

• Installed Windows package: OpenAI.Codex
• Verified package version: 26.915.4065.0
• Windows desktop; PowerShell local environment
• Report date: 2026-09-20

Reproduction (user reported)

1. Use a chat in Codex Desktop.
2. Close the app, or shut down and restart the computer.
3. Launch Codex and reopen an existing chat.
4. Type a follow-up prompt.
5. Observe that the Send arrow remains dimmed/disabled and the prompt cannot be submitted.
6. A newly created chat may accept an initial prompt, but subsequent typed prompts also become blocked.

Expected behavior

Reopened chats and chats whose previous turn has completed should allow subsequent prompts to be submitted.

Actual behavior and impact

Typed follow-ups cannot be submitted, preventing continued work in existing conversations. Restarting is associated with recurrence rather than providing a durable recovery.

Limited local evidence

A read-only inspection of today's app logs found two Conversation state not found errors at 2026-09-20 14:02:40 UTC during startup. Logs later contain Received turn/started for unknown conversation and Received turn/completed for unknown conversation during the working diagnostic chat. These latter events may involve an auxiliary conversation and are NOT evidence of the cause of the disabled composer.

The diagnostic chat successfully accepted its initial turn. A specific failed click was not instrumented, and no controlled reboot reproduction was performed during this investigation. Root cause remains unconfirmed. Conversation restoration and composer readiness state are areas to investigate, not established diagnoses.

Related reports

• #46619: Windows Send button disabled after a completed turn
• #46763: existing Windows Local Work chats cannot send; reports the same package version, 26.915.4065.0
• #45307: Windows first turn works, follow-up Send disabled
• #45305: recurrent disabled composer with alternate submission paths working
• #46775: similar symptom in WSL mode; that environment and proposed cause have not been verified for this report

Please correlate this recurrence with these reports and advise whether a fix exists for 26.915.4065.0, or what targeted composer/restoration diagnostics would help. A supported recovery that preserves conversation history would be helpful.

Privacy

No raw logs, conversation content, thread identifiers, credentials, or user-specific filesystem paths are attached.

Start by comparing this report with #46619, #46763, #45307, and #45305, then inspect the startup logs for the reported conversation-state errors. Reproduce the restart and reopened-chat workflow if possible; done means follow-up prompts can be submitted after restart without losing conversation history.