Codex Desktop on Windows no longer shows older chats after update

[Explorersoft]

In-app feedback ID: 019e3780-31aa-7b70-b26e-57b4f40e5b56

After updating Codex Desktop on Windows, many older chats disappeared from the sidebar/project views and are not found by in-app search.

The data still exists locally:

• ~/.codex/state_5.sqlite contains the missing threads
• ~/.codex/sessions contains the JSONL session files
• Threads are active, not archived

Examples:

• HealthAgents shows only 3 chats, but local state has 38 active threads for that cwd
• ZONE-koop shows only 2-3 chats, but local state has 19 active threads
• Restarting Codex and rebooting Windows did not fix it

Possible cause:
Some thread cwd values are stored as \?\D:... while project roots are D:...
The UI/sidebar/search may not be normalizing Windows extended-length paths consistently.

Environment:

• Windows
• Codex Desktop: OpenAI.Codex_26.513.4821.0_x64__2p2nqsd0c76g0
• App/server version in sessions: 0.131.0-alpha.9

[github-actions]

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

[Explorersoft]

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

[Explorersoft]

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:

• Codex Desktop local thread can be hidden/stale when state_5.sqlite and session_index.jsonl drift on Windows #22452: similar local metadata/index drift between state_5.sqlite, session_index.jsonl, and rollout JSONL files.
• Codx Chat History Bug after updating #22971: similar Windows path canonicalization issue involving normal paths vs \?\ paths.
• Codex Desktop: completed threads become inaccessible after update #22996: similar post-update Windows Desktop history/resume regression, but that issue focuses on visible threads becoming inaccessible.
• Windows Codex + WSL project: older threads lose cwd and terminal tries to cd into malformed WindowsApps/app/resources/\\wsl$ path #23189: similar Windows path normalization regression, but WSL-specific.
• Codex Desktop on Windows: existing history thread opens/resumes inconsistently; thread/goal/get returns "goals feature is disabled" #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.

[pseudico]

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.