›_ Codex Issues
Codex Issues / #21119

Codex Desktop sidebar loses chat history when thread titles contain large transcript chunks

Open 💬 4 comments Opened May 5, 2026 by ywkuno
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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 Chats section 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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 3 months ago

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

  • #19873
  • #20254
  • #21076
  • #20833
  • #20419

Powered by Codex Action

Donkodio · 2 months ago

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.sqlite and 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:

  • rebuild thread-workspace-root-hints from the local threads.cwd data;
  • rebuild sidebar project/chat ordering;
  • use pinned-thread-ids as a visibility fallback;
  • archive service automation/subagent threads to reduce sidebar noise.

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, .env files, private keys, Telegram sessions, proxy credentials, or private chat dumps.

grnbtqdbyx-create · 2 months ago

I added a privacy-safe evidence path for the specific "large transcript chunks in thread titles" version of this failure in trace-to-skill@0.1.76:

npx trace-to-skill@0.1.76 session-audit ~/.codex --format json

Scope note: it does not repair or mutate Codex state. It only summarizes local metadata so users can avoid posting raw transcripts, SQLite files, or full local paths.

New in this version, session-audit flags bloated_index_title when session_index.jsonl titles look like long transcript/log/attachment chunks. The report includes title byte count and coarse signals such as long_title, transcript_marker, and attachment_or_log_chunk, while still keeping the existing recoverable codex resume <thread_id> commands and hashed project grouping.

Release/proof: https://github.com/grnbtqdbyx-create/trace-to-skill/releases/tag/v0.1.76
Schema: https://github.com/grnbtqdbyx-create/trace-to-skill/blob/main/schemas/session-audit-result.schema.json

roccodaffuso · 2 months ago

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:

  • OS: macOS 26.3.1, build 25D2128
  • Codex Desktop bundle id: com.openai.codex
  • Codex Desktop version: 26.601.21317
  • Codex Desktop build: 3511
  • Local DB: ~/.codex/state_5.sqlite
  • SQLite PRAGMA integrity_check: ok
  • Total threads in threads: 224
  • Active/unarchived threads: 67
  • Session rollout JSONL files found locally: 224
  • Threads with length(title) > 200: 162
  • Threads with length(title) > 1000: 155
  • Max observed length(title): 5852

In my case, this issue was also likely amplified by recurring/heartbeat automation threads:

  • A recurring automation previously spawned standalone review/service threads.
  • Project chats became difficult to discover in the sidebar even though the underlying local data remained present.
  • I paused the recurring automation and moved the workflow to a single persistent runner thread to reduce sidebar/thread volume.
  • Current local automation state: the standalone cron automation is paused, while one heartbeat runner thread remains active.

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:

  • Project expansion should query all local unarchived threads for that workspace root, not rely only on the global recent thread list.
  • The UI should not show "No chats" if local thread/list for that cwd returns rows.
  • Service/automation/heartbeat threads should be separately classified, collapsed, or hidden from normal project chat ordering.
  • threads.title and first_user_message metadata should be capped/sanitized before persistence.
  • Sidebar rendering should defensively truncate display fields and avoid silently dropping rows when metadata is large.
  • Codex Desktop should provide a safe "repair/rebuild local chat index" action.

I am intentionally not attaching raw DB rows, logs, or session files because they contain private conversation/project data.