[Windows][26.820.9563.0] Resuming one specific 18.49 MB thread reproducibly leaves Desktop UI stuck

What version of the Codex App are you using?

• ChatGPT/Codex Desktop AppX: OpenAI.Codex 26.820.9563.0
• Bundled/relocated app-server CLI: codex-cli 0.150.0-alpha.8
• Microsoft Store package status: Ok

What subscription do you have?

Not disclosed. The problem occurs in local desktop thread hydration/state reconciliation.

What platform is your computer?

• Windows 11 Pro x64
• Windows version/build: 10.0.22000

What issue are you seeing?

After updating the Windows desktop app, resuming one particular existing thread reproducibly leaves the Desktop UI stuck. The same thread triggers the problem every time it is restored/resumed.

This is deterministic and thread-specific rather than an intermittent whole-app startup failure.

The affected local rollout is approximately 18.49 MB. The same redacted thread identifier appears in three separate desktop log files from repeated resume attempts.

While the UI is stuck:

• The visible ChatGPT/Codex main window exists.
• Windows reports the main process as Responding=True.
• The app-server child process remains alive.
• CODEX_CLI_PATH is unset.
• A 5-second process sample did not show a CPU busy loop:
  • busiest child: approximately 0.641 CPU seconds over 5 seconds
  • main process: approximately 0.109 CPU seconds over 5 seconds
• One renderer process had a working set of approximately 643 MB.
• No matching Windows Error Reporting AppHang, application-error, or crash report was present.

Sanitized desktop log signals associated with the failure pattern include:

error [electron-message-handler] ResizeObserver loop completed with undelivered notifications
error [electron-message-handler] Received turn/started for unknown conversation
error [electron-message-handler] Received turn/completed for unknown conversation

In one captured sequence, the unknown-conversation turn/started and turn/completed events occurred about three seconds apart, while the Desktop UI remained stuck.

This suggests that the backend/app-server can receive and complete the turn, but the renderer fails to associate the incoming events with the resumed conversation. The UI then remains in a stale loading/thinking state instead of reconciling with the authoritative thread state.

What steps can reproduce the bug?

1. Install/update ChatGPT/Codex Desktop on Windows to 26.820.9563.0.
2. Launch the app normally.
3. Open or resume the affected existing thread from the Desktop thread list or its codex://threads/<redacted> URI.
4. Observe that the Desktop UI becomes stuck.
5. Fully restart the Desktop app.
6. Resume the same thread again.
7. Observe the same stuck state again.

The exact thread ID is intentionally omitted from the public issue because it is an account/session identifier. It can be shared privately with OpenAI maintainers if a secure channel is provided.

What is the expected behavior?

• Resuming an existing thread should hydrate its history and restore its current turn state without freezing the UI.
• Incoming turn/started and turn/completed events should be associated with the resumed conversation.
• Larger thread histories should be loaded incrementally or paged.
• If a thread contains an unsupported or malformed record, Desktop should surface an actionable error and keep the rest of the application usable instead of remaining stuck.
• Restarting and resuming the same thread should not deterministically reproduce a stale renderer state.

Additional information

• A metadata-only local inspection located the affected rollout and measured it at approximately 18.49 MB. No conversation text, prompts, code, or tool-output content was inspected or attached.
• The rollout file was actively held open by the running app during one inspection attempt, so no attempt was made to copy, modify, truncate, repair, or delete it.
• Raw desktop logs are not attached because they contain account IDs, conversation IDs, local paths, URLs, and session data.
• The thread ID, account identifiers, local username, project paths, prompts, code, and tool outputs are omitted for privacy.
• Possibly related, but this report is specifically for a deterministic single-thread resume trigger on the newer 26.820.9563.0 build:
  • #35963
  • #34026
  • #24263

Start at the desktop resume and hydration flow, using the electron-message-handler signals for turn/started and turn/completed as the first entry point. Trace how events are associated with the resumed conversation and verify that the affected thread no longer leaves the UI stuck, while malformed or large thread data keeps the app usable.