[URGENT] Codex App on Windows: broken thread view can poison later thread switching/display until a new thread is created

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

Codex Desktop observed locally: 26.513.31313

Embedded CLI version recorded in local thread metadata: 0.131.0-alpha.9

What subscription do you have?

Not included in this public report.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After updating Codex Desktop on Windows today, I am seeing a thread-view/navigation bug in the desktop app.

There are two related symptoms:

1. A thread that was previously normal can become a broken thread during regular use. Later, opening it shows the generic desktop error screen instead of the conversation.
2. Once I click into one of those broken threads, subsequent thread switching is affected. Even another thread that was healthy before may fail to display correctly after that. The UI only recovers after I create a brand-new thread and then switch back.

So this is not only "one bad thread cannot open". A broken thread can poison later thread navigation/display in the current desktop session.

The user-facing error screen is:

Oops, something went wrong
[Check for updates] [Retry]

Local diagnostics suggest this is not simple data loss:

• the affected thread's local rollout JSONL still exists
• the corresponding thread row still exists in state_5.sqlite
• this behavior started immediately after today's desktop update

What steps can reproduce the bug?

I can reproduce it with the following pattern on Windows Codex Desktop:

1. Open Codex Desktop after today's update.
2. Use a normal thread for a while.
3. At some point, that thread later becomes a broken thread and shows the generic desktop error screen when reopened.
4. Click into that broken thread from the sidebar/history.
5. Then click into another thread that was previously healthy.
6. Observe that the healthy thread may now also fail to display correctly / the desktop UI remains in a bad state.
7. Create a brand-new thread.
8. Switch back to the previously healthy thread.
9. Observe that the healthy thread can display normally again only after creating a new thread first.

Observed characteristics:

• a previously healthy thread can later become broken
• opening a broken thread can affect subsequent thread navigation/display
• creating a new thread appears to reset the broken desktop UI state
• this is reproducible in the same desktop session

Known affected local thread ids from this machine around the repro window:

• broken archived/history thread: 019e3059-c620-7c32-b26b-4b2236fa39c7
• healthy diagnostics thread that could still be reopened after reset: 019e30bc-8840-7123-94eb-68b1aded6a1e

What is the expected behavior?

• A normal thread should not later become unreadable in the desktop app.
• If one specific thread fails to open, it should not affect any other thread.
• Switching to another healthy thread should work immediately.
• Creating a brand-new thread should not be required to recover normal thread navigation/display.

Additional information

This appears to be a desktop client/session UI state bug on Windows introduced by today's update.

The most important point is the two-stage failure:

1. a previously normal thread later becomes broken
2. opening that broken thread then affects later thread display/navigation until a new thread is created

That second behavior makes this more severe than a single broken conversation.