Codex Desktop Projects sidebar shows "No chats" for projects with older non-archived conversations

[kezh9527]

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

Codex Desktop 0.135.0-alpha.1 / Windows app package OpenAI.Codex_26.527.3686.0

What subscription do you have?

Current ChatGPT/Codex account; exact subscription plan is not shown in the issue form.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The Codex Desktop Projects sidebar can show "No chats" for a project even when that project still has existing, non-archived local conversations.

I observed this after a Codex Desktop update. Several projects in the sidebar were shown as having no chats, but the conversations were still present locally and were not archived. Querying the app-server with thread/list filtered by the project cwd returned the expected conversations.

Affected example project paths:

• D:\code\gaiyea\gaiyea-admin-backend\healthy-living-backend
• D:\data\project\backend\codex-pet-bridge
• D:\data\project\backend\ncds-license-issuer-backend
• D:\data\project\backend\scoliosis-accessment-backend

Observed behavior:
The Projects sidebar appears to load a limited recent conversation set first, and then group only those recent conversations by project cwd. If a project's conversations are older and not included in that recent set, the project is displayed as "No chats", even though it has non-archived historical conversations.

This is misleading because it makes users think conversations were deleted or automatically archived.

What steps can reproduce the bug?

1. Have multiple local Codex Desktop projects with historical conversations.
2. Let some project conversations become older so they are no longer included in the sidebar's recent conversation cache.
3. Open Codex Desktop and look at the Projects sidebar.
4. Some projects show "No chats".
5. Query the app-server directly using thread/list with the same project's cwd and archived=false.
6. The conversations are returned, proving that the project does have non-archived conversations.

In my local testing, after manually moving old non-archived conversations back into the recent index, the same projects appeared correctly in the Projects sidebar again. That suggests the issue is recent-list-based grouping rather than missing or archived conversations.

What is the expected behavior?

The Projects sidebar should not rely only on a recent conversation cache to decide whether a project has chats.

Expected behavior options:

1. When expanding a project, query conversations by that project's cwd with pagination.
2. If a project would otherwise show "No chats", perform a fallback cwd query for that project.
3. At minimum, distinguish between "No recent chats" and "No chats in this project".

A project should not display "No chats" when it has non-archived conversations available through app-server thread/list by cwd.

Additional information

This was reproduced on Windows. The relevant sessions were not all archived. The issue was confirmed by comparing the Codex Desktop sidebar with app-server thread/list results filtered by cwd.

The current behavior is especially confusing after an app update because users may believe project conversations disappeared or were automatically archived.

[github-actions]

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

• Codex Desktop project threads disappear from project views/search while session JSONL remains readable #25463
• Subagent child threads are counted as top-level recent conversations and can leave stale open spawn edges #25341
• Codex Desktop conversations become empty and resume fails with stale Windows path #24178

Powered by Codex Action

[kezh9527]

#25463 looks closely related. My report may be another reproduction of the same underlying local indexing/listing consistency issue, but with one additional observation:

On Windows, the affected conversations are still non-archived and are returned by the app-server when calling thread/list with the project cwd filter. However, the Projects sidebar still renders "No chats" when those conversations are older than the sidebar's recent conversation set.

So this may specifically be caused by the Projects sidebar grouping only a limited recent conversation list instead of querying history by project cwd, or at least not doing a fallback cwd query when a project appears empty.

[mgdark-commits]

Windows data point and copied-app workaround confirmation.

I reproduced the same failure mode on Windows Desktop and tested the renderer workaround on a copied app, not on the installed WindowsApps package.

Environment tested:

• Windows Codex Desktop AppX: OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0
• CLI: codex-cli 0.136.0-alpha.2
• Earlier Windows AppX 26.527.3686.0 had the same renderer target/signature.
• Target generated renderer bundle in both builds:
  webview/assets/app-server-manager-signals-Bpaj8VHp.js

Local evidence:

• The missing project chats were still present locally.
• thread/list by exact project cwd could return the expected non-archived threads.
• The Desktop project sidebar still showed No chats because the affected threads were outside the loaded global recent window.
• No SQLite/session/rollout data edits were needed for the workaround.

Mechanism:

The renderer initial sidebar refresh still contains a global recent-window call:

let t=await this.listRecentThreads({limit:50*this.recentConversationPageCount,cursor:null});

Patching that call in a copied app to use the existing all-thread pagination helper restored the hidden project chats:

let t={data:await this.listAllThreads({modelProviders:null,archived:!1}),nextCursor:null};  

Note the trailing spaces in the replacement above are intentional in my local patch so the replacement stays byte-length preserving for the packed generated JS asset.

Windows deployment approach that worked:

1. Do not patch C:\Program Files\WindowsApps\OpenAI.Codex_* in place.
2. Copy the package app directory to a user-writable location, for example:
   %USERPROFILE%\.codex\patched-main\app.
3. Patch only the copied app\resources\app.asar.
4. Update the ASAR file-entry integrity hash for the modified generated JS asset.
5. Launch the copied Codex.exe with:
   • CODEX_HOME=%USERPROFILE%\.codex
   • CODEX_ELECTRON_USER_DATA_PATH=%USERPROFILE%\.codex\patched-main\electron-user-data
6. Do not run official Codex and the copied patched app at the same time against the same live CODEX_HOME.

Observed result:

• The lab copy using a copied CODEX_HOME showed the previously hidden project chats.
• A patched-main copy using the live CODEX_HOME also launches from the copied app path.
• Running process paths are under %USERPROFILE%\.codex\patched-main\app, not WindowsApps.
• Patch verification on the copied app.asar:
  • patched marker present: true
  • original marker present: false

This is not a proper upstream fix. It is only a diagnostic/workaround patch and can increase startup/sidebar load for users with many local threads.

The product fix should probably keep the normal global recent list for the generic Chats section, but fetch project history separately when a project is expanded, using project-scoped pagination such as thread/list({ cwd, archived: false, cursor, limit }). No chats should only be rendered after a project-scoped query completes empty.

[kezh9527]

Thanks for confirming the Windows reproduction and the renderer-side cause. I will leave this issue open for upstream tracking, since the workaround is useful for diagnosis but not a proper product fix. The expected fix should still be project-scoped pagination/fallback querying before rendering "No chats".

[hilburger]

I can confirm this on Codex App Version 26.527.60818 (3437) on MacOS Sequoia 15.7.7 (24G720).
Via search function I can find chats/threads from those projects but clicking on them opens nothing (just seeing the background with the logo instead of the chat which should actually be visible).

[hilburger]

Update with more feedback depth (working locally):

I can reproduce a very similar issue on macOS, with additional evidence that this is not data loss but a Codex Desktop UI hydration/routing bug.

Environment:

• macOS, Codex Desktop
• bundled app-server reports 0.136.0-alpha.2
• multiple local projects are affected

Observed UI behavior:

• The Projects sidebar shows affected local projects but displays No chats / Keine Chats.
• The global search modal initially shows only a small set of recent chats.
• Searching for a term associated with an affected project does return old matching threads from that project.
• Clicking one of those search results closes the search dialog, but the main chat area stays blank and only shows the Codex logo.
• The thread does not open, and there is no usable way in the UI to access that old project thread.

Local data checks:

• The old conversations are still present locally.
• state_5.sqlite contains the affected original thread rows.
• The affected threads are non-archived and have valid cwd values pointing to the correct local project directories.
• The corresponding rollout JSONL files still exist under ~/.codex/sessions/.
• session_index.jsonl also contains the affected thread IDs.
• Direct app-server thread/read on one affected original thread works and returns the full conversation history.

Concrete experiment:

• An affected original project thread is found by Codex Desktop search.
• Clicking the search result navigates to the thread route but leaves the UI blank.
• Direct app-server thread/read for the same thread ID succeeds and returns the conversation turns.
• Changing only updated_at / updated_at_ms in state_5.sqlite did not fix the UI; app-server later reconstructed the original timestamps from rollout/session metadata.
• Forking the same original thread through app-server did work: the forked thread appeared under the correct project in the Desktop sidebar and opened correctly.

This strongly suggests:

• the old thread contents are intact
• app-server can read them
• newly created/forked threads hydrate correctly
• Codex Desktop fails to hydrate older existing project/search-result threads, especially when they are outside the initially loaded recent set or were created with older Codex versions

Expected behavior:

• Expanding a project should query or hydrate threads by that project cwd, not rely only on an initially loaded recent cache.
• Clicking a search result should always open the selected thread by ID via thread/read / thread/resume, even if that thread is not currently present in the sidebar's recent-thread cache.
• If a project has non-archived local conversations, the sidebar should not display No chats.

Impact:

This made it look as if many local project chats had disappeared. Recovering and proving that the data was still present required substantial local debugging across Codex local state, session index files, rollout JSONL files, app-server calls, and Desktop logs.

I would also like to raise a billing/support concern:
debugging this product regression consumed a significant amount of paid Codex/API usage and subscription quota. Since the usage was spent investigating a Codex Desktop bug rather than normal productive work, I would appreciate guidance on reimbursement or account credit for the wasted usage.