Repository navigation
Codex Desktop sidebar loses chat history when thread titles contain large transcript chunks #21119
Description
What is the issue?
Codex Desktop suddenly stopped showing most chat history in the left sidebar. The chats are still recoverable through Search, and pinning a searched chat makes it appear again, so this does not appear to be data loss. It looks like the sidebar thread list rendering/query path fails or drops most items while search still indexes them.
Environment
- OS: Windows
- Codex Desktop package:
OpenAI.Codex - Codex Desktop version:
26.429.3425.0 - Store package family:
OpenAI.Codex_2p2nqsd0c76g0
Observed behavior
- Sidebar
Chatssection only shows one recent thread. - Existing chats are still discoverable via Search.
- Pinning a found chat restores it under
Pinned. - SQLite integrity check passes and session files are still present.
Local diagnostics
The local thread store appears healthy:
DB: %USERPROFILE%\.codex\state_5.sqlite
PRAGMA integrity_check: ok
threads total: 125
active threads: 110
archived threads: 15
session JSONL files on disk: 121
However, many threads.title and threads.first_user_message values are extremely large. These look like transcript chunks rather than sidebar-safe titles.
active threads where length(title) > 200: 62
active threads where length(title) > 1000: 56
active threads where length(title) > 10000: 21
max length(title): 79452
avg length(title): 8732.992
Example shape, redacted:
id: <thread-id>
title_len: 79452
title_preview: "<normal user opening text> [165] user: # In app browser: ..."
The global state still has pinned thread IDs in %USERPROFILE%\.codex\.codex-global-state.json under electron-persisted-atom-state.pinned-thread-ids.
Relevant logs
Startup logs show thread/list returning successfully, which matches search/history still existing:
method=thread/list ... errorCode=null ... durationMs=186
There are also slow startup/config/plugin calls around ~60 seconds and many Git probe warnings, but the key sidebar-specific clue seems to be the huge thread metadata.
Hypothesis
threads.title / first_user_message can become populated with large transcript/browser/comment/approval-history payloads. The search path can still find threads, but the sidebar list renderer or thread/list consumer appears to fail, truncate incorrectly, or silently omit most rows when many active threads have very large titles.
Workaround
Closing Codex, backing up %USERPROFILE%\.codex\state_5.sqlite*, then truncating oversized threads.title / first_user_message metadata should restore sidebar list behavior without deleting session JSONL history.
I have not attached raw DB rows because they include private chat/project contents.
Expected behavior
The sidebar should continue listing active chats even if title generation or first-message metadata becomes very large. Ideally titles should be capped/sanitized before persistence, and thread/list/sidebar rendering should defensively truncate display fields.
Activity
github-actions commentedon May 5, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Donkodio commentedon May 31, 2026
I hit a very similar Codex Desktop sidebar/indexing failure on macOS.
In my case, project pages showed "No chats", but local data still existed in
~/.codex/state_5.sqliteand SQLite integrity was OK. The key clue was that pinned chats were still visible, which suggested this was not data loss but a sidebar/project index problem.The practical workaround was:
thread-workspace-root-hintsfrom the localthreads.cwddata;pinned-thread-idsas a visibility fallback;I published a sanitized unofficial helper here:
https://github.com/Donkodio/codex-desktop-sidebar-recovery
It does not upload data and defaults to dry-run. I am not sharing raw session files, tokens,
.envfiles, private keys, Telegram sessions, proxy credentials, or private chat dumps.grnbtqdbyx-create commentedon May 31, 2026
roccodaffuso commentedon Jun 4, 2026
My local instance is currently working again, so I am not asking for recovery help. I am adding redacted diagnostics because this previously reproduced on my machine and seems relevant to the broader sidebar/project discovery bug.
I am seeing the same class of Codex Desktop sidebar/project history issue on macOS.
The important detail is that local data does not appear to be lost. Existing conversations and rollout files are still present locally, but the Desktop sidebar/project view can show "No chats" or hide valid project conversations.
Local diagnostics, redacted:
com.openai.codex26.601.213173511~/.codex/state_5.sqlitePRAGMA integrity_check:okthreads:22467224length(title) > 200:162length(title) > 1000:155length(title):5852In my case, this issue was also likely amplified by recurring/heartbeat automation threads:
This looks like a sidebar/project discovery/indexing bug rather than data loss. It may overlap with the oversized-title metadata issue, but the automation/service-thread angle also matters because it can greatly increase thread volume and make the UI state drift more visible.
Suggested fixes:
thread/listfor that cwd returns rows.threads.titleandfirst_user_messagemetadata should be capped/sanitized before persistence.I am intentionally not attaching raw DB rows, logs, or session files because they contain private conversation/project data.