Codex app automation notifications remain unread after being viewed
What issue are you seeing?
Automation notifications / automation-generated threads remain marked as unread even after the user has opened and read them in the Codex desktop app.
The user sees a persistent unread badge/count for automation results. In this case the app UI showed an automation notification count, and local state later showed 34 unread thread IDs. Opening/reviewing the corresponding automation results did not clear the count.
There does not appear to be an obvious UI affordance to acknowledge these notifications, such as:
- Mark as read
- Mark all as read
- Dismiss / acknowledge automation notification
- Clear automation inbox notifications
What steps can reproduce the bug?
- Create or use active Codex automations that produce visible findings/messages.
- Wait for automation runs to complete and appear as notifications / inbox items / generated threads.
- Open and read the automation result threads in the Codex desktop app.
- Return to the automation/inbox/sidebar notification surface.
- Observe that the unread badge/count remains present even though the user has already viewed the notifications.
What is the expected behavior?
After a user opens/views an automation notification or the thread generated by an automation, Codex should mark it as read and decrement/remove the unread count.
At minimum, the UI should expose an explicit action such as "Mark as read", "Mark all as read", or "Acknowledge" for automation notifications.
A user should not need to edit local app state files to clear already-viewed automation notifications.
What actually happens?
The unread count persists after the notifications have been viewed.
The only workaround I found was to manually edit the local app state and clear:
~/.codex/.codex-global-state.json
"electron-persisted-atom-state"."unread-thread-ids-by-host-v1".localIn this case, clearing that array in both .codex-global-state.json and .codex-global-state.json.bak removed the local unread count after a relaunch/refresh, but this is not an acceptable UX or durable product behavior.
Additional information
Codex App version: 26.609.30741 (3808)
Bundle identifier: com.openai.codex
Platform: macOS 26.5.1 (25F80), arm64
The automations themselves were still active and working. The issue is specifically notification/read-state handling for automation-generated results.
I also adjusted the automation prompts to return DONT_NOTIFY when there is nothing actionable, which should reduce future noise, but it does not solve the underlying product issue: viewed automation notifications should be acknowledged automatically or manually from the UI.
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I’m seeing what looks like the same class of bug on macOS Codex Desktop.
The Dock badge was stuck at
1. The stale state was in:~/.codex/.codex-global-state.jsonunder:
electron-persisted-atom-state.unread-thread-ids-by-host-v1Deleting that key while Codex was still running didn't work; the app wrote the same unread IDs back into the file. My workaround was:
~/.codex/.codex-global-state.json.electron-persisted-atom-state.unread-thread-ids-by-host-v1.So this seems to be more than stale JSON on disk. The running app can keep stale unread state in memory and re-persist it.
As a user I’d want a reliable “mark all read / clear attention” action, or for Codex to reconcile that unread atom when the relevant thread/run has been viewed or completed. Right now the Dock badge can point at attention that is hard or impossible to find in the UI.
This also affects ordinary completed conversations, not only automation-generated threads.
Environment
Observed behavior
After reopening Codex in the morning, multiple conversations that were already completed and viewed the previous day show blue unread dots in the sidebar. Opening those conversations reveals no new message or other unread content. The dots therefore appear to represent stale/false unread state rather than unseen conversation content.
Expected behavior
A completed, previously viewed conversation should not become unread merely because the app was closed and reopened. The blue dot should appear only when there is genuinely new unseen content, or there should be a setting to disable these markers.
This has been happening for a couple of weeks and is very annoying