Sidebar only shows the 50 most recent threads, making older threads inaccessible

Resolved 💬 5 comments Opened Mar 18, 2026 by rlogank Closed Apr 2, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.313.41514

What subscription do you have?

Plus

What platform is your computer?

Darwin 24.6.0 arm64 arm

What issue are you seeing?

Observed behavior:

  • only a limited recent subset of threads appears in the sidebar
  • several workspace groups show No threads even though those threads still exist locally
  • if I archive some currently visible threads, older hidden threads immediately become visible
  • hidden threads become visible again when their recency moves high enough to enter the startup-loaded recent set

This is not data loss. The threads still exist locally. The problem is that the desktop sidebar is rendering from a globally preloaded recent window instead of each workspace's actual local thread history.

No error dialog was shown. The problem appears to be incorrect loading and pagination behavior in the desktop sidebar.

What steps can reproduce the bug?

  1. Have over 50 non-archived threads across several saved workspaces.
  2. Open the Codex Desktop App.
  3. Look at the workspace groups in the sidebar.
  4. Observe that some workspaces show No threads even though they previously had conversations and those conversations still exist locally.
  5. Archive several of the currently visible recent threads.
  6. Observe that older threads from previously empty or missing workspaces now appear.

Additional repro notes:

  • pinning or changing recency can make a hidden thread appear again
  • the issue seems tied to global recent ordering, not actual thread existence
  • session id / token limit / context window usage: not applicable

What is the expected behavior?

Expanding a workspace in the Desktop App should show that workspace's full local thread history, or it should continue paging until it has loaded all matching threads for that workspace.

A workspace should not show No threads simply because its threads fall outside the app's initial recent preload window.

Additional information

This looks like a desktop renderer/sidebar loading bug rather than a persistence problem.

The local conversations still exist, and the behavior strongly suggests the app is only loading a recent subset on startup and then grouping that subset by workspace. Archiving visible threads makes older ones move up into that loaded window, which makes them suddenly reappear.

Keywords: codex threads deleted, codex threads gone, missing threads, threads missing, conversations gone

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 5 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #14751
  • #15052
  • #14370
  • #13713

Powered by Codex Action

adeolaemmanuelmorren · 5 months ago

same problem

iqdoctor · 5 months ago

I hit the same class of bug and traced a concrete cap in the recent-thread loading path.

Relevant code paths from the current extension sources / sourcemaps:

  • src/app-server/app-server-manager-constants.ts
  • RECENT_CONVERSATIONS_PAGE_SIZE = 50
  • src/app-server/app-server-manager.ts
  • refreshRecentConversations() uses limit = RECENT_CONVERSATIONS_PAGE_SIZE * recentConversationsPageCount
  • loadMoreRecentConversations() uses limit: RECENT_CONVERSATIONS_PAGE_SIZE

In practice on my machine:

  • initial UI showed 50 local sessions
  • after patching the page size to 500, the UI showed 100
  • only after forcing auto-pagination across nextCursor did the UI show 313

That suggests the visible “50 most recent” symptom is real, but the underlying problem is broader:

  • the sidebar / task history is rendering only a loaded recent subset
  • there also seems to be another server-side or RPC page boundary if the client does not continue paging

So I think this issue is really “recent subset only, not full local history” rather than just a simple 50-item UI cap.

lechuhuuha · 5 months ago

Yes, this appears to be the same bug as in #6410.

Previously, the limit was only 20. Now it seems to have increased to 50, but that is still not enough for daily use.

Please consider increasing this limit to atleast 200, removing it, or providing a configuration variable so users can control it manually.

Thanks.

iqdoctor · 5 months ago

You can ask Codex to patch the Codex plugin as described in #15368. It worked surprisingly well for me. Just give Codex the link.