Repository navigation
[Windows app] Previously read completed threads become unread after restart and outrank active threads #37033
Description
What version of the Codex App are you using?
26.730.7989.0
What platform is your computer?
Windows 10 Enterprise 22H2 (build 19044), x64
What issue are you seeing?
Since approximately August 2–5, 2026 (Asia/Shanghai, UTC+8), restarting the Codex desktop app causes some long-completed, previously read threads to become unread again.
This also makes the sidebar appear incorrectly ordered: with the default Priority sorting, those old completed-but-reintroduced-as-unread threads jump above threads that are currently active/running. The affected threads may be in different projects.
The main bug appears to be that read/unread state is not stable across a full app restart. The sorting symptom is amplified because Priority ranks unread threads ahead of active threads.
The current Projects sidebar layout does not expose a sort control, so the user cannot switch to Last updated through the visible UI.
No task content appears to be lost.
Steps to reproduce
- Open/read completed threads until their unread indicators are cleared.
- Keep at least one other thread active/running (ideally across multiple projects).
- Fully quit the Codex desktop app.
- Reopen the app.
- Observe that some old completed threads are marked unread again.
- Observe that Priority sorting places those threads above currently active threads.
This can affect a subset of old completed threads after each restart rather than every thread.
Expected behavior
- A completed thread that has been read should remain read after restarting the app.
- Priority sorting should not promote old completed threads above active threads because of an incorrectly restored unread state.
- If Priority ordering is intentional, the Projects sidebar should expose the supported Last updated sorting option as a user-accessible workaround.
Additional diagnostic information
Sanitized, read-only inspection of the current packaged renderer and local preferences found:
- Persisted sidebar settings were
chatSortMode: "priority"andprojectSortMode: "priority". - The Priority attention order is
waiting → unread → active → idle, which explains why a falsely restored unread state outranks an active thread. - The renderer supports an internal
updated_atsort mode. - In the current Projects navigation layout, the options menu is invoked in an organize-only mode, so sorting controls are hidden.
- Setting both sort modes to
updated_atavoids the misleading ordering, but it does not fix the unread-state reset itself.
The cause of the unread-state rehydration/reset has not been identified.
Related but not duplicate: #35228, #30855, #33077.
No raw thread IDs, thread titles, local paths, session files, or databases are attached.
Activity
claell commentedon Aug 5, 2026
I can independently reproduce this on Codex Desktop
26.730.8199.0underMicrosoft Windows NT 10.0.26200.0 x64.After fully closing and reopening the app, tasks that did not have a blue unread indicator before shutdown acquire one after startup and are shown as unread. The affected set is not stable: across repeated restarts, additional previously read tasks can acquire the unread indicator, so the apparent unread count grows even though those tasks received no new activity and were not manually marked unread.
This matches the read-state rehydration problem described here. In my observation, the most visible symptom is the accumulating blue unread indicators themselves; the state changes only after closing and reopening the app.
rileyjameson commentedon Aug 5, 2026
Reproducing consistently on macOS 26.5.2 (25F84, Darwin 25.5.0 arm64), Codex 26.730.61309 (build 6223).
Previously read tasks show no blue indicators before quitting. After fully quitting and relaunching Codex, a subset regain blue unread/activity dots despite no new task activity. Opening affected tasks clears the dots only until the next full restart. This is recurring and matches #37087, so #37033 appears to be cross-platform.
No task content appears lost.
In-app feedback was submitted immediately after reproducing this on macOS.
Feedback ID:
019fcfa1-220c-7c70-a510-e3f5fd4ca9aeclaell commentedon Aug 8, 2026
Update on Codex Desktop
26.803.5235.0: the apparent unread count increased again after the latest restart/recovery. Additional tasks acquired blue unread indicators without new task activity.This latest occurrence followed a crash-and-restore event involving Codex or Windows, so it does not isolate a clean app shutdown. However, I had already observed the same symptom across update-related restarts. I may also have observed it across an ordinary restart, but I can no longer reconstruct that sequence confidently enough to claim it as a separate confirmed case.
The recurring part I can confirm is that the set of falsely unread tasks continues to grow across restart/recovery events.
rensei11 commentedon Oct 3, 2026
Additional Windows reproduction on October 3, 2026 (JST):
The same user first experienced the opposite failure earlier the same day: unread/completion blue dots stopped appearing entirely for completed background ChatGPT conversations. Later, the blue dots began appearing again, but now some chats that had already been opened/read were marked unread with a blue dot.
So within the same day the sidebar moved from false negatives (missing unread/completion dots) to false positives (already-read chats shown as unread).
This strongly suggests unstable read/unread state synchronization or rehydration rather than a simple renderer visibility issue. The practical impact is severe because the sidebar unread dot can no longer be trusted as a completion indicator for parallel-chat workflows.