Codex Desktop on Windows no longer shows older chats after update

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

• #22971
• #22981
• #22452
• #22996
• #23189

Powered by Codex Action

Clarification: the affected cwd paths include Windows extended-length path prefixes like:

\\?\D:\HealthAgents\site
\\?\D:\SIS-ZONE\CodeX\koop

while the saved project roots appear as normal paths like:

D:\HealthAgents\site
D:\SIS-ZONE\CodeX\koop

Potential duplicates detected. Please review them and close your issue if it is a duplicate. Codx Chat History Bug after updating #22971 Codex Desktop on Windows: existing history thread opens/resumes inconsistently; thread/goal/get returns "goals feature is disabled" #22981 Codex Desktop local thread can be hidden/stale when state_5.sqlite and session_index.jsonl drift on Windows #22452 Codex Desktop: completed threads become inaccessible after update #22996 * Windows Codex + WSL project: older threads lose cwd and terminal tries to cd into malformed WindowsApps/app/resources/\\wsl$ path #23189 _Powered by Codex Action_

I reviewed the suggested possible duplicates.

Related but not exact duplicates:

• #22452: similar local metadata/index drift between state_5.sqlite, session_index.jsonl, and rollout JSONL files.
• #22971: similar Windows path canonicalization issue involving normal paths vs \\?\ paths.
• #22996: similar post-update Windows Desktop history/resume regression, but that issue focuses on visible threads becoming inaccessible.
• #23189: similar Windows path normalization regression, but WSL-specific.
• #22981: similar Windows Desktop history/open inconsistency, but it focuses on thread/goal/get / resume behavior rather than sidebar/search visibility.

My issue differs because the affected threads are not just failing to resume/open. Most of them are not surfaced in the sidebar/project views or in-app search at all, even though state_5.sqlite still contains active rows and the rollout JSONL files exist.

So this may share the same underlying history/path/index regression, but the user-facing failure mode here is listing/search visibility.

I am seeing the same class of bug on Windows, with current local diagnostics.

Environment:

• Platform: Windows, x64
• Codex executable/product version: 0.131.0-alpha.9
• Observed date: 2026-05-19
• Local storage checked: %USERPROFILE%\.codex\state_5.sqlite, %USERPROFILE%\.codex\session_index.jsonl, %USERPROFILE%\.codex\.codex-global-state.json

User-visible behavior:

• The Desktop sidebar still lists saved projects, but several projects display No chats even though they have unarchived local thread rows.
• One highly active project dominates the visible recent/project list; older or less recently active project histories are effectively pushed out of the sidebar.
• Sidebar options such as Show all chats, Organize -> Chronological list, and project Show more did not restore the missing project histories.
• This makes the app look like project history has been wiped, but the local data is still present.

Read-only local evidence:

• state_5.sqlite contains many unarchived thread rows for projects that are missing or incomplete in the sidebar.
• Representative active/unarchived counts by sanitized project/root group:
• Project A: ~410 active rows across equivalent Windows path forms
• Project B: 74 active rows
• Project C: 47 active rows
• Project D: 24 active rows
• Project E: 14 active rows
• Several cwd values are stored in both plain and Windows extended-length forms, e.g. C:\... and \\?\C:\....
• session_index.jsonl also contains recent thread IDs that are not surfaced consistently by the Desktop project sidebar.

Expected behavior:

• Each visible saved project should show its own unarchived local threads, or provide reliable project-specific pagination/loading.
• A project should not show No chats when state_5.sqlite and session metadata still contain unarchived threads for that project/root.
• The Desktop app should normalize equivalent Windows paths (C:\... vs \\?\C:\...) before grouping threads by project.
• There should be a supported repair/reindex action for rebuilding the sidebar/project grouping from durable local state.

Actual behavior:

• The sidebar appears to rely on a limited or stale recent/global thread subset and/or path-sensitive project grouping.
• Reopening/resuming hidden threads via lower-level mechanisms is possible, but that does not restore the user's requirement: seeing all threads inside their projects in the Desktop sidebar.

A screenshot from the affected sidebar shows multiple saved projects where some show No chats despite local rows existing, while another active project shows only a recent subset. I cannot attach the screenshot through the connector used to post this comment, but it is available if helpful.

This seems closely aligned with #18640, #20833, #21128, #21581, #22796, and this issue, but I wanted to add a current Windows + 0.131.0-alpha.9 data point with project grouping/path-normalization evidence.

I’m seeing a very similar issue on Windows Codex Desktop.

Symptom:

• Project list is visible.
• Most projects show “No chats”.
• Only two currently active projects still show chats.
• The missing sessions are not deleted.

Local verification:

• %USERPROFILE%\.codex\state_5.sqlite passes PRAGMA integrity_check = ok.
• threads table contains 133 rows.
• archived = 0 for all 133 rows.
• Every threads.rollout_path points to an existing rollout-*.jsonl file.
• codex resume --all in Codex CLI shows the missing sessions correctly.
• Direct resume by thread id also works.
• Exporting the rollout-*.jsonl files to Markdown recovered readable transcripts.

Observed Desktop state:

• .codex-global-state.json still contains electron-saved-workspace-roots for the affected projects.
• project-order only contains a subset of projects.
• heartbeat-thread-permissions-by-id contained only 7 thread ids, all belonging to currently visible sessions.
• I tested adding missing permission entries for all 133 DB threads using the same sandbox policy shape as existing entries, but this did not make the Desktop UI show the missing sessions.
• I rolled this change back.

Counts:

• DB threads: 133
• Existing rollout files: 133
• Archived threads: 0
• CLI-visible sessions via codex resume --all: yes
• Desktop-visible sessions: only a small subset

This looks like a Windows Desktop sidebar/project indexing or workspace mapping issue, not data loss. The CLI can still see and resume the sessions.

A built-in repair/reindex action from state_5.sqlite + sessions/**/*.jsonl would be very helpful.

I ran into a similar Windows-side Codex Desktop update issue: older chats were still present locally, but the new UI/sidebar did not show them under the expected project.

I documented the recovery workflow I used here:

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

This is an unofficial workaround, not an upstream fix. It does a dry-run first, checks session_index.jsonl, .codex-global-state.json, SQLite threads.cwd, exact cwd matching, and Windows \\?\ path mismatches, then creates timestamped backups before any write and verifies the result afterward.

It may help if the missing threads still exist in state_5.sqlite and sessions/**/*.jsonl, but the Desktop app no longer associates them with the project after an update.

I ran into the same general failure mode on macOS: Codex Desktop showed "No chats" for projects even though the local SQLite thread store still had active threads and PRAGMA integrity_check returned OK.

In my case, the strongest clue was that pinned chats were still visible. That made it possible to recover visibility by treating this as a sidebar/project index issue rather than data loss.

The workaround I used was:

• rebuild thread-workspace-root-hints from threads.cwd in ~/.codex/state_5.sqlite;
• rebuild sidebar project/chat ordering in .codex-global-state.json;
• use pinned-thread-ids as a fallback for important real project chats;
• archive service automation/subagent threads so the sidebar is not flooded with background runs.

I published a sanitized helper and recovery notes here:
https://github.com/Donkodio/codex-desktop-sidebar-recovery

The helper defaults to dry-run, creates backups before applying changes, and does not upload local data. No raw sessions, tokens, .env, private keys, Telegram sessions, proxy credentials, or private chat dumps are included.

Additional short update from my Windows case, building on the helpful recovery notes from @huajiexiewenfeng and @Donkodio:

What I tried first:

• verified that state_5.sqlite is OK
• verified that all rollout-*.jsonl files still exist
• verified that codex resume --all shows the missing sessions
• tested huajiexiewenfeng/codex-session-recovery
• fixed Windows \\?\ cwd mismatches and rebuilt project/sidebar hints for affected projects
• used surface_codex_sidebar_threads.py to make selected chats visible again

New observation:

After making some progress, I noticed that some previously visible chats suddenly disappeared from the Desktop sidebar again.

Then I archived some chats/projects that I currently do not need. Immediately afterward, other previously missing non-archived chats became visible again.

So this now looks like a Desktop sidebar visibility/surface limit rather than data loss. In my case, roughly 49 chats seem to be visible at the same time. When too many chats compete for the sidebar, some projects show “No chats” even though their sessions still exist and are resumable via CLI.

Practical workaround:

Archive chats/projects you do not currently need. This may make other missing non-archived chats visible again.

The “No chats” label is therefore misleading: it can mean “no chats currently surfaced in the sidebar”, not “no local chats exist”.

Is this intended behavior, or is it a bug?

Short Windows update from another reproduction of this issue.

A copied-app renderer workaround restored hidden project chats on Windows AppX OpenAI.Codex_26.527.7698.0 / codex-cli 0.136.0-alpha.2 without editing state_5.sqlite, session_index.jsonl, or rollout files.

The workaround patches only a copied app\resources\app.asar, not C:\Program Files\WindowsApps\OpenAI.Codex_*, and changes the initial sidebar refresh from the limited global recent slice to the existing all-thread pagination helper:

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

// copied-app workaround replacement; trailing spaces preserve byte length
let t={data:await this.listAllThreads({modelProviders:null,archived:!1}),nextCursor:null};  

Detailed Windows notes: https://github.com/openai/codex/issues/25500#issuecomment-4596553952

This is only an unsupported diagnostic workaround. It reinforces that the hidden chats are usually still local/readable, and that the real fix should be project-scoped pagination/loading by cwd instead of rendering each project from only the already-loaded global recent window.

Affected on macOS, version 26.601.21317. All projects show "No chats" except ones opened fresh after the June 2 update. Data is confirmed intact in state_5.sqlite (486 active threads, all hints correct, session_index complete). Manually opening projects does not trigger re-indexing. This appears to be a sidebar rendering bug introduced in this release.

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.