[Windows Desktop] All existing chats disabled; new chats allow one turn only; sign-out/sign-in restores sending #47489

Summary

On Codex Desktop for Windows, the composer became globally stuck after a completed turn:

• All existing conversations had a gray/disabled Send button.
• In a brand-new conversation, the first message could be sent normally.
• After the first response completed, the second message could no longer be sent; the Send button became gray and clicking it only resulted in an indefinite spinner / no submission.
• Switching conversations did not recover it.
• Opening Settings and returning to the conversation did not recover it.
• Signing out of Codex, fully restarting the app, and signing back in immediately restored normal multi-turn sending.

This looks related to the Windows follow-up/composer regressions reported in #45626, #44342, #44102, and #45069, but the important difference in this reproduction is that re-authentication fixed the problem, which may point to stale account/auth/session state contributing to the composer being stuck.

Environment

• Codex Desktop on Windows
• Agent permission mode: Full access
• Project/workspace open in Codex
• Subscription: Plus
• Exact Codex build was not captured before recovery

Steps to reproduce

1. Open an existing Codex Desktop conversation on Windows.
2. Type a follow-up message.
3. Observe that the Send button is gray/disabled. Clicking it does not actually submit the message and may leave the UI spinning indefinitely.
4. Open other existing conversations: the same disabled Send state is present.
5. Create a brand-new conversation.
6. Send the first message: it succeeds and receives a response.
7. After the response completes, type a second message.
8. The Send button becomes gray/disabled again and the message cannot be submitted.
9. Switching to another conversation and back does not help.
10. Opening Settings and returning does not help.
11. Sign out of Codex.
12. Fully close/restart Codex.
13. Sign back in.
14. Multi-turn sending works again, including follow-up messages.

Actual behavior

The Desktop UI behaves as if conversations are still busy or otherwise not eligible to submit another turn, even though the previous response has completed. This affects all existing conversations, and newly created conversations become affected immediately after their first completed turn.

Expected behavior

After a turn completes, the composer should return to an enabled state and allow the next message to be submitted normally.

If authentication/account state is invalid or stale, the app should surface an actionable authentication error instead of silently disabling the composer.

Recovery / workaround that worked

The following recovered the app:

1. Sign out of Codex.
2. Fully quit the Desktop app.
3. Restart the app.
4. Sign back in.

After re-login, existing and new conversations could send follow-up messages again.

Additional notes

The recovery through re-login may be useful for distinguishing this case from reports where renderer reload, thread switching, app restart, or local-config refetch were sufficient.

Potentially related:

• [Windows Desktop 26.908.70816] Follow-up messages disabled after first completed turn; existing threads cannot send (CLI unaffected) #45626 — follow-up messages disabled after first completed turn
• Windows desktop: existing-chat sends indefinitely blocked by loading-local-config / pending codex-home; main-window reload recovers, normal restart can recur #44342 — existing-chat sends blocked by local configuration state
• Windows Desktop 26.903.61454: follow-up messages cannot be sent after the first completed turn #44102 — completed turns restored as still streaming
• Codex desktop (Windows): follow-up messages in existing threads never send #45069 — follow-up messages never send on Windows

I can provide screenshots from the affected state if useful.