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

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

26.409.20454

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.22631.0 x64

What issue are you seeing?

Older local Codex Desktop threads are no longer returned by the sidebar list or sidebar search after restart, even though they still exist in local state on disk.

Observed environment:

Codex About version: 26.409.20454
local diagnostics also show: app.version=0.119.0-alpha.28
Windows 11
timezone: Europe/Brussels
observed on 2026-04-12

What I see in the UI:

after a cold exit and relaunch, the sidebar only shows threads up to about 1w old
older threads are missing from the sidebar
switching the sidebar to Chronological does not restore them
searching for known missing thread ID 019cd29b-9215-7943-ae51-aa9c10dd74b4 returns no result

Why this looks like a local-state/indexing bug rather than data loss:

state_5.sqlite still contains 121 thread rows
session_index.jsonl still contains older March 2026 thread IDs
on-disk session rollout files still exist
the missing thread ID above is present locally but not returned by sidebar search

Strong path-normalization signal:

many threads.cwd values in state_5.sqlite are stored as \\?\C:\...
these can be normalized while Codex is closed
after reopening Codex, the app writes the \\?\-prefixed form back again

Relevant counts:

threads_total=121
first repair: cwd_prefixed_before=92
first repair: cwd_prefixed_after=0
after reopening Codex: prefixed threads.cwd rows returned to 92
first repair: index_lines_before=124
first repair: index_unique_before=118
first repair: index_duplicate_ids_before=5
first repair: index_lines_after=121

What steps can reproduce the bug?

Fully exit Codex Desktop on Windows so no Codex process remains.
Launch Codex Desktop again.
Wait for the sidebar to load.
Observe that only recent threads are visible; the oldest visible threads are about 1w old.
Switch the sidebar to Chronological.
Search for known missing thread ID 019cd29b-9215-7943-ae51-aa9c10dd74b4.
Observe that the sidebar search returns no result.
Inspect local state:
- state_5.sqlite still contains older threads
- session_index.jsonl still contains older thread IDs
- older rollout session files still exist under %USERPROFILE%\.codex\sessions

Repair attempts that did not fix it:

Rebuilt session_index.jsonl
Normalized threads.cwd in state_5.sqlite
Patched workspace-root state
Reset package-local cache
Cleaned duplicated workspace roots
Reinstalled Codex Desktop

Result after all of the above:

older threads still do not appear in the sidebar
older threads still do not appear in sidebar search
after relaunch, prefixed threads.cwd values are regenerated

Representative local examples:

missing thread still present locally:
- id=019cd29b-9215-7943-ae51-aa9c10dd74b4
- created_at=2026-03-09 12:38:56 UTC
prefixed non-OneDrive example:
- id=019cf6d0-b928-7231-a20f-c732d658d315
- created_at=2026-03-16 13:23:19 UTC
- cwd redacted=\\?\C:\dev\<project_redacted>
plain non-OneDrive example:
- id=019d2479-db67-7173-b7a2-39918425f817
- created_at=2026-03-25 10:10:59 UTC
- cwd redacted=C:\dev\<project_redacted>

This does not appear to be OneDrive-only:

older missing threads include both OneDrive and non-OneDrive paths
they also include both \\?\C:\... and plain C:\... path forms

What is the expected behavior?

All local threads should remain visible and searchable in the Codex Desktop sidebar after restart.

Specifically:

restarting Codex should not hide older local threads
switching the sidebar to Chronological should still show those threads
sidebar search should return a locally existing thread ID or title
Codex should not regenerate path state in a way that breaks thread visibility

Additional information

Additional diagnostics:

logs_2.sqlite shows repeated thread/resume activity around launch/resume windows
no explicit log line was found saying “cwd rewritten”, but the before/after SQLite state shows that the prefixed cwd values are regenerated after app launch
local diagnostics include:
- app_server.client_version="26.409.20454"
- app.version=0.119.0-alpha.28

Artifacts available on request:

%USERPROFILE%\.codex\state_5.sqlite
%USERPROFILE%\.codex\session_index.jsonl
%USERPROFILE%\.codex\logs_2.sqlite
%USERPROFILE%\.codex\sessions
%USERPROFILE%\.codex\archived_sessions

I also have a redacted sidebar screenshot showing that the oldest visible items are labeled 1w, plus redacted exports of the thread state, session index, and launch-log summary.

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

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:

Keep Crypto already present in the left workspace list.
Start a new thread from Windows File Explorer context in the same Crypto folder (instead of starting from the existing left-sidebar workspace entry).
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:

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.
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:
#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

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:

Older local threads are hidden from sidebar/search even though they exist on disk.
Resuming/opening an older thread makes it “recent” and visible.
Another valid thread is then pushed out of the visible sidebar list.
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.

I reproduced a more specific variant of this issue and identified a metadata condition that reliably controlled whether affected threads appeared in the Windows desktop sidebar.

Environment

ChatGPT desktop, powered by Codex & OWL: 26.715.72359
Release date shown in app: July 22, 2026
Codex CLI: 0.145.0
Windows 11 Pro 25H2, build 26200.8894, x64
Local project path: standard non-OneDrive path

Observed behavior

A local project contained 8 top-level user threads. After closing and reopening the desktop app, only 2 threads remained visible in the project sidebar. The other 6 were not archived and were not visible through the project UI.

The missing threads were not deleted:

Their rollout .jsonl files still existed under %USERPROFILE%\.codex\sessions
Their IDs and names were present in session_index.jsonl
Their rows were present in state_5.sqlite
Their project assignments and working-directory values were correct in .codex-global-state.json
codex resume <session-id> successfully opened the complete missing conversation

Database difference found

In the threads table of state_5.sqlite, all 8 top-level threads had:

thread_source = 'user'
archived = 0
Correct cwd
Correct rollout path

However, the 6 hidden threads had:

Empty first_user_message
Empty preview

The 2 visible threads had both fields populated.

All 6 hidden threads began with long pasted requests. In their rollout transcripts, the actual opening request had been stored in:

%USERPROFILE%\.codex\attachments\<attachment-id>\pasted-text.txt

The rollout user event referenced that attachment, but the corresponding threads.first_user_message and threads.preview fields were left empty.

Recovery result

With the desktop app fully closed, I backed up the Codex state and populated only these two empty fields for one affected thread using its authentic original text from pasted-text.txt:

first_user_message
preview

After reopening the desktop app, that thread immediately appeared in the correct project sidebar.

I then applied the same repair to the other 5 affected threads. All 8 project threads became visible again.

No rollout transcripts, session IDs, project assignments, titles, archive states, working directories, or project files were changed.

has_user_event remained 0 for all 8 threads, including the visible ones, so that field did not appear to control visibility in this case.

Possible trigger

A possible reproduction path is:

Start a new local Codex Desktop thread on Windows.
Use a sufficiently long pasted request as the first message.
Codex stores the request as attachments\<id>\pasted-text.txt.
The thread row is created with empty first_user_message and preview.
Close and reopen the desktop app.
The thread is absent from the project sidebar even though its transcript and indexes remain intact.

This may be a separate trigger or root cause within the broader missing-local-thread symptom reported here. It appears that attachment-backed first messages are not always propagated into the thread preview metadata used by the desktop sidebar.

I can provide sanitized SQL schema details, a read-only diagnostic script, and the repair logic if useful. I will not upload the database, transcripts, or original prompts because they contain private project content.

Navigation Menu

Repository navigation

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

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Summary

Environment

Expected behavior

Actual behavior

Evidence

Impact

Notes

Environment

What I see

Local evidence

Important detail that points to sidebar hydration / pagination

Logs

Expected behavior

Actual behavior

Artifacts available

Environment

Observed behavior

Database difference found

Recovery result

Possible trigger

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Apr 12, 2026

dumbly commented on Apr 12, 2026

bjorkepoc commented on Apr 14, 2026

VesaKardin commented on Apr 17, 2026

Summary

Environment

Expected behavior

Actual behavior

Evidence

Impact

Notes

kappa9999 commented on Apr 20, 2026

Environment

What I see

Local evidence

Important detail that points to sidebar hydration / pagination

Logs

Expected behavior

Actual behavior

Artifacts available

theysayheygreg commented on Apr 30, 2026

claell commented on May 1, 2026

vladskuzn commented on May 20, 2026

nos1609 commented on May 20, 2026

Keesan12 commented on May 20, 2026

d1sc0v3r commented on May 21, 2026

Keesan12 commented on May 21, 2026

d1sc0v3r commented on May 21, 2026

Keesan12 commented on May 21, 2026

d1sc0v3r commented on May 23, 2026

sdick3 commented on Jun 2, 2026

onedooge commented on Jun 6, 2026

wangyaok1 commented on Jun 7, 2026

wangyaok1 commented on Jun 10, 2026

onedooge commented on Jun 22, 2026

brigysl commented on Jul 23, 2026

Environment

Observed behavior

Database difference found

Recovery result

Possible trigger

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions