Windows desktop taskbar badge remains unread due to archived and closed subagent thread IDs

Open 💬 2 comments Opened Jul 24, 2026 by qjxtony

What version of the Codex App are you using?

26.721.3996.0

What platform is your computer?

Windows (x64)

What issue are you seeing?

The Windows taskbar icon continues to show an unread badge (1) even after every visible task has been opened/read.

A read-only inspection of the local persisted app state shows that the badge is backed by a non-empty entry at:

electron-persisted-atom-state.unread-thread-ids-by-host-v1.local

At the time of inspection, this array contained five thread IDs. Cross-checking those IDs against the read-only thread database showed:

one thread with threads.archived = 1
two child/subagent threads whose thread_spawn_edges.status = "closed"
two ordinary, non-archived threads, including the task that was currently open in the foreground

The two closed child threads are not reachable as normal sidebar tasks, so the user has no UI path to mark them read. The archived thread also remains in the unread set after archival. During verification, the currently open task was newly added to the unread array, increasing it from four entries to five.

The taskbar displays 1 rather than the number of stored IDs, which suggests the Windows badge is being used as a boolean (any unread) while stale/unreachable IDs keep the condition permanently true.

No local state was modified during diagnosis.

What steps can reproduce the bug?

Use Codex Desktop on Windows and create tasks that spawn subagents/child threads.
Allow the child threads to finish and reach closed status.
Open/read all tasks visible in the sidebar.
Archive a task that has previously been considered unread.
Observe that the Windows taskbar icon continues to show an unread badge of 1.
Restarting or revisiting visible tasks may not clear the badge because closed child-thread IDs and archived-thread IDs remain in unread-thread-ids-by-host-v1.local.

The problem can also occur for an ordinary task: a task that is currently open may still be present in the persisted unread array.

What is the expected behavior?

Opening a task should reliably remove its ID from the persisted unread set.
Archiving a task should remove its ID from the unread set.
Closed child/subagent threads that are not independently reachable in the UI should not contribute to the application/taskbar unread badge.
On startup or badge recomputation, the app should prune unread IDs that refer to archived threads, closed child threads, or otherwise unreachable records.
The Windows taskbar badge should clear immediately when there are no actionable unread tasks.

Additional information

This appears related in theme, but not identical, to automation-specific macOS reports such as #20418 and #26857. This report concerns Windows taskbar state, ordinary tasks, archived tasks, and closed subagent threads rather than unread automation runs.

Potential defensive fix:

Remove an ID transactionally when a thread is opened/read or archived.
Do not add independently hidden child threads to the global unread collection, or clear them when the spawn edge becomes closed.
Before setting the OS badge, reconcile the unread collection against thread metadata and filter archived = 1, closed child edges, and missing/unreachable threads.

All identifiers, task titles, user paths, and conversation contents have been omitted from this report.

View original on GitHub ↗

2 Comments

qjxtony · 1 month ago

Additional persistence evidence from a controlled local cleanup:

While Codex Desktop was still running, the persisted unread-thread-ids-by-host-v1.local array was backed up and cleared. The file remained valid JSON and immediately showed zero unread IDs.
After fully exiting and restarting Codex, the same four stale IDs were restored exactly: one archived thread, two closed child/subagent threads, and one already-read ordinary thread.
I then repeated the cleanup only after every ChatGPT.exe and codex.exe process had exited. A pre-cleanup backup again contained those same four IDs; the after-exit cleanup removed all four.
After restarting, those four stale IDs did not return and the taskbar badge cleared.

This indicates that the first cleanup did not fail because of malformed state or database corruption. Instead, the running app retained an in-memory copy of the stale unread set and wrote it back during shutdown, overwriting the externally cleaned file.

This may be useful when choosing the fix location: startup reconciliation alone would hide the symptom after restart, but stale IDs can also be re-persisted by the shutdown/state-flush path. Ideally the unread set should be reconciled both when thread lifecycle events occur (read/archive/child-close) and before persisted state is flushed or the OS badge is computed.

All paths, thread IDs, titles, and conversation contents remain omitted.

ZyKe01 · 10 days ago

Same issue here on Windows. A completed task was deleted before it was opened, and since then the Codex desktop taskbar icon has permanently shown an unread badge of 1, even though there are no visible unread tasks remaining. This appears to match the stale unread-state behavior described in this issue.