Windows app: older local threads disappear from sidebar and sidebar search after restart while still present on disk

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

• #17304
• #16901
• #17317
• #17354
• #16095

Powered by Codex Action

Potential duplicates detected. Please review them and close your issue if it is a duplicate. Desktop project sidebar hides active threads after state DB migration drift and stale temporary sessions #17304 Desktop thread panel hides existing workspace threads after workspace restructuring; backend pagination still returns them #16901 Multiple sidebar bugs after workspace directory migration: "56 years ago" timestamps, missing threads, threads vanish on click (macOS) #17317 Recent Thread history wiped in app, present in CLI #17354 * Mac app stops showing local threads even though local thread data still exists #16095 _Powered by Codex Action_

Codex Action suggested possible duplicates: #17304, #16901, #17317, #17354, #16095.

I reviewed them. They look related, but I don’t think this issue is an exact duplicate:

• #16901, #17317, #17354, and #16095 are macOS issues or different desktop/UI failure modes.
• #17304 is the closest desktop/sidebar case, but my report is specifically on Windows and includes repeated regeneration of threads.cwd to \\?\C:\... after repair, plus sidebar search failing for a known locally present thread ID.

So I’m keeping this open as a Windows-specific variant unless maintainers prefer consolidation.

I can reproduce a related Windows path-normalization/sidebar issue on Codex Desktop 26.409.20454.

Environment (redacted):

• Windows 11
• Workspace folder initially added as: C:\Users\<redacted>\Desktop\Crypto

Repro variant:

1. Keep Crypto already present in the left workspace list.
2. Start a new thread from Windows File Explorer context in the same Crypto folder (instead of starting from the existing left-sidebar workspace entry).
3. Return to Codex Desktop.

Observed:

• Sidebar ends up with two visually identical Crypto workspace entries.
• Internally these map to two path forms (plain vs device-prefixed):
• C:\Users\<redacted>\Desktop\Crypto
• \\?\C:\Users\<redacted>\Desktop\Crypto
• One Crypto entry can show No threads even while active/recent threads exist in the other entry.
• This looks like workspace grouping/indexing mismatch, not data loss.

Local evidence (redacted):

• Threads remain present on disk under .codex/sessions.
• Thread rows remain present in state_5.sqlite.
• Only one thread was archived; active threads still existed for the \\?\...\Crypto cwd variant.

Expected:

• Path canonicalization should treat these two forms as the same workspace.
• The sidebar should show one Crypto workspace with all threads.

My case, if there something useful here (analysed by Codex):

Summary

Some Codex threads disappear from the Windows app sidebar and cannot be found via search, even though the thread data still exists locally on disk and is still present in the local session index.

This appears to be a UI/sidebar/search indexing or visibility issue rather than data loss.

Environment

• Product: Codex desktop app
• Platform: Windows
• Date observed: April 17, 2026

Expected behavior

Threads that still exist locally and are present in the local session index should remain visible in the sidebar and be discoverable through search, unless they are explicitly archived and intentionally hidden.

Actual behavior

A thread expected under a title like Review PaymentTerminal.cs / Review PaymentTerminal.cs for bugs was missing from the sidebar and could not be found by search.

However, the thread still existed in:

• the active local sessions store
• the local session_index.jsonl

Evidence

Matching active threads found in C:\Users\veskar1\.codex\session_index.jsonl:

• 019d027f-13de-7b40-a432-5fab12f18704

Title: Review PaymentTerminal.cs for bugs

• 019d02a2-12de-7992-aab9-5d9ce89ed273

Title: Review PaymentTerminal.cs for bugs

Matching local thread files:

• C:\Users\veskar1\.codex\sessions\2026\03\18\rollout-2026-03-18T21-49-35-019d027f-13de-7b40-a432-5fab12f18704.jsonl
• C:\Users\veskar1\.codex\sessions\2026\03\18\rollout-2026-03-18T22-27-49-019d02a2-12de-7992-aab9-5d9ce89ed273.jsonl

Opening prompts in those files:

• PaymentTerminal.cs Can you review the file for serious bugs?
• PaymentTerminal.cs Can you review the file for serious bugs?

Also observed:

• archived threads are stored separately under C:\Users\veskar1\.codex\archived_sessions
• this specific missing thread was not in archived_sessions
• therefore this case does not appear to be explained by archiving

Impact

Important historical threads can appear lost even though local data is intact, which makes recovery difficult and reduces trust in sidebar/search history.

Notes

This looks like one of:

• sidebar not loading all indexed threads
• search not searching the full local index
• stale/corrupt local UI state causing some threads to be hidden
• mismatch between active-thread store and what the sidebar renders

I can reproduce a related Windows Codex Desktop sidebar bug on the current Store build, with a WSL-mirrored workspace.

Environment

• Codex App version: 26.415.4716.0
• Codex CLI version: 0.121.0
• Pi version: 0.67.68
• Platform: Microsoft Windows NT 10.0.26200.0 x64
• Workspace root affected:
• `\\?\\C:\Users\Administrator\wsl-ubuntu\home\administrator

What I see

In Codex Desktop, the ios-gamesec-re project appears in the left sidebar but shows No chats.

However, those chats still exist locally and can still be resumed from CLI/Pi.

This is not data loss:

• the local state DB still contains the threads
• the rollout session files still exist on disk
• the workspace root saved by the desktop app exactly matches the threads.cwd values for the missing chats
• local backfill state is complete

Local evidence

From local diagnostics:

• backfill_state in state_5.sqlite is complete
• all rollout_path files referenced by thread rows still exist on disk
• there are 59 non-archived threads whose cwd exactly matches:
• `\\?\\C:\Users\Administrator\wsl-ubuntu\home\administrator\
• the desktop app's saved workspace roots also contain that exact path string
• despite that, the project still renders as No chats

Representative local thread still present:

• id: e605a6f5-0e5c-4cb6-b70e-cb43b57d5a48

Another older thread visible via local state but not surfaced in the desktop sidebar:

• id: 019d2002-f300-7240-a50f-92b2af07d633

Important detail that points to sidebar hydration / pagination

This does not look like a path mismatch anymore.

For the exact affected workspace path above:

• total exact-match non-archived threads: 59
• exact-match threads inside top 50 by created_at_ms: 2
• those 2 are exec threads

This seems consistent with the broader report that the desktop sidebar is hydrating from a limited recent slice instead of the full project-scoped local thread set.

Logs

Desktop logs show successful thread/list responses, while the UI still fails to show the expected chats for the project.

I also saw a separate renderer/app-state error during local investigation:

• Conversation state not found conversationId=019da807-60df-7a62-b563-48b9aacbfb51

Representative log file on my machine:

• %LOCALAPPDATA%\\Packages\\OpenAI.Codex_2p2nqsd0c76g0\\LocalCache\\Local\\Codex\\Logs\\2026\\04\\19\\codex-desktop-328faca3-f58d-408b-b146-2dc0eb8c3fcd-33448-t0-i1-231542-0.log

Expected behavior

If a saved workspace root exactly matches threads.cwd for local non-archived threads, the project should show those chats in the desktop sidebar.

Actual behavior

The project is listed, but the sidebar still shows No chats even though the local thread store is populated and CLI/Pi can still resume the threads.

Artifacts available

I can provide redacted copies of:

• %USERPROFILE%\\.codex\\state_5.sqlite
• %USERPROFILE%\\.codex\\session_index.jsonl
• %USERPROFILE%\\.codex\\sessions
• desktop log excerpts
• sidebar screenshots

I can reproduce a related Codex Desktop sidebar failure on macOS, and the pinned-chat behavior seems like a useful clue.

In my case, this does not look like data loss:

• ~/.codex/state_5.sqlite integrity checks pass.
• Missing chats still exist in SQLite, session_index.jsonl, and rollout JSONL files.
• Direct app-server thread/list requests for the affected project roots return the missing chats.

What the UI shows:

• Pinned chats survive.
• Project sections render as No chats.
• Non-pinned/project chats disappear again after restart/state refresh.

The local desktop state split seems relevant:

• pinned-thread-ids remains correct.
• Other sidebar/project membership state regresses to a stale or narrow shape, including active-workspace-roots, project-order, projectless-thread-ids, and thread-workspace-root-hints.

So this looks like a Desktop sidebar hydration/cache bug rather than an app-server thread/list failure. Pinned chats survive because they are keyed directly by thread ID; normal/project chats can vanish when cached workspace membership or thread-to-workspace hints drift.

Suggested fix direction: treat sidebar membership caches as advisory. On launch/sidebar refresh, rehydrate saved workspace/project sections from authoritative thread/list results, follow pagination for project-scoped lists, normalize workspace identity consistently, and rebuild/discard stale hints instead of rendering No chats.

---

Follow-up after deeper local investigation: I think my macOS case is primarily a sidebar hydration/pagination issue, and related but not identical to the Windows path-canonicalization reports above.

Direct project-scoped thread/list calls return the missing chats for the affected project roots. However, the Desktop sidebar appears to build project contents from a limited global recent-thread slice. On my machine, newer automation/companion threads from another workspace push these project chats outside that slice, so the saved project sections remain visible but render as No chats.

So there may be at least two overlapping failure modes here:

• workspace identity/path normalization issues, especially on Windows with \?\C:\... paths
• sidebar hydration/pagination that relies on one global recent page instead of querying saved workspace roots authoritatively

A robust fix likely needs both: consistent workspace identity normalization, plus project-scoped/sidebar pagination so saved projects are populated from their own thread/list results rather than from one recent global page.

Similar problem, potentially related. And I haven't really seen what exactly triggers it. But typically, I observe it after signing out and signing in with a different account. Not sure though whether this is triggering it, or the chat already disappeared before that.

This happened in stages for me, slowly more and more chats are not shown anymore (majority is still there, luckily). Potentially also affecting the older sessions (as if there was some fixed limit of how many sessions to show, ...).

Retracted by author request. Will repost manually if needed.

Adding another Windows data point from a current local investigation. This looks like the same issue class, but with a useful extra detail: after a manual DB repair the visible/missing projects can effectively invert, which points to two overlapping failure modes rather than a single stale cwd row.

Environment / storage checked:

• Windows, Codex local state under %USERPROFILE%\.codex
• state_5.sqlite, .codex-global-state.json, and rollout JSONL files under .codex\sessions
• Current npm CLI checked separately: codex-cli 0.132.0
• Observed on 2026-05-20

User-visible behavior:

• The Desktop sidebar still lists saved projects.
• Some projects show only a few chats or No chats, even though active local thread rows still exist for those projects.
• Other projects suddenly show many chats after a manual repair.
• After another refresh/relaunch, the visible vs empty projects change again. In practice this feels like an inversion: the projects that were manually fixed become visible, while older/less recent projects become empty.

Local DB evidence after the latest refresh:

TOTAL_APP_VISIBLE_CANDIDATES=231
TOP50=50

Representative affected projects:

normalized visible rows: 1
exact plain visible rows: 0
first rank in global recent list: 58

normalized visible rows: 10
exact plain visible rows: 0
global ranks: 80-89

normalized visible rows: 11
exact plain visible rows: 0
global ranks: 59-69

normalized visible rows: 21
exact plain visible rows: 21
global ranks: 153-173

normalized visible rows: 44
exact plain visible rows: 33
variants: both plain D:\... and \\?\D:\...

So there are two separate signals:

1. Windows path identity is still unstable. In this snapshot, state_5.sqlite contains many active rows and any tool should use a Windows extended-length prefix (\\?\...). For sampled affected threads, rollout JSONL session_meta.cwd and turn_context.cwd were already plain D:\..., but threads.cwd had become \\?\D:\... again after Desktop/app refresh. That means a DB-only normalization is not durable.
2. Even after normalizing by hand, many affected project rows are outside the first global recent page. In the snapshot above, starts at global rank 58, or at 59, another at 80, and the older one at 153. If the Desktop sidebar hydrates project contents only from a global thread/list(limit: 50) page, those projects can render as empty even though project- scoped local data exists.

This is why the failure looks cyclic from the user side: fixing cwd helps one layer, but then the global recent-page/sidebar hydration limit still hides projects; trying to promote or touch rows makes those projects visible at the expense of others, so the visible/missing set appears to invert.

This seems consistent with #18640/#19873/#23193/#22796. The sidebar likely needs both fixes:

• Durable, consistent Windows path identity normalization for persisted threads.cwd, workspace roots, and thread/workspace hints (D:\... and \\?\D:\... must be treated as the same project).
• Project-scoped sidebar hydration/pagination. Saved project sections should query/page thread/list for that project/root, rather than deriving project contents only from one global recent page.

From the local evidence, this is not data loss. The rows and rollout files are still present; the Desktop sidebar is failing to surface/group them reliably.

This looks bigger than sidebar search. For resumability, losing discoverability is very close to data loss. In MartinLoop we ended up separating the canonical session receipt from rebuildable UI indexes: immutable session/thread identity plus normalized workspace metadata at write time, then any sidebar/search index can be regenerated from that source of truth.

If state_5.sqlite and session_index.jsonl still know the thread exists, I would love an explicit repair/reindex path and a visible "some local threads are unavailable due to index mismatch" warning. Students get hit especially hard here because old receipts disappear right when they need to resume prior work or prove what the model did.

What version of the Codex App are you using (From “About Codex” dialog)?
26.519.21041

What subscription do you have?
Pro

What platform is your computer?
Microsoft Windows 11 NT 10.0.26200.0 x64

What issue are you seeing?
The Codex App sidebar on Windows intermittently hides existing local threads and sometimes makes existing threads impossible to open from codex:// links.

Feedback ID: 019d881f-670a-7e21-a6bf-987d5dd75aed

Symptoms:

I have around 80+ local Codex threads across several projects.
The local Codex state database still contains the threads, and their rollout JSONL files exist.
The sidebar shows only a subset of threads.
Sometimes project groups become empty and threads move to the generic Chats area.
Sometimes previously visible threads disappear after restart/reboot, while other older threads appear.
Some codex://threads/<thread_id> links do not open the target thread unless that thread is currently visible/loaded in the sidebar.
Restarting Codex and rebooting Windows did not fix it.
Changing sorting to Chronological did not fix it.
One observed error when trying to resume a thread:

cannot resume running thread 019e4751-d521-7290-9627-e501f3d7d2d3 with stale path: requested \\?\C:\Users\<USER>\.codex\sessions\2026\05\21\rollout-2026-05-21T00-36-45-019e4751-d521-7290-9627-e501f3d7d2d3.jsonl, active C:\Users\<USER>\.codex\sessions\2026\05\21\rollout-2026-05-21T00-36-45-019e4751-d521-7290-9627-e501f3d7d2d3.jsonl

This looks like either:

a sidebar pagination/limit/virtualization bug;
a state synchronization bug between local DB, global state, and session files;
or a Windows path normalization bug (\\?\C:\... vs C:\...) that prevents resume.
What steps can reproduce the bug?
Use Codex App on Windows with many local threads, approximately 80+.

Organize threads across multiple projects/workspaces.

Close and reopen Codex App, or reboot Windows and open Codex again.

Open the left sidebar and check project groups.

Observe that only part of the existing threads are visible.

Try opening an existing hidden thread through a deep link, for example:

codex://threads/019e4751-d521-7290-9627-e501f3d7d2d3

In some cases the thread does not open, even though the local state DB still has it and the rollout JSONL exists.

In one case Codex showed a stale path error caused by different Windows path forms:
\\?\C:\Users\<USER>\... vs C:\Users\<USER>\...

I also generated a local HTML index directly from the Codex local state DB as a workaround. It confirms that the threads exist locally, but the app sidebar and/or deep links do not reliably expose them.

What is the expected behavior?
All existing local threads should remain discoverable and openable.

Expected:

The sidebar should show all active threads, or provide reliable pagination/search if there is a display limit.
Project groups should not randomly become empty after restart.
Existing threads should not move unpredictably between project groups and generic Chats.
codex://threads/<thread_id> should open any existing local thread regardless of whether it is currently visible in the sidebar.
Windows path normalization should treat \\?\C:\... and C:\... as the same session file when resuming a thread.
Additional information
Related/possibly similar issue:
https://github.com/openai/codex/issues/13846

Feedback ID:
019d881f-670a-7e21-a6bf-987d5dd75aed

Local observations:

Codex local DB: C:\Users\<USER>\.codex\state_5.sqlite
Session files: C:\Users\<USER>\.codex\sessions\...
App logs: C:\Users\<USER>\AppData\Local\Codex\Logs\...
The issue persisted after Codex restart and Windows reboot.
A local export from the DB can list the missing threads, so this does not look like deleted data.

That stale-path error is the strongest clue in the thread so far. If resume treats \\?\\C:\\... and C:\\... as different session locations, the sidebar/search miss and the deep-link miss can come from the same broken identity boundary.

The repair shape I'd want is:

• canonical thread/session identity independent of display path
• one workspace-key normalization pass at write time, not best-effort repair after launch
• sidebar/project hydration from project-scoped thread lists, not only a global recent slice
• deep-link open by thread id first, then resolve the current rollout path from canonical state

That way a bad path form can make a receipt noisy, but it cannot make an existing local thread undiscoverable.

One more data point that seems to support this identity/hydration hypothesis:

After updating the CLI to 0.133.0 and running:

codex resume --all <thread-id>

the same original thread became visible again in the Codex Desktop app/sidebar. No copied replacement thread was created; it was the original thread ID.

So the local thread/session is present and resumable by CLI, but Desktop can miss it until the CLI resume path touches or rehydrates the session state.

This makes the issue look less like data loss and more like a Desktop sidebar/deep-link hydration problem around canonical thread identity, workspace/path normalization, or recent/project-scoped indexing.

That codex resume --all <thread-id> data point is useful because it suggests the canonical thread state is still healthy and the CLI path can rehydrate it by thread id. If that is true, Desktop should probably do the same thing on deep-link open and sidebar repair:

• resolve by thread_id first
• fetch the current rollout/session path from canonical local state
• rebuild sidebar/project membership from that result

That would make a bad workspace hint or stale path form noisy, but not able to hide an otherwise healthy local thread.

Adding a current Windows datapoint after the latest Codex Desktop update.

This still reproduces for me. Local thread state appears healthy: the threads exist in state_5.sqlite / rollout files, and my local state-db export can enumerate the active threads. The Desktop sidebar still behaves like a bounded recent window: when an older valid thread is made visible/resumed, another valid thread disappears from the sidebar.

This creates a recovery loop:

1. Older local threads are hidden from sidebar/search even though they exist on disk.
2. Resuming/opening an older thread makes it “recent” and visible.
3. Another valid thread is then pushed out of the visible sidebar list.
4. Some older long threads then trigger automatic compaction and fail with context_length_exceeded, so they cannot be safely continued.

Related path signal also still appears on Windows:
requested path uses C:\...
active path uses \\?\C:\...
These appear to be treated as different session locations in some resume/deep-link paths.

Expected behavior:

• Sidebar/search should hydrate from canonical thread_id/project state, not only a recent slice.
• Deep links should resolve by thread_id first, then current rollout/session path.
• Bad/stale path hints should not make an existing local thread undiscoverable.

Codex for Windows app loses visible project chat children after a project is collapsed and later re-expanded. The session JSONL files remain present and valid under %USERPROFILE%\.codex\sessions. Ctrl+G can find the missing sessions, but they will not display when they are clicked from the Ctrl-G. Codex itself can toggle the pinned state when asked and that makes them visible under Pinned, but they do not reappear under their original project. This indicates a stale or corrupted project-to-session sidebar index, not deleted session data.

Once they are shown in Pinned, you can unpin them, and they reappear in the Project.

But, after restoring all the chats this way (prompting Codex to do it), After closing down Codex with collapsed projects again. Upon restart all those chats are missing again.

I am seeing the same class of issue on Windows after a newer Codex Desktop update.

Environment:

• Windows, Codex Desktop from Microsoft Store package OpenAI.Codex_26.602.4764.0_x64__2p2nqsd0c76g0
• Local state under %USERPROFILE%\.codex

Observed behavior:

• Project conversations still exist in local backend data (state_5.sqlite and %USERPROFILE%\.codex\sessions\YYYY\MM\DD\rollout-*.jsonl).
• The left sidebar project groups show No conversations, or only a small subset of conversations.
• Keyword search can sometimes find conversations that are not visible in the project group.
• After restart or after the app-server reindexes, visibility changes again.
• Some recurring automation threads can reappear in normal project/sidebar space and crowd out real project conversations.

Additional diagnostics from this machine:

• There are many project assignments and local rollout files still present, so this is not actual data loss.
• The sidebar/project view appears to depend on a limited recent-conversation window plus explicit project assignment state.
• threads.cwd values can be rewritten between normal paths and extended Windows paths like \\?\C:\....
• Normalizing paths and rebuilding project assignments can temporarily restore visibility.
• Refreshing timestamps in both SQLite and the corresponding rollout JSONL files also changes which conversations appear, suggesting the desktop sidebar/app-server recent index is dropping older-but-existing local threads.

Impact:
This looks like data loss to users. In project-based workflows, hidden conversations cause loss of work continuity because the user relies on the left sidebar project folders to remember active ideas and tasks.

Expected behavior:

• All local threads belonging to a saved project should remain visible or reachable from that project after restart.
• Sidebar search should return existing local threads by title or id.
• \\?\C:\... and C:\... should be treated as the same workspace root for grouping.
• Automation/recurring task threads should not crowd out normal project conversations unless explicitly shown.

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.

Thanks for the macOS datapoint. My Windows case looks very similar.

On my side, this still does not look like data loss: state_5.sqlite and the rollout JSONL files still contain the missing threads. Manual repairs can temporarily change which conversations are visible, but after restart/reindex the sidebar can still hide older project threads again.

So I agree with your conclusion: current behavior feels like partial recovery at best. A durable official local reindex/recovery command would be very helpful, ideally rebuilding project/sidebar history from the canonical local thread/session state instead of relying on the current sidebar cache or recent-thread window.