Codex macOS app project sidebar can hide existing local project chats after restart/cache drift while SQLite thread records remain intact
Summary
The Codex macOS app sidebar/project view showed several saved projects as having no chats or missing chats, even though the local Codex SQLite state still contained active, non-archived thread rows for those project roots.
The issue appeared around 2026-05-30/31 and persisted after a normal app restart. A local UI cache reset restored some project visibility, but additional drift remained between:
- saved workspace roots in
.codex-global-state.json; - thread
cwdroots instate_5.sqlite; - what the app sidebar/search showed under projects.
No message/thread data appeared to be deleted. The problem looked like project sidebar/index visibility drift.
Environment
- App: Codex Desktop for macOS
- Version:
26.527.31326 - Build:
3390 - macOS: iMac local install
- Local Codex state files involved:
~/.codex/.codex-global-state.json~/.codex/state_5.sqlite
Observed Behavior
- Several project folders in the Codex sidebar showed
No chatsor omitted known project chats. - Affected chats were still present in local SQLite:
threads.cwdmatched the expected project root;archived = 0;- titles/previews/timestamps were intact.
- Some projects became visible again after a local UI cache reset.
- Other threads were still only discoverable via local thread inventory, not reliably via saved project/sidebar grouping.
- Creating visible recovery anchor threads helped the sidebar show certain projects again, which suggests an index/display-layer issue rather than missing data.
Expected Behavior
If a saved workspace/project root has active, non-archived local threads whose cwd is that root, the sidebar/project view should reliably show those chats after restart.
If a root has local active threads but is not currently a saved project root, the app should either:
- show the root in a recoverable/local roots section;
- offer to re-add it as a project;
- or surface a clear warning rather than making the sessions look missing.
Evidence From Local Audit
Local read-only audit found:
- 17 saved project roots.
- 24 local roots with Codex thread records.
- 199 active local threads.
- 109 archived local threads.
- 7 active local roots were not saved project roots.
Examples of unsaved local roots with active threads:
~/Claude/codex/projects~/Claude/analytics~/Claude/upwork-bid-tracker~/Documents/Calendar Admin- several historical
~/Documents/Codex/...roots
Examples of saved project roots where recovery anchors were needed or visibility was inconsistent:
- Happy Wood Stoves
- LinkedIn Outreach
- Instantly
- BoxLeague Pro
- Calendar Admin
- RippleKeep
Recovery Steps Tried
- Normal Codex restart: did not fully resolve.
- Local state backup created.
- UI/sidebar cache reset: restored several project folders/chats.
- Recovery anchor threads created under affected project roots to force visible project entries.
- Built a read-only local monitor comparing saved project roots against
threads.cwdroots to detect future drift.
Impact
The issue makes it look like project chats have disappeared, even though the data is still present locally. This creates a high-risk UX failure for users managing many project-scoped Codex sessions, because they may assume important work has been lost.
Suggested Fix / Product Behavior
Potential improvements:
- On startup, reconcile saved workspace roots with local
threads.cwdroots. - Surface active local roots that are not saved project roots.
- Add a “recover project chats” or “show local roots with sessions” option.
- Add a sidebar/index repair command that does not require manual SQLite/cache inspection.
- Avoid showing
No chatsfor a saved root when active local thread rows exist for thatcwd.
Privacy Note
This report is sanitized. Full local logs/state can be provided privately if requested, but should not be posted publicly because paths and thread titles may contain private business context.
---
Submitted from a sanitized local incident report with user approval.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗