Repository navigation
Project sidebar stuck showing unread tasks with no visible filter reset #32091
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.707.31428 (5059)
What subscription do you have?
Pro
What platform is your computer?
Darwin 25.5.0 arm64 arm
What issue are you seeing?
One project in the sidebar of the new ChatGPT Codex app only displays unread tasks. Tasks that I have already read—those without the blue unread indicator—are missing from that project’s list, although I can still find and open them using Search.
Other projects correctly display all unarchived tasks. I cannot find any filter control in the current UI, and I did not knowingly enable an unread-only filter.
Fully quitting and restarting the app does not resolve the issue.
What steps can reproduce the bug?
I do not know what originally caused the project to enter this state, so I cannot provide deterministic steps to reproduce it.
Once the state occurs, it can be observed as follows:
- Open the ChatGPT Codex app.
- Expand the affected project in the sidebar.
- Observe that only tasks with the blue unread indicator are displayed.
- Search for a known read, unarchived task belonging to the same project.
- Observe that the task appears in Search and can be opened, but is absent from the project’s sidebar list.
- Fully quit and reopen the app.
- Observe that the unread-only behaviour persists.
The issue affects only one project; other projects display both read and unread unarchived tasks.
What is the expected behavior?
The project should display all unarchived tasks, or provide a visible way to clear an active filter.
Additional information
No response
Activity
rudivs commentedon Jul 10, 2026
I’ve figured out what is happening. The read tasks are not actually hidden; unread tasks are now prioritised at the top of the project’s task list, ahead of recently active read tasks.
Because this project contains many unread tasks, its recent read tasks are pushed far down the list. Clicking “Show more” multiple times eventually reveals them.
This therefore appears to be an unmet user expectation or UX regression rather than a data-loss or filtering bug. It is a departure from the previous behaviour, where I expected tasks to be ordered by recency.
I would like either:
The current UI does not make this behaviour or its configuration apparent.
Using "Mark all as read" would be a useful workaround here, but there's an open bug preventing that (#30855).