Mac app stops showing local threads even though local thread data still exists #16095

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Mar 28, 2026
2. github-actions commented on Mar 28, 2026

   

   github-actionsbot

   on Mar 28, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex Desktop hides existing workspace threads on macOS #14370
   • Sidebar only shows the 50 most recent threads, making older threads inaccessible #15060
   • Desktop app sidebar only shows loaded recent subset, not full workspace history #14751
   • Threads randomly disappear from history without deletion (possible sync/cache issue) #15406
   • threads missing at every single start of codex for windows #15052

   Powered by Codex Action
3. neddes commented on Mar 28, 2026

   

   neddes

   on Mar 28, 2026 – with ChatGPT Codex Connector

   Last edited by neddes

   Author

   More actions

   Additional evidence from local investigation on macOS 26.325.31654:

   • The local backend is healthy. Querying the same local app-server the Desktop app uses returns the missing threads via thread/list, including workspace-scoped results and previously missing threads.
   • That means ~/.codex/state_5.sqlite and ~/.codex/sessions are not the failing layer here.

   I also found a request shape that reproduces the exact empty-sidebar symptom on my local data:

   • thread/list(..., cwd="<active-workspace-cwd>", sourceKinds=["cli"]) => empty result
   • thread/list(..., cwd="<active-workspace-cwd>", sourceKinds=["vscode"]) => expected missing threads appear immediately

   Relevant local data shape:

   • active threads by source: vscode=1130, exec=40
   • active threads with empty first_user_message: 0
   • active threads with null cwd: 0
   • active threads by provider: openai=1170

   Additional client-state observation:

   • .codex-global-state.json keeps reverting to a populated selected-remote-host-id and codexCloudAccess=enabled even after resetting it to local-only.

   Recovery steps already tried with no fix:

   • rebuild session_index.jsonl and state_5.sqlite
   • clear Local Storage and Session Storage
   • clear the broader app container under ~/Library/Application Support/Codex
   • force local-only global state
   • normalize thread titles and recreate session_index.jsonl
   • rewrite updated_at

   So this now looks like a Desktop client-side history request/rendering bug. The app-server can list the threads correctly; the Mac client is either not issuing the right thread/list request or is rendering from the wrong request/state.

   This seems closest to #14370 and possibly related to #15406. It does not look identical to the recent-subset / pagination variant in #14751 / #15060, because even very recent workspace threads are absent here and the cli vs vscode source filter reproduces the empty state exactly.
4. linear

   closed this as duplicateon Apr 2, 2026
5. yahuo commented on Apr 8, 2026

   

   yahuo

   on Apr 8, 2026 – with ChatGPT Codex Connector

   More actions

   Additional evidence from a second macOS machine. This still looks like a Desktop sidebar / renderer bug, not local thread loss.

   Environment

   • Codex Desktop: 26.325.31654 (1272)
   • CLI / app-server on this machine: 0.118.0-alpha.2
   • macOS: 26.3.1 (25D771280a) on arm64

   Observed symptom

   • In project view for /Users/jinxin/Applications/OpenSource/claude-code, the left sidebar shows only the current thread under that project.
   • Full app restart does not restore the missing local threads.

   Verified local data is intact

   • ~/.codex/state_5.sqlite has 12 unarchived threads for that exact cwd.
   • All 12 are source='vscode'.
   • The corresponding rollout files still exist under ~/.codex/sessions/....

   Verified backend / app-server is healthy

   • Querying the same local app-server binary the Desktop app ships with returns the missing threads correctly via thread/list for that exact cwd.
   • On this machine, all of the following return the expected 12 rows for the active workspace:
     • thread/list({cwd=..., archived=false})
     • thread/list({cwd=..., archived=false, sourceKinds=[]})
     • thread/list({cwd=..., archived=false, sourceKinds=null})
     • thread/list({cwd=..., archived=false, sourceKinds=["vscode"]})
   • So this is not caused by state_5.sqlite, rollout-file loss, or sourceKinds=[] by itself.

   Verified it is not the symlink / path-mismatch case

   • realpath(/Users/jinxin/Applications/OpenSource/claude-code) matches the opened workspace path exactly.
   • This does not look like the symlinked-workspace mismatch variant.

   Verified it is not just a hidden sidebar filter

   • Persisted sidebar state on this machine is:
     • sidebar-workspace-filter-v2 = all
     • sidebar-organize-mode-v1 = project
   • So the UI is not intentionally set to a restrictive per-branch / relevant-only mode here.

   Most suspicious renderer path so far

   • The Electron sidebar path is using the recent-conversations-meta query / hook layer in the renderer, not reading SQLite directly.
   • In the current bundle, that hook seeds the React query cache from Bg(...) (current in-memory manager state) and then separately kicks an async refresh via Hg(...).
   • If the manager initially only has the currently open thread hydrated, the query cache starts with a 1-thread list. Given the observed symptom, it looks plausible that the follow-up refresh result is not being written back into the same query cache path reliably for this sidebar view, leaving the UI stuck showing only the current thread even though thread/list returns the full set.

   Local test patch candidate (lead, not confirmed root cause yet)

   • I produced a local renderer hotfix candidate by changing that bootstrap path to call Vg(...).then(setQueryData(...)) instead of only seeding from Bg(...) and fire-and-forget Hg(...).
   • I have not yet validated that patch end-to-end, so treat this as a debugging lead rather than a confirmed fix.

   Net conclusion

   • The failure layer appears to be Desktop client-side sidebar hydration / rendering for local project threads.
   • On this machine, the local backend can enumerate the missing threads correctly; the sidebar is not reflecting them.