Codex Desktop project sidebar hides older workspace conversations despite existing local thread data

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

• #20419
• #20608
• #20741
• #20759
• #20254

Powered by Codex Action

It seems that archive/unarchive mutates active-workspace-roots to a single root, causing other project chats to disappear from sidebar despite threads existing and searchable and existing in the db

Adding another macOS repro with local diagnostics. This looks related, but in this case the app-server can return the affected project threads while the Desktop project sidebar still renders "No chats".

Environment:

• Platform: macOS arm64
• Codex Desktop/app-server user agent: Codex Desktop/0.133.0-alpha.1 (Mac OS 26.5.0; arm64)
• Desktop process bundle observed locally: 26.519.41501
• Local storage: ~/.codex/state_5.sqlite, ~/.codex/sessions, ~/.codex/session_index.jsonl

Observed behavior:

• A project in the Desktop sidebar shows No chats / localized 暂无对话.
• The project's conversations are not deleted.
• Local SQLite rows exist, are unarchived, and have has_user_event = 1.
• Rollout JSONL files exist on disk.
• Calling thread/list against app-server with the exact project cwd returns the missing threads.
• Desktop still shows the project as empty after restart.

Local evidence, redacted path:

select cwd, archived, has_user_event, count(*)
from threads
where cwd = '<project cwd>'
group by cwd, archived, has_user_event;

cwd             archived  has_user_event  n
<project cwd>   0         1               9

Global rank evidence:

project active threads: 9
best global updated_at rank: 16
worst global updated_at rank: 198
threads in global recent 50: 1

So this is not just "all project threads are outside the global recent 50"; at least one affected project thread is inside the recent window, yet the Desktop project sidebar still renders no chats.

App-server evidence:

Using a direct thread/list request with the exact cwd, archived: false, limit: 20, and sourceKinds: [] returns project threads, e.g.:

{
  "id": "...",
  "cwd": "<project cwd>",
  "preview": "...",
  "status": { "type": "notLoaded" },
  "source": "vscode"
}

This strongly suggests the persisted thread store and app-server listing path are healthy, but the Desktop sidebar/project UI is either:

1. grouping against a different in-memory project identity than the app-server cwd,
2. filtering the returned interactive vscode threads differently than thread/list,
3. or failing to render/project-group returned threads after startup.

Expected behavior:

• If thread/list({ cwd: "<project cwd>", archived: false }) returns active threads, the Desktop project sidebar should not show No chats.
• The sidebar should query the selected project/workspace path directly, page results as needed, and render any active threads returned by app-server.
• If the UI uses a different canonical project path than the local thread cwd, it should show a diagnostic or normalize paths consistently instead of silently showing an empty project.

This is causing users to think their working history was deleted even though the local thread data is still present and readable through app-server.

Follow-up: this is not an isolated one-off event for this user. The same "project shows No chats / 暂无对话 while local threads still exist" failure has recurred multiple times across different projects.

Additional local evidence from the same macOS machine:

archived  has_user_event  n
0         0               1
0         1               247

So almost all local thread rows are active and have user events.

Affected/at-risk projects with active local threads still present:

active_threads  latest_utc           project
89              2026-05-19 13:02    MAC media/video project
84              2026-05-24 07:10    TG bot project
12              2026-05-21 09:55    promotional/video material project
9               2026-05-23 17:18    TG backend project
8               2026-05-24 07:05    TG acceptance tester project
7               2026-05-24 07:20    switch project

The user reports this has happened repeatedly, not just once or twice. From the local diagnostics, the data remains present in:

• ~/.codex/state_5.sqlite
• ~/.codex/sessions
• ~/.codex/session_index.jsonl

The failure pattern is recurrent:

1. A project in Codex Desktop shows No chats / 暂无对话.
2. Local SQLite rows and rollout JSONL files still exist.
3. Rows are unarchived and have user events.
4. Direct app-server thread/list for the exact cwd can return the missing threads.
5. Desktop sidebar still fails to show them.

This creates repeated apparent "chat loss" for normal users, even though the underlying records remain on disk. It is severe because users naturally try manual database/file workarounds, which can make the state worse. A supported repair/reindex command or a Desktop-side "rebuild local chat index" action would be very helpful until the sidebar project-history bug is fixed.

Request:

• Please treat this as a recurring data-visibility reliability issue, not a single corrupted local profile.
• Add diagnostics to distinguish "no chats exist" from "chats exist locally but are not loaded/rendered by sidebar".
• Consider shipping a supported codex doctor --repair-thread-index or equivalent safe reindex operation.

I can reproduce what looks like the same underlying issue on macOS Codex Desktop.

This does not look like local data loss. In my local store, the missing project conversations still exist in state_5.sqlite, their rollout files are present, and app-server can return them when queried with a server-side cwd filter.

Sanitized evidence from one affected project:

• The project has 40+ valid, unarchived local threads in threads for the same project cwd.
• The Desktop project sidebar only shows about 15 of them.
• A direct app-server thread/list call with the project cwd returns the project history correctly.
• A global recent thread/list page followed by client-side project filtering reproduces the truncated visible subset.

The behavior seems consistent with pagination happening before project filtering. In other words, the UI appears to load a limited global recent-thread page, then group/filter that already-loaded subset by project, instead of fetching the selected project's own history.

Suggested fix:

• When a project/workspace is expanded, call thread/list with a server-side cwd filter, or add a server-side cwdPrefix / projectRoot filter if child working directories should be included.
• Paginate after the project filter has been applied, not before.
• Avoid relying on the first global recent-thread page as the source of truth for a project's sidebar history.

This is easy for users to interpret as deleted history, but the local thread data and app-server project query path appear to be healthy.

Adding another Windows/WSL Codex Desktop datapoint.

This does not look like data loss. In my local store, the missing project thread still existed in state_5.sqlite with archived=0, had the expected project cwd, and its rollout/session file was still present. The Desktop sidebar/project thread listing only surfaced two very recent threads for that workspace, while an older May 19 thread updated on May 22 was hidden until I found the thread id by querying the local SQLite DB directly and pinned it.

So this matches the “local thread data exists, sidebar/project discovery hides older unarchived conversations” failure mode.

Hi everyone, I'm tracking the same Codex Desktop missing-thread/sidebar-history issue on macOS.

For those affected here: did you eventually get all hidden project threads back in Desktop? If yes, what exact method worked durably for you?

Examples I'm trying to distinguish:

• official update fixed it
• restart/reindex fixed it
• codex resume --all <thread-id> rehydrated it
• repairing session_index.jsonl / state_5.sqlite / .codex-global-state.json fixed it
• Codex Wake or another local recovery helper fixed it
• app bundle / listAllThreads patch fixed it
• nothing worked yet

In my case, the missing project threads still exist in ~/.codex/sessions and state_5.sqlite, but Desktop does not hydrate them back into the project sidebar after restart. Any confirmed durable fix would help. Please do not share private session contents; sanitized method/results are enough.

Adding a macOS datapoint after updating to the latest Desktop build.

Environment:

• macOS 15.5 (24F74)
• Apple Silicon / arm64
• Codex Desktop: 26.608.12217
• CFBundleVersion: 3722
• Local storage: default ~/.codex

Recovery status on my affected project:

• The update appears to have restored some previously missing threads.
• It did not restore everything.
• Older project threads are still missing from the Desktop sidebar/project history.
• The local data still appears to exist. For the affected project, state_5.sqlite still has 251 active/non-archived rows with the expected project cwd.
• Earlier checks also confirmed matching rollout JSONL/session files under ~/.codex/sessions.

So my current result is: 26.608.12217 looks like a partial recovery, not a full recovery. It would still be very helpful to have an official full local reindex/recovery command that rebuilds sidebar/project history from durable local state.

Spent a few days investigating this on an affected install and wanted to share findings that might help others here. Your threads are not deleted. The conversation data stays intact in ~/.codex/state_5.sqlite (integrity check ok) and every thread still opens with codex resume <thread-id>. What changed is the sidebar/search behavior: it shows a bounded window of recently active threads, and older threads silently age out of view — which looks exactly like data loss. There is a one-command workaround. Giving a hidden thread one trivial turn of activity brings it back into the sidebar (and search), persistently across restarts: codex exec resume <thread-id> --skip-git-repo-check "reply with just OK" Notes from testing: editing local state files .codex-global-state.json, state_5.sqlite flags) does not restore listing, and any edits made while the app is running are overwritten on exit. In-session "restores" (asking the agent to fix the sidebar, fork-based restores) only appear to work and create duplicates. Documented the verified model with small recall/diagnostic scripts here: https://github.com/BulletCode-69/codex-thread-rescue (MIT). Hope it saves someone the panic I went through.