Desktop sidebar shows "No chats" for all projects — thread/list with useStateDbOnly:true returns 0 threads when limit >= 50

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

• #27577
• #27408
• #27453
• #27664
• #26236

Powered by Codex Action

Confirmed the same behavior on macOS with Desktop App 26.609.30741 / bundled codex-cli 0.140.0-alpha.2.

In my case the sidebar was completely empty (not just project sections), and rebuilding ~/.codex/session_index.jsonl from state_5.sqlite did not help.

A workaround that restored the sidebar for me was clearing the Desktop App's renderer cache and restarting:

rm -rf ~/Library/Caches/Codex \
       ~/Library/Caches/com.openai.codex \
       ~/Library/Application\ Support/Codex/Default/Cache \
       ~/Library/Application\ Support/Codex/Default/Code\ Cache \
       ~/Library/Application\ Support/Codex/Default/GPUCache \
       ~/Library/Application\ Support/Codex/Default/Session\ Storage

However, as noted above this does not work for everyone, so it is likely just perturbing the renderer into using a different request path rather than fixing the underlying thread/list regression.

I also see this error in logs on every launch, which may be related to the same alpha auth/provider change:

failed to refresh available models: unexpected status 403 Forbidden: ... Missing scopes: api.model.read ... url: https://api.openai.com/v1/models?client_version=0.140.0

Thanks for confirming on macOS — that rules out anything Windows-specific.

Your cache-clearing workaround is consistent with the root cause described above, and likely explains why it doesn't work for everyone: clearing the renderer caches also wipes the locally cached feature-gate evaluations, so on next launch the expanded-thread-history gate evaluates to its default (off) and the sidebar falls back to the legacy useStateDbOnly: false path — which works. Once the gate cache re-syncs from the server, the gate turns back on and the regression returns. So it perturbs exactly the request path you suspected, rather than fixing thread/list.

Regarding the 403 on /v1/models (api.model.read missing scope): probably unrelated. The failing thread/list { useStateDbOnly: true, limit >= 50 } call reproduces fully offline against the local SQLite state DB, with no network involved, so the listing regression can't be an auth/scope issue.

Follow-up: tested the cache-clearing workaround on Windows (app 26.609.3341.0, same runtime) — it does not restore the sidebar here, in either form:

1. Faithful equivalent of the macOS commands (clearing Cache, Code Cache, GPUCache, Session Storage in both the Electron profile root and web/Codex/Default) → sidebar still shows "No chats" for every project after restart.
2. Extended version also clearing Local Storage (which holds the locally cached feature-gate/Statsig state) → same result.

So the gate appears to be re-evaluated from the server during startup, before the sidebar first renders — which would explain why the cache workaround is unreliable across machines: it only helps if the renderer happens to fall back to the legacy listing path before the gate state is re-fetched. In other words, there is no reliable local workaround; the fix needs to land in the thread/list useStateDbOnly implementation (or the expanded-history gate rolled back until it does).

I've been experiencing this issue for several days now. The manipulations only helped launch a common flat chat list, but linking threads to a project still hasn't appeared.

I reproduced this on Windows and completed a successful full recovery. The result suggests that, at least in my case, the current application build was functional, but the existing per-user Codex state had become inconsistent.

Initial symptoms

• Projects were visible, but showed No chats.
• Existing and newly created project chats were only accessible through Search.
• A newly created chat could immediately report that its working directory no longer existed.
• Reinstalling the Microsoft Store application did not help.
• Adding all active thread IDs to projectless-thread-ids restored chat visibility, but only as one flat Chats list without project grouping.

Clean-profile test

I created a completely separate Windows user account and installed Codex there.

Under that clean Windows profile:

1. I added a project folder.
2. Created a chat inside the project.
3. Received a response.
4. Closed and reopened Codex.
5. The project, chat, working directory, and project grouping all remained correct.

This showed that the installed application build itself could work correctly and that the problem was specific to the original user's local Codex state.

State verification

Before modifying anything, I backed up the complete %USERPROFILE%\.codex directory and created a consistent SQLite backup.

Results from the affected profile:

• SQLite PRAGMA integrity_check: ok
• 61 total threads
• 57 active threads
• 4 archived threads
• 80 session JSONL files
• No missing rollout files

Several thread working directories used inconsistent path representations, including forms equivalent to:

• D:\project
• /mnt/d/project
• C:\mnt\d\project
• extended Windows path forms

Recovery procedure

With Codex fully closed:

1. Renamed the affected .codex directory and allowed Codex to create a fresh profile.
2. Verified that new projects and chats persisted correctly.
3. Migrated the old conversations into the fresh profile in controlled batches.
4. For every migrated thread:

• copied its rollout JSONL file;
• inserted the corresponding row into the fresh state_5.sqlite;
• updated rollout_path;
• normalized cwd to the real existing Windows path;
• copied the matching session_index.jsonl record when one existed.

1. Registered existing project directories in:

• electron-saved-workspace-roots
• project-order

1. Kept only genuinely generated/projectless conversations in projectless-thread-ids.
2. Preserved archived status.
3. Ran PRAGMA integrity_check after each migration batch.

Final result

• 61 old threads restored
• 1 clean-profile test thread retained
• 62 threads total
• 58 active
• 4 archived
• 15 saved workspace roots
• SQLite integrity: ok
• Project chats are grouped under their projects again
• Old conversations open with full history
• Working directories are valid
• Projects and chats survive application restart

The final restored profile still contains more than 50 active threads and currently works correctly. This may mean that the exact thread/list limit >= 50 regression is no longer active in the current build/environment, while the old local profile remained in an inconsistent state across application updates.

Suggested product improvement

Codex Desktop needs a supported Repair / Reindex local history operation that can:

• validate state_5.sqlite;
• rediscover rollout JSONL files;
• rebuild missing thread rows and session index entries;
• normalize equivalent Windows/WSL path representations;
• rebuild saved workspace roots and project grouping;
• distinguish real project threads from generated projectless chats;
• create an automatic backup before repair.

Users should not need to edit SQLite and .codex-global-state.json manually to recover conversations that are still present on disk.

Related: #19873, #27906, #27843. A redacted recovery manifest and recovery script are available for maintainers if needed.