Codex Desktop project sidebar shows empty even when threads have matching cwd

Summary

Codex Desktop does not show existing conversations under a pinned local project, even though the conversations have the exact same cwd as the project root in the local thread database and are not archived.

The project appears in the left sidebar, but expanding/selecting it shows No conversations / 暂无对话.

Environment

• Codex Desktop version: 26.513.31313
• Codex build number: 2867
• OS: macOS 26.4.1 (25E253)
• Host/source observed in local DB: vscode

Reproduction / observed flow

1. Open Codex Desktop on macOS.
2. Work inside a local project folder, for example: /Users/<user>/Documents/Codex/2026-05-20/novel-animation-pitch-workflow
3. Pin or view that project in the left sidebar.
4. Start/resume conversations whose cwd is exactly that project root.
5. Restart Codex Desktop.
6. The pinned project still shows 暂无对话 / no conversations.

Expected behavior

Conversations whose cwd exactly matches a local project root should appear under that project in the sidebar.

Actual behavior

The sidebar project remains empty even though local thread state shows matching, live conversations.

Diagnostics already checked

Local SQLite thread state contains multiple non-archived conversations with the correct cwd, including the current thread:

conversation id: 019e4331-04a6-7102-9f8a-a408424db022
title: 怎么不能把对话放到对应的项目里啊？
cwd: /Users/<user>/Documents/Codex/2026-05-20/novel-animation-pitch-workflow
source: vscode
thread_source: user
archived: 0

Other live conversations in the same project root also have archived: 0 and the exact same cwd.

I also verified that ~/.codex/.codex-global-state.json contains persisted workspace-root hints under:

electron-persisted-atom-state.thread-workspace-root-hints

Those mappings point the affected conversation ids to the same project path, and projectless-thread-ids does not include the current conversation id.

~/.codex/session_index.jsonl already contained the affected conversations, so there were no missing session-index entries to add.

Suspected area

From inspecting the bundled app code, the project sidebar grouping appears to group local tasks by cwd against workspaceRootOptions.roots in sidebar-project-groups-*.js. Based on that logic, these threads should be grouped if they reach the sidebar as local tasks with workspaceKind !== 'projectless'.

This suggests the issue may be earlier in the pipeline: the sidebar task list may not include these threads, may be filtering by source kind, or may classify them as projectless before grouping despite the DB and persisted root hints being correct.

Privacy note

The real local username/path has been anonymized above, but the path structure and matching behavior are preserved.