Codex Desktop macOS hides unarchived local threads even when they are inside the recent-50 window

[Poke-nushi]

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop macOS app bundle:

CFBundleShortVersionString: 26.506.31421
CFBundleVersion: 2620

What subscription do you have?

ChatGPT Pro

What platform is your computer?

macOS 26.3.1 (a)
BuildVersion: 25D771280a
arch: arm64

What issue are you seeing?

Several Codex Desktop conversations disappeared from the app UI and are not discoverable through the in-app search, even though the local SQLite state and rollout JSONL files are still present.

This does not look like data loss. It looks like a Desktop thread list / project sidebar / search indexing problem.

Important difference from the recent-50 reports: at least two affected direct, unarchived threads are still inside the global recent-50 window. They are not older rank-51+ conversations.

Local evidence, with private paths and titles redacted:

~/.codex/state_5.sqlite PRAGMA integrity_check: ok
threads total: 836
active threads: 622
archived threads: 214
active direct/non-subagent threads: 400
~/.codex/sessions JSONL files: 856
~/.codex/archived_sessions JSONL files: 205
~/.codex/session_index.jsonl lines: 448

The affected project has active local rows:

affected project active direct threads: 3
project best global rank among active direct threads: 1

Two missing affected threads are ranked inside the global recent direct-thread list:

thread A global_rank: 33, archived=0, rollout_path exists, title_len=90
thread B global_rank: 36, archived=0, rollout_path exists, title_len=93

Despite that, the user could not find those threads in Codex Desktop by searching for:

• a custom renamed thread name
• a unique word from the original title/body
• a unique URL substring from the original first user message
• the thread id prefix

There is also a rename/index inconsistency for one affected thread:

~/.codex/session_index.jsonl contains two entries for the same thread id:
  old generated name
  later custom renamed name

state_5.sqlite threads.title for that same id still contains the original first user message, not the later custom renamed name.

The custom renamed name exists on disk in session_index.jsonl, but searching for that renamed name in the Desktop app does not find the thread.

The global state also shows the affected project path under sidebar-collapsed-groups, but that alone should not make active threads unsearchable:

.codex-global-state.json electron-persisted-atom-state.sidebar-collapsed-groups[<affected cwd>] = true

Metadata size / adjacent symptoms

This machine also has unbounded metadata symptoms that may be related to existing reports:

all threads: 836
threads with title > 200 chars: 211
threads with title > 1000 chars: 61
threads with title > 10000 chars: 16
max title length: 33075
avg title length: 605.5

active threads: 622
active threads with title > 200 chars: 190
active threads with title > 1000 chars: 52
active threads with title > 10000 chars: 16
max active title length: 33075
avg active title length: 738.8

However, the two missing affected threads themselves have short titles and are still ranked 33/36 globally, so title bloat and recent-50 may be adjacent but do not fully explain this case.

What steps can reproduce the bug?

I do not have a synthetic repro yet. The observed sequence was:

1. Use Codex Desktop on macOS across many projects and threads.
2. Rename at least one thread using the Desktop/app rename UI.
3. Later open Codex Desktop and inspect the project sidebar / chat search.
4. Observe that several historical conversations appear missing.
5. Search for a renamed thread title, original title/body words, URL substring, and thread id prefix.
6. Observe no result in the Desktop UI.
7. Inspect local state:
   • state_5.sqlite integrity check passes.
   • affected rows are archived=0.
   • affected rollout JSONL files exist under ~/.codex/sessions.
   • affected entries exist in session_index.jsonl.
   • affected direct threads are still inside the global recent-50 list.

What is the expected behavior?

• Active local threads should remain visible in the project sidebar and searchable if their SQLite rows and rollout files exist.
• Search should query all persisted local threads, or at minimum all active direct threads in the selected project, not only a stale UI subset.
• A custom thread name set through the UI should be persisted consistently across the sources Desktop uses for listing/searching.
• A collapsed project group should not make the project’s active threads disappear from global search.
• Desktop should provide a safe reindex/repair path for local history when SQLite/session JSONL data is intact.

Additional information

Related issues that look adjacent:

• Codex Desktop macOS project sidebar hides unarchived local threads even though SQLite/session files are intact #20608
• Codex Desktop project chat histories disappeared after recent update #20741
• Codex Desktop sidebar loses chat history when thread titles contain large transcript chunks #21119
• Codex Desktop silently hides project conversations outside the global recent-50 window #21128
• Thread navigation/loading slows from unbounded metadata and eager large-history hydration #21211

I made a local backup before doing any repair attempts and did not mutate the live Codex history database while collecting the above diagnostics.

[Poke-nushi]

Additional observation after filing this issue:

After archiving many unrelated active conversations in Codex Desktop, previously hidden affected conversations became visible again in the UI. The affected thread rows themselves remained archived=0.

Local state after the archiving workaround:

active threads: 576
archived threads: 261
affected project: active 4, archived 3

The two affected thread IDs I checked are still unarchived and still have existing rollout paths in ~/.codex/sessions.

This strongly suggests the Desktop UI/search is operating on a bounded, stale, or otherwise incomplete loaded subset of active conversations. Archiving unrelated conversations appears to change which still-active threads become visible, so the local data was not deleted.