threads / projects in sidebar missing

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

• #18364
• #17540
• #17970
• #17317
• #16811

Powered by Codex Action

After renaming threads in my patched app, they also show up in the original app.
https://github.com/openai/codex/issues/17540 might be related or a duplicate, but it does not mention the actual problem (though the issues reported by the users seem similar)
https://github.com/openai/codex/issues/18364 also mentions not seeing conversations but I'm not sure if this is just there threads/list call or another bug

TLDR what codex did to fix it:

Patched the desktop app’s bundled codex app-server launcher to intercept the initial sidebar thread/list(limit: 50, cursor: null, archived: false) request, fan it out into thread/list(cwd=..., limit=20) calls for each saved workspace root, merge and dedupe the results, and return that combined project-balanced feed back to the existing UI.

The attached markdown is a more detailed description including the patch itself.
codex-app-server-intercept-patch.md

This now also removed the projects. After restarting the app multiple projects are gone. Using the cli in the correct folders, I still can find the conversations using codex resume

I can confirm this is reproducible when the affected project's threads are present in the local thread store but are outside the first global recent page.

Additional diagnostics from a Windows Desktop case:

• thread/list via the app-server can return the missing project threads when queried directly with the matching cwd.
• The CLI resume picker can also see/resume the same threads.
• The Desktop project sidebar can still render the project as having no chats when none of that project's threads are in the initial global recent page.
• In the installed Desktop webview bundle, the recent conversation store fetches the first page with listRecentThreads({ limit: 50 * pageCount, cursor: null }), then subsequent pages with limit: 50. The request is a global thread/list request with modelProviders: null, archived: false, and no project cwd filter.

This points to a Desktop sidebar hydration issue rather than data loss or an app-server inability to list the threads.

A robust fix would be project-scoped pagination in the Desktop frontend:

1. When rendering or expanding a project, call thread/list with that project's cwd filter instead of relying only on the first global recent page.
2. Keep cursor pagination per project, or continue fetching until either at least one matching project thread is found or nextCursor is exhausted.
3. Avoid workarounds that mutate updated_at / ordering; that only forces old threads into the first global page and changes user history semantics.
4. Increasing the global page size would only delay the bug. A workspace with enough newer unrelated threads can still hide older project threads.

I checked the public openai/codex repository at current main and could not find the Desktop webview source that contains this recent-conversation store, so I cannot submit a useful external code PR for the actual frontend fix. The public repo appears to expose the app-server protocol/backend surfaces, while the affected Desktop UI source is not present there.

I can also reproduce this on macOS with Codex Desktop.

Environment:

• Codex Desktop: 26.506.31421 (bundle version 2620)
• macOS: 26.4.1 (25E253)

Observed behavior:

• Project conversations existed in the local thread store and were not archived, but the Desktop sidebar did not show the affected projects/conversations.
• The affected projects were two local workspace repos, anonymized here as <project-a> and <project-b>.
• The issue persisted after fixing stale cwd values from earlier repo moves, so the remaining problem was not data loss and not only an invalid-cwd issue.

Local diagnostics before applying a local workaround:

• The app log contained an app_state_snapshot with thread_count_loaded_recent=50.
• Sorting active threads by updated_at desc, the first affected <project-a> conversation was rank 56.
• The first affected <project-b> conversation was rank 77.
• Those threads were present in ~/.codex/state_5.sqlite with archived=0 and source='vscode'.
• Recent unrelated CLI/status-like threads with cwd=/ occupied much of the first global recent page.

After archiving obvious local CLI /status noise and bumping the affected project threads into the top 50, the conversations appeared again. That workaround confirms the sidebar visibility is coupled to the first global recent page, rather than project-scoped history availability.

This looks like the same Desktop sidebar hydration bug described above: project history is derived from a global recent page instead of fetching/paginating per project cwd. A fix should not require mutating updated_at or otherwise changing local history ordering.

Same here, and the thread also cannot be listed in the new mobile app.

I can confirm this issue with an additional redacted Windows reproduction and app-server evidence.

Environment observed:

• Codex Desktop app-server user agent includes Codex Desktop/0.131.0-alpha.9
• Windows x86_64
• Local Codex state only; no cloud data loss assumption
• Project names, local username, absolute paths, session ids, and rollout paths are intentionally omitted here

Summary:

• Multiple older project entries in the sidebar show No chats.
• The underlying local session data still exists.
• A project-scoped thread/list query using the project cwd returns the expected sessions.
• The sidebar appears to build project group threadKeys from a global recent thread window instead of loading sessions per project.

Redacted app-server A/B using the same app-server and a full local state copy:

| Redacted project | Global default Top 50 | Global state-backed Top 50 | Project cwd default query |
|---|---:|---:|---:|
| Project A | 0 | 8 | 12 |
| Project B | 0 | 0 | 1 |
| Project C | 0 | 1 | 11 |
| Project D | 0 | 1 | 3 |
| Project E | 0 | 0 | 1 |
| Recently active project | 8 | 8 | 8 |
| Pinned/current-heavy project | 38 | 26 | 50 |

Additional checks:

• Raw session/rollout files exist locally.
• Local SQLite thread rows exist.
• sourceKinds: [] and omitted sourceKinds produced equivalent results in the tested calls.
• The final renderer is not the apparent root cause: the project group renderer receives an empty threadKeys list and then correctly renders No chats.

The important distinction is that increasing or changing the global recent query may only partially fix this. For older projects outside any global recent window, the robust fix seems to be project-scoped loading: when a project group is expanded, or when a visible project group has empty threadKeys, call thread/list with that project's cwd / project root and support pagination for that project.

Expected behavior: a visible project entry should not appear empty only because other projects have produced 50+ newer conversations.