Codex Desktop project sidebar and search omit older notLoaded local project threads

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

• #25463
• #25574
• #26157
• #25761
• #26031

Powered by Codex Action

Hi everyone, I'm tracking the same Codex Desktop missing-thread/sidebar-history issue on macOS.

For those affected here: did you eventually get all hidden project threads back in Desktop? If yes, what exact method worked durably for you?

Examples I'm trying to distinguish:

• official update fixed it
• restart/reindex fixed it
• codex resume --all <thread-id> rehydrated it
• repairing session_index.jsonl / state_5.sqlite / .codex-global-state.json fixed it
• Codex Wake or another local recovery helper fixed it
• app bundle / listAllThreads patch fixed it
• nothing worked yet

In my case, the missing project threads still exist in ~/.codex/sessions and state_5.sqlite, but Desktop does not hydrate them back into the project sidebar after restart. Any confirmed durable fix would help. Please do not share private session contents; sanitized method/results are enough.

Adding another macOS data point that looks like the same underlying Desktop sidebar/search history issue, with one narrower detail: affected older source='cli' threads are readable by thread ID but are omitted from Desktop search/listing.

Environment:

• Codex Desktop: 26.602.30954 (CFBundleVersion 3575)
• Codex CLI: codex-cli 0.135.0
• Platform: macOS 26.5.1 (25F80)
• Local storage involved: ~/.codex/state_5.sqlite, ~/.codex/sessions

Observed behavior:

• A historical thread is not visible under the ~/ project group in the Desktop sidebar.
• Searching Desktop/App thread search for text from that thread can surface a stale-looking result, but opening it fails or does not hydrate the thread.
• The thread is also omitted from list_threads(query=...) for exact title/content keywords.
• read_thread(threadId=...) succeeds and returns the full thread content.
• Other older source='cli' threads under the same cwd show the same search omission pattern.

Concrete local evidence:

thread_id: 019e681e-0d44-7580-ad01-df59616096b6
title: codex如何开启fast模式？
source: cli
thread_source: user
cwd: /Users/<user>
archived: 0
created_at local: 2026-05-27 14:27:40
updated_at local: 2026-05-27 14:50:02

The local SQLite row exists and is active:

SELECT id, title, source, thread_source, cwd, archived
FROM threads
WHERE id = '019e681e-0d44-7580-ad01-df59616096b6';

returns:

019e681e-0d44-7580-ad01-df59616096b6 | codex如何开启fast模式？ | cli | user | /Users/<user> | 0

For the same cwd, local state contains active threads from multiple sources:

active threads for cwd=/Users/<user>: 74
source breakdown:
cli: 26
vscode: 17
exec: 11
subagent/guardian: 20

The rollout JSONL is still present and readable. In this profile, ~/.codex/sessions was moved to ~/personal/sessions with a symlink left at the original path:

~/.codex/sessions -> ~/personal/sessions

The old rollout_path still works through the symlink, and the file exists:

~/.codex/sessions/2026/05/27/rollout-2026-05-27T14-27-40-019e681e-0d44-7580-ad01-df59616096b6.jsonl

So this does not appear to be simple file loss or a broken rollout path. The data is still present in SQLite and on disk, and direct thread-id reading works. The failure appears to be in Desktop/sidebar/search hydration or indexing for older local CLI-originated threads.

Expected behavior:

• Desktop sidebar/search should be able to discover active local source='cli' threads when they exist in state_5.sqlite and the referenced rollout JSONL file is readable.
• If ~/.codex/sessions is a valid symlink, Desktop should either follow it or show a diagnostic if symlinked session storage is unsupported.
• Search results should not point to a thread that cannot be opened/hydrated.

This may be the same broad project/sidebar recent-window issue described here, but the source='cli' + symlinked ~/.codex/sessions detail may help narrow the Desktop index/hydration path.

Adding a macOS datapoint after updating to the latest Desktop build.

Environment:

• macOS 15.5 (24F74)
• Apple Silicon / arm64
• Codex Desktop: 26.608.12217
• CFBundleVersion: 3722
• Local storage: default ~/.codex

Recovery status on my affected project:

• The update appears to have restored some previously missing threads.
• It did not restore everything.
• Older project threads are still missing from the Desktop sidebar/project history.
• The local data still appears to exist. For the affected project, state_5.sqlite still has 251 active/non-archived rows with the expected project cwd.
• Earlier checks also confirmed matching rollout JSONL/session files under ~/.codex/sessions.

So my current result is: 26.608.12217 looks like a partial recovery, not a full recovery. It would still be very helpful to have an official full local reindex/recovery command that rebuilds sidebar/project history from durable local state.

I’m seeing a related issue on Codex Desktop for macOS.

Environment:

• Codex Desktop / bundled CLI: 0.138.0-alpha.7
• macOS: 26.3.1
• Project: private local repo, name/path redacted

Observed:

• Project sidebar shows only 3 conversations for one private project.
• Global Search can still find additional conversations from the same project.
• Local state does not look corrupted:
• codex doctor --summary reports thread inventory OK.
• rollout files and state DB thread inventory agree.
• no missing/stale rows reported.
• Local DB has hundreds of active, non-archived thread rows for the redacted project cwd.
• This is not simply “latest N”, because the sidebar includes an older thread while newer active project threads are omitted.

Expected:
The project sidebar should either show active project conversations consistently, or clearly expose the filter/pagination/“show full history” behavior that explains why Search and sidebar differ.

Privacy note:
Project name, path, thread titles, and screenshots are redacted because this is a private repository.

Adding a current-build macOS datapoint that matches this issue.

Environment:

• Codex Desktop: 26.611.62324
• CFBundleVersion: 4028
• macOS, local storage under ~/.codex

Observed:

• A known local thread is not discoverable through Codex Desktop/thread search/listing, while terminal/raw JSONL access works.
• codex_app.read_thread(threadId="019ed1c0-ca44-7472-b527-8e271f0e6f4e") succeeds and returns the thread.
• codex_app.list_threads(query="019ed1c0-ca44-7472-b527-8e271f0e6f4e") returns [].
• codex_app.list_threads(query="<unique title/content terms>") also returns [].
• The row exists in ~/.codex/state_5.sqlite with archived=0, source="vscode", thread_source="user", and cwd=/Users/<user>.
• The backing rollout JSONL exists under ~/.codex/sessions/2026/06/16/...019ed1c0...jsonl.

I also tried opening codex://threads/019ed1c0-ca44-7472-b527-8e271f0e6f4e; macOS accepted the deeplink, but the reliable evidence here is the search/list mismatch above.

Expected: direct app search/list should surface a known active local thread by exact thread id and/or content/title terms when read_thread can hydrate it.

Reproduced again on the unified ChatGPT/Codex macOS app.

Environment

• App: ChatGPT/Codex 26.707.41301 (build 5103)
• macOS 26.4.1 (build 25E253)
• Apple Silicon (arm64)
• Reproduced: 2026-07-12

Reproduction

1. Locate an older local thread:

• thread id: 019ec03b-3dd2-7210-9734-8ccb13636136
• title: 筛选高星 SaaS 模板
• status: notLoaded
• non-archived
• older than the global recent-50 window

1. Call:

``json
{"threadId":"019ec03b-3dd2-7210-9734-8ccb13636136","pinned":true}
``

1. codex_app.set_thread_pinned returns:

``json
{"threadId":"019ec03b-3dd2-7210-9734-8ccb13636136","pinned":true}
``

1. The sidebar's Pinned section still renders only the previously pinned thread; the target thread is absent.
2. Navigating directly to the target thread, then toggling pinned: false and pinned: true, also returns success.

Persistence evidence

The action is persisted successfully. ~/.codex/.codex-global-state.json contains two pinned thread IDs, including the missing target:

{
  "pin_count": 2,
  "target_present": true,
  "pinned_ids": [
    "019f51c0-624e-7412-becb-608193d96e63",
    "019ec03b-3dd2-7210-9734-8ccb13636136"
  ]
}

However, the UI shows only the first pinned item.

This narrows the failure to sidebar hydration/rendering for older notLoaded threads rather than the pin mutation or persistence layer. A pinned thread should be loaded and rendered even when it is outside the recent-50 window.

Adding a Windows datapoint that also reproduces for a projectless local thread, so this is not limited to project/cwd grouping.

Environment

• Codex Desktop: 26.707.72221
• Bundled CLI recorded by the thread: 0.144.2
• Windows: 10.0.26200.0
• Reproduced: 2026-07-16
• Default local storage under %USERPROFILE%\.codex

Projectless reproduction

The affected thread was created as a projectless Desktop task and is explicitly present in the persisted projectless-thread-ids state. Its output directory is under the normal Documents\Codex\<date>\... location.

Local evidence:

• backing rollout JSONL exists and is readable;
• session_index.jsonl contains the thread;
• state_5.sqlite contains the thread with:
• archived = 0
• source = "vscode"
• thread_source = "user"
• cli_version = "0.144.2"
• read_thread(threadId=...) succeeds, returns the title/turns, and reports status.type = "notLoaded";
• list_threads() omits it;
• list_threads(query="<exact thread id>") returns [];
• list_threads(query="<exact title terms>") returns [];
• set_thread_pinned(true) returns success;
• direct navigate_to_codex_page(threadId=...) succeeds;
• the normal list/search path still does not enumerate the thread.

The same restart also hid a project-associated local thread, but the projectless case is the useful discriminator: the failure persists without any saved-project root matching or Unicode project-path dependency.

This narrows the likely fault to Desktop/app-server history enumeration or hydration for local notLoaded threads (and possibly pinned rendering), rather than missing rollout data or project sidebar grouping alone. There were only a few local user threads in this new installation, so this case is also unlikely to be explained by an older-than-recent-50 cutoff.

Privacy note: no raw conversations, full local paths, logs, or secrets are attached.