Codex Desktop Projects sidebar shows "No chats" for projects with older non-archived conversations

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

• #25463
• #25341
• #24178

Powered by Codex Action

#25463 looks closely related. My report may be another reproduction of the same underlying local indexing/listing consistency issue, but with one additional observation:

On Windows, the affected conversations are still non-archived and are returned by the app-server when calling thread/list with the project cwd filter. However, the Projects sidebar still renders "No chats" when those conversations are older than the sidebar's recent conversation set.

So this may specifically be caused by the Projects sidebar grouping only a limited recent conversation list instead of querying history by project cwd, or at least not doing a fallback cwd query when a project appears empty.

Windows data point and copied-app workaround confirmation.

I reproduced the same failure mode on Windows Desktop and tested the renderer workaround on a copied app, not on the installed WindowsApps package.

Environment tested:

• Windows Codex Desktop AppX: OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0
• CLI: codex-cli 0.136.0-alpha.2
• Earlier Windows AppX 26.527.3686.0 had the same renderer target/signature.
• Target generated renderer bundle in both builds:

webview/assets/app-server-manager-signals-Bpaj8VHp.js

Local evidence:

• The missing project chats were still present locally.
• thread/list by exact project cwd could return the expected non-archived threads.
• The Desktop project sidebar still showed No chats because the affected threads were outside the loaded global recent window.
• No SQLite/session/rollout data edits were needed for the workaround.

Mechanism:

The renderer initial sidebar refresh still contains a global recent-window call:

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

Patching that call in a copied app to use the existing all-thread pagination helper restored the hidden project chats:

let t={data:await this.listAllThreads({modelProviders:null,archived:!1}),nextCursor:null};  

Note the trailing spaces in the replacement above are intentional in my local patch so the replacement stays byte-length preserving for the packed generated JS asset.

Windows deployment approach that worked:

1. Do not patch C:\Program Files\WindowsApps\OpenAI.Codex_* in place.
2. Copy the package app directory to a user-writable location, for example:

%USERPROFILE%\.codex\patched-main\app.

1. Patch only the copied app\resources\app.asar.
2. Update the ASAR file-entry integrity hash for the modified generated JS asset.
3. Launch the copied Codex.exe with:

• CODEX_HOME=%USERPROFILE%\.codex
• CODEX_ELECTRON_USER_DATA_PATH=%USERPROFILE%\.codex\patched-main\electron-user-data

1. Do not run official Codex and the copied patched app at the same time against the same live CODEX_HOME.

Observed result:

• The lab copy using a copied CODEX_HOME showed the previously hidden project chats.
• A patched-main copy using the live CODEX_HOME also launches from the copied app path.
• Running process paths are under %USERPROFILE%\.codex\patched-main\app, not WindowsApps.
• Patch verification on the copied app.asar:
• patched marker present: true
• original marker present: false

This is not a proper upstream fix. It is only a diagnostic/workaround patch and can increase startup/sidebar load for users with many local threads.

The product fix should probably keep the normal global recent list for the generic Chats section, but fetch project history separately when a project is expanded, using project-scoped pagination such as thread/list({ cwd, archived: false, cursor, limit }). No chats should only be rendered after a project-scoped query completes empty.

Thanks for confirming the Windows reproduction and the renderer-side cause. I will leave this issue open for upstream tracking, since the workaround is useful for diagnosis but not a proper product fix. The expected fix should still be project-scoped pagination/fallback querying before rendering "No chats".

I can confirm this on Codex App Version 26.527.60818 (3437) on MacOS Sequoia 15.7.7 (24G720).
Via search function I can find chats/threads from those projects but clicking on them opens nothing (just seeing the background with the logo instead of the chat which should actually be visible).

Update with more feedback depth (working locally):

I can reproduce a very similar issue on macOS, with additional evidence that this is not data loss but a Codex Desktop UI hydration/routing bug.

Environment:

• macOS, Codex Desktop
• bundled app-server reports 0.136.0-alpha.2
• multiple local projects are affected

Observed UI behavior:

• The Projects sidebar shows affected local projects but displays No chats / Keine Chats.
• The global search modal initially shows only a small set of recent chats.
• Searching for a term associated with an affected project does return old matching threads from that project.
• Clicking one of those search results closes the search dialog, but the main chat area stays blank and only shows the Codex logo.
• The thread does not open, and there is no usable way in the UI to access that old project thread.

Local data checks:

• The old conversations are still present locally.
• state_5.sqlite contains the affected original thread rows.
• The affected threads are non-archived and have valid cwd values pointing to the correct local project directories.
• The corresponding rollout JSONL files still exist under ~/.codex/sessions/.
• session_index.jsonl also contains the affected thread IDs.
• Direct app-server thread/read on one affected original thread works and returns the full conversation history.

Concrete experiment:

• An affected original project thread is found by Codex Desktop search.
• Clicking the search result navigates to the thread route but leaves the UI blank.
• Direct app-server thread/read for the same thread ID succeeds and returns the conversation turns.
• Changing only updated_at / updated_at_ms in state_5.sqlite did not fix the UI; app-server later reconstructed the original timestamps from rollout/session metadata.
• Forking the same original thread through app-server did work: the forked thread appeared under the correct project in the Desktop sidebar and opened correctly.

This strongly suggests:

• the old thread contents are intact
• app-server can read them
• newly created/forked threads hydrate correctly
• Codex Desktop fails to hydrate older existing project/search-result threads, especially when they are outside the initially loaded recent set or were created with older Codex versions

Expected behavior:

• Expanding a project should query or hydrate threads by that project cwd, not rely only on an initially loaded recent cache.
• Clicking a search result should always open the selected thread by ID via thread/read / thread/resume, even if that thread is not currently present in the sidebar's recent-thread cache.
• If a project has non-archived local conversations, the sidebar should not display No chats.

Impact:

This made it look as if many local project chats had disappeared. Recovering and proving that the data was still present required substantial local debugging across Codex local state, session index files, rollout JSONL files, app-server calls, and Desktop logs.

I would also like to raise a billing/support concern:
debugging this product regression consumed a significant amount of paid Codex/API usage and subscription quota. Since the usage was spent investigating a Codex Desktop bug rather than normal productive work, I would appreciate guidance on reimbursement or account credit for the wasted usage.

I can confirm the same/similar issue on macOS with the German UI.

Environment / local evidence:

• Platform: macOS, Codex Desktop
• Date observed: 2026-06-03
• Local version metadata currently shows latest_version 0.135.0 (exact About dialog version not checked yet)
• UI symptom: several project folders in the left Projects sidebar show Keine Chats even though their old chats still exist locally.
• This appeared after a Codex update/reindex.

Observed behavior:

• The Projects sidebar shows affected folders with Keine Chats.
• Some direct search queries also fail to find obvious older project terms.
• The affected conversations are still present locally and are non-archived.
• Newer active threads still appear normally.

Read-only local audit:

• ~/.codex/sessions contains 121 rollout JSONL files.
• ~/.codex/session_index.jsonl contains 109 thread entries.
• ~/.codex/state_5.sqlite contains 121 rows in threads.
• The affected thread rows have intact titles, previews, timestamps, cwd values, and archived = 0.
• Example affected project categories include restaurant/app projects, GitHub repo project folders, and an older UTM/Windows project. Exact local paths are omitted for privacy.

This strongly looks like sidebar/project indexing or cwd-to-project mapping drift, not data loss.

Expected behavior:

• If active, non-archived thread rows exist for a project cwd, the project sidebar should not render Keine Chats.
• The app should either perform a project-scoped query/fallback before showing an empty project or offer a safe reindex/recover-project-chats action.

Impact:

The UI makes it look like old project chats disappeared after the update, which is alarming. Local audit shows the chat data is still present, so a non-destructive index repair/recovery path would be very helpful.

Privacy note: I am intentionally not posting full local paths, screenshots, or thread titles that may contain private business context.

I have been using Codex to debug itself. Its report

Subject: Codex Desktop hides older local project chats after restart, even though local data is intact

I am seeing a Codex Desktop bug on Windows where older local chats disappear from their projects in the sidebar after restarting Codex. The affected projects show "No chats", but the chats still exist locally.

Symptoms:

• Project sidebar shows "No chats" for older projects such as SharepointTest and CheckAppStore.
• Ctrl+G search can find some older chats that are not listed in the sidebar.
• Earlier, clicking some search results produced an error.
• Pinning a hidden chat makes it visible globally.
• Unpinning temporarily drops the chat back into the correct project.
• After restarting Codex, the old chats disappear from the project again.
• If I send a real prompt in an old chat, that chat remains visible after restart.

Local data checks:

• codex doctor reported state/log DB integrity ok.
• active rollout files and DB rows matched.
• missing active rows: 0.
• stale rows: 0.
• archive mismatches: 0.
• The affected threads exist in C:\Users\sean_\.codex\state_5.sqlite.
• The affected rows have archived = 0.
• The affected rows have correct cwd values, for example:
• \\?\D:\Source\Codex\SharepointTest
• \\?\D:\Source\Codex\CheckAppStore

Specific test thread IDs:

• SharepointTest: 019d1878-73ac-7943-aaad-83f04c37f337
• CheckAppStore: 019ce49b-dc45-7913-8e6c-5669a24ce3f1

Tests performed:

1. I updated only the updated_at/updated_at_ms values in state_5.sqlite and the updated_at values in session_index.jsonl for those two test chats. This did not make the chats appear under their projects.

1. After a later Codex restart, state_5.sqlite reverted those rows back to their original March timestamps, while session_index.jsonl still had the newer June timestamps. This suggests Codex Desktop is rebuilding state_5.sqlite from another source during startup, probably rollout JSONL history, and not using session_index.jsonl as the source of truth for sidebar rebuild.

1. I noticed visible/recent chats had entries in .codex-global-state.json under electron-persisted-atom-state.heartbeat-thread-permissions-by-id, while the hidden test chats did not. I added matching entries for the hidden test chats. Codex removed those entries on restart.

1. I repeated the global-state test with Codex fully closed. A helper script waited for all Codex processes to exit, waited for .codex-global-state.json to become stable, then added the two missing entries. The log confirmed the entries were added while Codex was closed. After reopening Codex, the projects still showed "No chats", and Codex had removed the entries again.

1. Codex app-level thread search also failed to find these two exact hidden titles even though their rows still existed in state_5.sqlite.

Conclusion:

This appears to be caused by Codex Desktop itself during startup/index rebuild. The user did not archive, delete, or corrupt the chats. Codex is rebuilding or pruning local sidebar/thread state and excluding older active local threads from project sidebar eligibility. Manual edits to state_5.sqlite, session_index.jsonl, and .codex-global-state.json are ignored or overwritten by Codex. A real prompt works because it appends a new event through Codex's normal path.

Requested fix:

Please add or repair a durable local-session reindex path so Codex Desktop scans all active rollout files and active state_5.sqlite threads, honors archived = 0 and cwd matching saved project roots, and shows those chats under the correct project without requiring a new prompt. Ctrl+G search, app-level thread listing, and the project sidebar should agree. Older threads should not be hidden just because they predate newer metadata such as thread_source = user.

And more Details from the Codex Chat. *

Codex Desktop Sidebar Missing Chats: Debug History And Conclusions

Date: 2026-06-04

Summary

Older local Codex chats disappear from their saved project groups in the Codex Desktop sidebar after restarting Codex. The projects show No chats, but the underlying chat data still exists locally. This is not caused by the user archiving or deleting the chats, and it is not caused by missing rollout files.

The strongest conclusion from the tests is that Codex Desktop itself is rebuilding or pruning local sidebar/index state on startup, and that rebuilt state excludes some older active local threads. Manual edits to the local SQLite database, session index, and global desktop state were either ignored or overwritten by Codex on startup. A real user prompt works because it appends a new event through Codex's normal thread path, after which the chat remains visible.

User-Visible Symptoms

Observed sidebar state:

• Projects such as SharepointTest, CheckAppStore, BambuLab, Bugs, NDA Process, SlingShotMU, JourneyLog, and Facebook History Viewer showed No chats.
• Ctrl+G search could find chats from those projects even when the sidebar said No chats.
• Clicking some search results produced an error earlier in the investigation.
• Pinning a hidden chat made it visible in the global Pinned section.
• Unpinning a pinned chat temporarily caused it to return to the correct project.
• After closing projects and restarting Codex, the old chats disappeared from project groups again.
• If a real prompt was entered into one of the old chats, that chat remained visible after restart.

Environment And Local Stores

Observed Codex local data root:

C:\Users\sean_\.codex

Relevant local files and databases:

C:\Users\sean_\.codex\state_5.sqlite
C:\Users\sean_\.codex\session_index.jsonl
C:\Users\sean_\.codex\.codex-global-state.json
C:\Users\sean_\.codex\sessions\
C:\Users\sean_\.codex\archived_sessions\

Earlier codex doctor output showed the local rollout inventory was internally consistent:

active rollouts: 78 files
archived rollouts: 6 files
rollout DB rows: 84
rollout DB active rows: 78
rollout DB archived rows: 6
rollout DB missing active rows: 0
rollout DB missing archived rows: 0
rollout DB stale rows: 0
rollout DB archive mismatches: 0
state DB integrity ok
log DB integrity ok

That means the issue is not that the local session files are missing or that the archive count is wrong.

Important Thread IDs Used In Tests

SharepointTest:

019d1878-73ac-7943-aaad-83f04c37f337

CheckAppStore:

019ce49b-dc45-7913-8e6c-5669a24ce3f1

Both rows existed in state_5.sqlite, had archived = 0, had rollout paths, and had the correct project cwd:

\\?\D:\Source\Codex\SharepointTest
\\?\D:\Source\Codex\CheckAppStore

Test 1: Pin And Unpin Hidden Chats

Action:

• Hidden chats were pinned through Codex's thread-management API.
• The user then unpinned them in the Codex Desktop UI.

Result:

• Pinning made the hidden chats visible globally.
• Unpinning caused the chats to drop back into the correct project.
• This repaired the sidebar temporarily.
• After restarting Codex, the old chats disappeared again.

Conclusion:

• The local data is sufficient for Codex to know the correct project association at least temporarily.
• The sidebar/project grouping state is being lost or recomputed incorrectly on restart.

Test 2: Real Prompt Makes A Chat Stay Visible

Action:

• The user entered a new prompt in an old chat.

Result:

• That chat remained visible after restart.

Conclusion:

• Recency alone is not enough, but a real Codex turn through the normal app path appears to create or refresh additional durable metadata.
• This is why a no-op prompt is a possible temporary workaround, although it changes the chat history.

Test 3: Manually Update Chat Timestamps

Action:

• The user confirmed a backup was done.
• Two low-risk projects were selected: SharepointTest and CheckAppStore.
• Only timestamp fields were changed:
• state_5.sqlite, table threads: updated_at, updated_at_ms
• session_index.jsonl: updated_at
• Creation dates, titles, project paths, archive state, and rollout JSONL files were not changed.

Test timestamp values:

CheckAppStore:   2026-06-03T20:35:00Z
SharepointTest: 2026-06-03T20:36:00Z

Immediate read-back showed both stores had been updated:

state_5.sqlite updated_at_ms:
CheckAppStore   1780518900000
SharepointTest  1780518960000

session_index.jsonl:
CheckAppStore   2026-06-03T20:35:00.0000000Z
SharepointTest  2026-06-03T20:36:00.0000000Z

Result:

• After restart, no chats appeared under those two projects.
• The timestamp update did not make the chats visible.
• Later read-back showed state_5.sqlite had reverted the two test rows back to their March rollout-derived timestamps.
• session_index.jsonl still retained the June timestamps.

Final read-back after Codex startup:

CheckAppStore state_5.sqlite:
updated_at    1773362551
updated_at_ms 1773362551915
UTC time      2026-03-13T00:42:31.915Z

SharepointTest state_5.sqlite:
updated_at    1774234690
updated_at_ms 1774234690180
UTC time      2026-03-23T02:58:10.180Z

Conclusion:

• The sidebar is not controlled simply by state_5.sqlite.updated_at_ms.
• session_index.jsonl is not the source of truth for this startup rebuild.
• Codex Desktop appears to rebuild state_5.sqlite thread metadata from another source, most likely rollout JSONL history, and it overwrote the timestamp edits.

Test 4: Add Missing Desktop Permission Metadata While Codex Was Running

Observation:

• Visible/recent chats had entries in .codex-global-state.json under:

electron-persisted-atom-state.heartbeat-thread-permissions-by-id

• The hidden SharepointTest and CheckAppStore thread IDs did not have entries there.

Action:

• Added entries for both test thread IDs using the same shape as visible HNCT/Bambu threads:

{
  "approvalPolicy": "on-request",
  "approvalsReviewer": "user",
  "sandboxPolicy": {
    "type": "workspaceWrite",
    "writableRoots": [],
    "networkAccess": true,
    "excludeTmpdirEnvVar": false,
    "excludeSlashTmp": false
  }
}

Result:

• Read-back confirmed both entries were present.
• After restarting Codex, the entries were gone.
• The projects still showed no chats.

Conclusion:

• Editing .codex-global-state.json while Codex is running is not durable.
• Codex rewrites or prunes this state on shutdown/startup from its in-memory or rebuilt state.

Test 5: Add Missing Desktop Permission Metadata While Codex Was Fully Closed

Action:

• Created a one-shot helper script:

C:\Users\sean_\Documents\Codex\2026-06-02\how-do-i-reindex-the-local\scripts\patch-codex-sidebar-test.ps1

• The helper waited for all Codex processes to exit.
• It waited until .codex-global-state.json stopped changing.
• It then added the two missing heartbeat-thread-permissions-by-id entries.

Helper log:

2026-06-04 09:25:28 Waiting for Codex processes to exit.
2026-06-04 09:25:50 Codex processes exited. Waiting for state file to become stable.
2026-06-04 09:25:54 Added: CheckAppStore 019ce49b-dc45-7913-8e6c-5669a24ce3f1
2026-06-04 09:25:54 Added: SharepointTest 019d1878-73ac-7943-aaad-83f04c37f337
2026-06-04 09:25:54 Patch complete.

Result:

• After reopening Codex, no chats appeared under the two projects.
• Read-back showed both added global-state entries were removed again by Codex startup.

Conclusion:

• This was not just a "file edited while app was open" problem.
• Codex Desktop startup actively rebuilt or pruned .codex-global-state.json and removed the manually added entries.
• This global-state key is not sufficient to restore the project sidebar.

Test 6: App-Level Thread Search

Action:

• Used Codex app thread search for the exact hidden test titles:

Build SharePoint list viewer app
Build app checking store versions

Result:

• The app-level thread listing returned no matching threads.
• The same thread IDs still existed in state_5.sqlite.

Conclusion:

• The hidden chats are not only missing from the sidebar display.
• They are also excluded from at least one Codex app-level thread listing path.
• This points to a higher-level eligibility/indexing problem, not just a sidebar rendering bug.

Additional Clues

Older hidden threads often have:

thread_source = NULL
cli_version = 0.115.0-alpha.*

Newer visible threads often have:

thread_source = user
cli_version = 0.133.0 or newer

This may be part of the migration/indexing bug, but it is not proven to be the sole cause. Some older BambuLab chats with thread_source = NULL became visible after normal app activity, so the long-term fix should not rely only on this one field.

Conclusions

1. The user did not delete, archive, or corrupt these chats.

1. The local rollout and database inventory was healthy according to codex doctor.

1. The affected threads existed locally, were active (archived = 0), and had correct project cwd values.

1. Pin/unpin temporarily repaired project attachment, proving Codex could still infer the correct project.

1. Restarting Codex caused the repaired project sidebar state to be lost again.

1. Updating timestamps in state_5.sqlite and session_index.jsonl did not restore the sidebar.

1. Codex later reverted the state_5.sqlite timestamp edits while leaving session_index.jsonl unchanged, which indicates Codex Desktop startup is rebuilding SQLite state from another source.

1. Adding missing heartbeat-thread-permissions-by-id entries did not restore the sidebar. Codex removed those entries on startup even when they were added while Codex was fully closed.

1. A real prompt in the old chat works because it goes through Codex's own event path and appends durable new rollout history.

1. The problem appears to be in Codex Desktop's local-session migration, startup reindex, or project-sidebar eligibility logic for older local threads.

Long-Term Fix Requested

Codex Desktop should provide a durable local-session reindex/repair path that:

• scans all active rollout files under C:\Users\sean_\.codex\sessions,
• includes all state_5.sqlite.threads rows where archived = 0,
• honors valid cwd values that match saved project roots,
• does not require a new prompt to make an old active chat eligible,
• does not hide older threads because they lack newer metadata such as thread_source,
• keeps Ctrl+G search, app-level thread listing, and project sidebar eligibility consistent,
• and does not show No chats for projects that have active local threads.

Temporary Workarounds

The least invasive temporary workaround is to open an old chat and send a minimal no-op prompt such as:

Metadata refresh only; no code changes needed.

This uses Codex's normal event path and appears to survive restarts, but it changes the chat history.

Pin/unpin is less durable. It can temporarily reattach hidden chats to projects, but the repair is lost after restarting Codex.

Manual edits to SQLite, session_index.jsonl, or .codex-global-state.json are not reliable because Codex Desktop rewrites or ignores that state during startup.

Thanks everyone for the additional Windows and macOS confirmations.

Based on the reports above, this seems to be broader than only the Projects sidebar rendering "No chats". The affected threads are still present locally, non-archived, and readable through app-server APIs such as thread/list or thread/read, but Codex Desktop may fail to include them in project-scoped listings and may also fail to hydrate/open them from search results.

The common pattern appears to be older local threads, often created by older Codex versions or missing newer metadata, being excluded during startup reindex/migration or from the initial recent-thread cache. A real prompt or fork can make the thread visible again because it goes through the normal app event path, but that is only a workaround and modifies history.

Expected upstream fix:

• project expansion should query threads by cwd with pagination/fallback, not rely only on a global recent window;
• search result navigation should open any readable thread by ID even if it is outside the recent cache;
• startup/local reindex should include all active non-archived local rollout/session threads with valid cwd;
• "No chats" should only be rendered after a project-scoped query confirms there are no active chats.

It would also be helpful to provide a safe "repair/reindex local chats" action so users do not need to edit SQLite/session files or send no-op prompts to recover old project chats.

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.

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.

Windows 10 here: copied-app renderer patch worked; official restart/reindex did not.

I avoided editing .codex data entirely. No SQLite/session_index/global-state/JSONL/mtime/source/thread_source edits, and no recovery bump prompt.

What worked was a side-by-side copied Codex app using the real %USERPROFILE%\.codex, with only the copied renderer bundle patched:

• limit: 50 * recentConversationPageCount -> limit: 5000
• load-more limit: 50 -> limit: 5000

This restored hidden project chats in the patched copy. Reopening the official unpatched Store app loses the fix, as expected, because the official bundle is unchanged.

So for your list: app bundle patch fixed it, specifically a Recent5000 variant. I did not need listAllThreads for this test, though that style of patch also seems conceptually closer to the real product fix.

Caveats: copied app will not auto-update; do not run official and patched app simultaneously against the same .codex; 5000 is a workaround and may be slower for huge histories. Proper upstream fix should be project-scoped pagination/fallback before showing No chats.

On Windows.

I got them back by asking Codex to mark them all as pinned.
But as soon as you unpin them, next load they are gone again.
UNLESS you type something in each one to bring back to being current.

I can confirm the same issue on macOS with an additional workaround signal: pinning a hidden old thread makes it visible and openable.

Environment:

• macOS 15.3.1 (24D70)
• Codex Desktop bundled CLI: codex-cli 0.137.0-alpha.4
• Shell codex --version: codex-cli 0.128.0
• Date observed: 2026-06-08

Observed behavior:

• Older local project threads do not appear in the project sidebar, even after switching sidebar organization to chronological/time order.
• The same threads are also not returned by the app's normal thread search/list path for obvious keywords such as macos, 能编译, or 转油.
• Opening an affected thread with codex://threads/<threadId> routes to a blank thread view.
• The thread data is still intact and readable through the internal thread read path.
• If the same hidden thread is pinned, it appears in the sidebar and can then be opened normally.

Concrete examples from local state, all non-archived:

• 019e6c95-b790-7152-a19b-e16ca75fa517, created 2026-05-28, project cwd under a local codex-taxi checkout, archived = 0
• 019e7841-6f6d-7852-9bcc-33442fe09005, created 2026-05-30, same project, archived = 0
• 019e8907-1a65-7b52-bb50-700bec63fc23, created 2026-06-02, title/preview related to macOS build, same project, archived = 0

Local verification:

• state_5.sqlite.threads contains the affected rows with archived = 0 and the expected cwd.
• ~/.codex/sessions/... rollout JSONL files exist for the affected thread IDs.
• read_thread succeeds for affected threads and returns their turns/messages.
• list_threads search does not find at least some affected old threads by obvious title keywords.
• Direct codex://threads/<threadId> opens a blank view.
• After pinning 019e7841-6f6d-7852-9bcc-33442fe09005, it appears in the sidebar and opens correctly.

Relevant app log clue after opening the pinned/deep-linked thread:

IAB_LIFECYCLE ... conversationId=019e7841-6f6d-7852-9bcc-33442fe09005 ... ownerRoutePath=/local/019e7841-6f6d-7852-9bcc-33442fe09005

This makes it look like the route/thread ID is recognized, but the Desktop UI does not hydrate/render older unpinned threads unless they are forced into the sidebar cache by pinning.

Expected behavior:

• Non-archived local threads with valid rollout files and valid cwd should be discoverable in project sidebar/search.
• Opening a thread by ID should render it if thread/read can read it, even if it is outside the current recent-thread/sidebar cache.
• Pinning should not be required to recover/open old local project threads.

Workaround confirmed:

• Pinning a hidden thread makes it visible and openable. This does not appear to be a data-loss issue.

I am still hitting this on macOS with a newer Codex Desktop build.

Environment:

• Codex Desktop: 26.602.40724 (CFBundleVersion 3593)
• macOS: 26.4.1 (25E253)
• Architecture: arm64
• Storage: local ~/.codex/state_5.sqlite, ~/.codex/sessions, ~/.codex/archived_sessions

Observed behavior:

• The Codex Desktop sidebar only shows a recent subset of conversations.
• Switching the sidebar organization/filter to chronological did not make older conversations appear.
• Older conversations are not deleted. They still exist locally and can be found in SQLite/session files.

Local evidence from this machine:

state_5.sqlite threads total: 257
active / unarchived threads: 148
archived threads: 109
oldest updated_at in SQLite: 2026-02-07 17:20:52
newest updated_at in SQLite: 2026-06-08 03:54:33

session files under ~/.codex/sessions + ~/.codex/archived_sessions: 257
session files older than 7 days: 228

session_index.jsonl lines: 211

active threads in top 50 by updated_at: 50
active threads outside top 50 by updated_at: 98

This strongly matches the suspected recent-window/sidebar hydration problem. Even after archiving some old threads, there are still many active threads outside the first 50 recent items, and the app UI does not provide a reliable way to load/show the full project history.

I also checked the current app bundle for this build. The relevant code path still appears to exist in the webview bundle:

/Applications/Codex.app/Contents/Resources/app.asar
  webview/assets/app-server-manager-signals-SKi6YePu.js

That chunk still contains runRecentConversationRefresh / listRecentThreads(...) logic. This seems consistent with earlier reports that the Desktop sidebar initializes from a bounded recent thread list instead of loading all local project threads or paging until the full relevant project history is available.

Impact:

• This makes the Desktop app very hard to use for long-running projects or users with many conversations.
• The local data is intact, but the app UI makes older conversations effectively undiscoverable.
• Workarounds like archiving unrelated recent threads, manually refreshing updated_at, or patching app.asar are not acceptable long-term fixes.

Requested fix:

• Make project/sidebar history load all relevant local threads, or page until exhausted, instead of depending on the first global recent-thread window.
• Make sidebar search cover all local threads, not only already hydrated recent threads.
• Provide a supported "rebuild/reindex local sidebar history" command from durable local state (state_5.sqlite + sessions/**/*.jsonl), so users do not need to manually edit SQLite/global state or patch the app bundle.

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. Pinning/forcing recency may still be useful as a workaround, but I do not see full historical project recovery yet.

Update from Windows as of June 15, 2026:

• Codex Desktop: 26.609.4994.0
• The projects that previously showed No chats now display their older non-archived conversations normally.
• I can no longer reproduce the original issue.

I also verified that this is no longer explained by my earlier local workaround. Some affected conversations have again fallen outside the first 100 non-archived threads by updated_at:

• ncds-api-backend: its only thread is currently around position 113
• ncds-base-backend: its four threads are around positions 105–115
• ncds-police-backend: threads extend to around position 120

Despite this, the projects are still displaying their conversations correctly. This suggests that the newer Windows build now performs project-scoped loading, pagination, or an equivalent fallback instead of relying only on the initial recent-thread window.

So, on Windows 26.609.4994.0, this appears to be fixed. However, since there is still a report of only partial recovery on macOS 26.608.12217, I will leave the issue open for maintainer confirmation and additional cross-platform verification.