Codex Desktop project sidebar shows No chats while local sessions still exist

I ran into the same class of issue after a Codex Desktop update: the local session data still existed, but the project sidebar/UI no longer associated the old threads with the project.

I collected the recovery workflow I used here:

https://github.com/huajiexiewenfeng/codex-session-recovery

It is an unofficial workaround, not an upstream fix. The workflow is intentionally conservative: it runs a dry-run first, checks session_index.jsonl, .codex-global-state.json, SQLite threads.cwd, project/sidebar mappings, Windows \\?\ path mismatches, creates timestamped backups before writing, and verifies the result afterward.

This may help in cases like this issue where sessions/**/*.jsonl / session_index.jsonl still exist but the Desktop sidebar shows No chats because project/thread mapping state is incomplete or stale.

I have an additional workaround/diagnostic observation that may help narrow this down.

Environment

• App: Codex Desktop
• Platform: macOS arm64
• macOS: 15.7.3, build 24G419
• Codex Desktop app version: 26.527.31326
• Codex Desktop bundle version: 3390
• Current codex CLI on PATH: codex-cli 0.128.0
• CODEX_HOME: default ~/.codex
• Relevant local files:
• ~/.codex/state_5.sqlite
• ~/.codex/session_index.jsonl
• ~/.codex/.codex-global-state.json
• ~/.codex/sessions/**/rollout-*.jsonl

The affected thread metadata in state_5.sqlite had source='vscode', model_provider='openai', and for the test thread cli_version='0.131.0-alpha.9'.

Observed behavior

I saw the same class of issue on macOS Codex Desktop:

• A project showed no visible threads in the Desktop sidebar.
• The underlying threads still existed in ~/.codex/state_5.sqlite.
• The rollout JSONL files still existed under ~/.codex/sessions/....
• Some of the same threads were still visible from the mobile/remote view.
• The Desktop sidebar/project list appeared stale or incomplete rather than the data being lost.

For one affected project, local DB inspection showed:

• threads.cwd = '/Users/<user>/repository/reweighting'
• 13 total threads
• 13 active threads
• 0 archived threads

But Codex Desktop showed no visible threads for that project.

Workaround / diagnostic

A workaround that restored the missing project threads was:

1. Give Codex Desktop a project path whose sidebar shows No chats.
2. Read local state_5.sqlite and find active thread IDs with threads.cwd = <that project path>.
3. Pick one real user thread from that project, not an internal/review-looking thread.
4. Create a heartbeat automation targeting that thread ID with targetThreadId.
5. Let the heartbeat post once to that target thread.
6. The project’s hidden threads reappear in the Desktop sidebar.
7. Pause/delete the heartbeat.

I reproduced this twice:

• once for the current hidden thread itself
• once for another project where no threads were visible in the Desktop sidebar

In the second case, the hidden project had 13 active threads in state_5.sqlite; after sending a one-shot heartbeat to one existing hidden thread in that project, the project threads reappeared in the Desktop sidebar.

Interpretation

This suggests the issue does not appear to be data loss. Causing new activity on an existing hidden thread seems to refresh or re-register the Desktop sidebar/project mapping for that thread/project.

This is not a clean fix because it writes a small message into the target thread, but it is useful as a diagnostic. It suggests the missing state may be recoverable by rehydrating or refreshing per-thread activity/mapping state from the server/local DB, rather than only rebuilding session_index.jsonl.

Temporary workaround

• Find a hidden thread ID from ~/.codex/state_5.sqlite.
• Create a heartbeat automation targeting that thread.
• Let it run once.
• Pause/delete the heartbeat.
• Check whether the project reappears in the Desktop sidebar.

Caution: this modifies the target conversation by adding a heartbeat message.

I am seeing a very similar Windows Codex Desktop project-sidebar failure, but with an additional deterministic path-rewrite signal that may help narrow the root cause.

Environment

• OS: Windows 11
• Codex Desktop process path observed: C:\Program Files\WindowsApps\OpenAI.Codex_26.602.4764...
• Local Codex storage inspected: %USERPROFILE%\.codex\state_5.sqlite, %USERPROFILE%\.codex\session_index.jsonl, %USERPROFILE%\.codex\.codex-global-state.json
• Affected workspaces are on D:\... paths.

User-visible behavior

Saved projects remain visible in the Desktop sidebar, but some project pages show no chats / incomplete history even though the corresponding local threads still exist on disk and in SQLite.

This is not data loss. The thread rows and rollout .jsonl files are still present.

Local diagnostics

Current sanitized counts from local read-only audit:

• threads rows in SQLite: 339
• IDs present in session_index.jsonl: 171
• Rows missing from session_index.jsonl: 168
• Active non-archived, non-subagent user-like threads: 89
• Threads with Windows extended-path cwd (\\?\...): 167
• Active user-like threads with extended-path cwd: 86

The important part: the apparent problem is not simply that user chats are missing from session_index.jsonl. Most active user-like chats are present in the index. The failure appears to be in project/root matching.

Path matching evidence

Saved project roots in .codex-global-state.json are stored in normal DOS path form, for example:

"project-order": ["D:\\...\\Workspace\\ProjectA", ...]
"electron-saved-workspace-roots": ["D:\\...\\Workspace\\ProjectA", ...]

But after Codex Desktop starts, many threads.cwd values in state_5.sqlite are rewritten to Windows extended-length form:

D:\...\Workspace\ProjectA
-> \\?\D:\...\Workspace\ProjectA

For active user-like threads in my local state:

• exact threads.cwd == saved project root: 0
• match only after removing the \\?\ prefix: 85
• no saved-root match even after normalization: 4

So, if Desktop groups project conversations using string equality between threads.cwd and saved roots, almost all project associations fail even though the paths are equivalent to Windows.

Reproduction / experiment

A local repair script was used only after backing up state and with Codex Desktop closed. It normalized threads.cwd from \\?\D:\... to D:\....

Observed sequence:

Before repair:  extended cwd rows = 167
After repair:   extended cwd rows = 0
After starting Codex Desktop again: extended cwd rows = 167

This happened repeatedly. The repair changes were applied to disk, but Codex Desktop rewrote the cwd values back to \\?\... during/soon after startup.

I also tested adding \\?\... versions of the roots to .codex-global-state.json (project-order / electron-saved-workspace-roots), but that made projects disappear from the sidebar entirely, so it does not appear to be a safe workaround.

Expected behavior

Codex Desktop should treat these Windows paths as equivalent when grouping threads under projects:

D:\path\to\project
\\?\D:\path\to\project

Either:

1. avoid persisting threads.cwd in \\?\... form when project roots are stored in normal form, or
2. normalize/canonicalize both sides before project/thread matching, or
3. persist all relevant project-root and thread-root fields in one canonical representation.

A supported local reindex/rebuild command would also help, but the durable fix seems to be path canonicalization in Desktop project grouping.

Impact

The UI looks like chat history was deleted, but local data is still recoverable from SQLite/rollout files. This is high impact for users relying on Codex Desktop as project memory because saved projects become visually empty after restart/update.

Appears to be fixed.

Version 26.608.12217 • Released 9 Jun 2026

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.

This appears to have changed with the latest release (at least on Windows).

All the chats from my old projects are back. Now, I notice that there is still a limit to how many chats remain in the sidebar for a single project. I have not counted them. But the one I am working on now, which has a lot of chats, only shows the last two weeks worth.

Thanks — that matches what I measured on macOS (latest build as well). The "only the last ~2 weeks show up" part seems to be the key mechanism rather than a glitch: the sidebar lists threads with recent activity, and everything older silently ages out, per project.

Two things from my testing that might be useful here:

On my install the old threads did not come back automatically with the update — possibly because my local display state had been through a partial migration. What reliably brings any specific thread back (persistently, until it ages out again) is giving it one trivial turn of activity: codex exec resume <thread-id> --skip-git-repo-check "reply with just OK"

The data is never gone — every "missing" thread is intact on disk and opens with codex resume <thread-id>, even when search can't find it.

So if anyone still has projects showing "No chats" after updating, it's worth checking with codex resume before assuming loss. Scripts/details: https://github.com/BulletCode-69/codex-thread-rescue

I believe I hit the same underlying issue and found an additional clue that may help narrow it down.

Symptoms

After updating Codex Desktop on Windows:

• Projects were still visible.
• Project chat lists became empty.
• Global search could still find old chats.
• Opening chats from search worked.
• Some chats showed:

Current working directory is missing
The working directory for this chat no longer exists

Importantly, the data was not lost.

Investigation

The SQLite database (~/.codex/state_5.sqlite) still contained all threads.

Historical threads had cwd values like:

/mnt/d/Projects/ExampleProject

However, after the update, newly created chats in the same project were being stored with:

C:\mnt\d\Projects\ExampleProject

This path does not exist on a normal Windows installation.

As a result:

1. Existing threads no longer matched the project's current workspace root.
2. New chats were also associated with a non-existent path.
3. Search still worked because it appeared to query threads independently of project/workspace matching.

Workaround

As a temporary workaround, I:

1. Created junctions such as:

C:\mnt\d -> D:\
C:\mnt\c -> C:\

1. Normalized old /mnt/<drive>/... thread paths inside state_5.sqlite to match the new format.

After doing this, nearly all project chats reappeared.

One Additional Detail

I had previously configured the agent environment to use WSL by default, and many of my historical threads were created in that environment.

Because of that, my database contained thread cwd values like:

/mnt/d/Projects/ExampleProject

I cannot say whether this issue affects users who have never enabled WSL or have a clean installation without WSL configured.

It is possible that this only occurs when migrating existing thread history between WSL-based workspace roots and the newer Desktop path handling. In my case, the issue appeared immediately after an update and only affected project chat visibility. The underlying session data remained intact.

I don't know if WSL is the root cause or merely a prerequisite for triggering the bug.

Possible Root Cause

This looks like a regression in workspace root normalization and matching between equivalent locations:

/mnt/d/Projects/ExampleProject
D:\Projects\ExampleProject
C:\mnt\d\Projects\ExampleProject

It may be helpful to canonicalize equivalent WSL and Windows paths before comparing workspace roots and to avoid persisting C:\mnt\<drive>\... paths unless those mappings actually exist on the machine.

Happy to provide additional diagnostics or database samples if needed.