Codex Desktop update lost project/sidebar conversation history mapping although local sessions still exist

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

Codex App version: 26.601.21317

What subscription do you have?

ChatGPT Pro plan

What platform is your computer?

sw_vers 25.4.0 arm64 arm ProductName: macOS ProductVersion: 26.4.1 BuildVersion: 25E253

What issue are you seeing?

After updating Codex Desktop/App on macOS, most existing Codex project conversations disappeared from the app sidebar and project history. The underlying local data does not appear to be deleted: ~/.codex/state_5.sqlite still contains 58 historical thread records, and ~/.codex/sessions plus ~/.codex/archived_sessions still contain rollout logs. Some old threads can be read directly by thread ID, so this looks like a local project/thread indexing or migration issue rather than actual session data loss.

The main symptoms are:

1. The Codex App recent/sidebar list only shows a few new threads after the update.
2. Many existing project conversations no longer appear under their original projects.
3. Pinning several old threads can make some conversations accessible, but the project association is still incomplete.
4. Some recovered conversations are not associated with their original project root.
5. Manual reconstruction of project mappings in the local global state can be overwritten by the running app on restart or during API/tool activity.

Local evidence:

• ~/.codex/state_5.sqlite: 58 historical thread records found.
• ~/.codex/sessions: approximately 250 MB of rollout logs.
• ~/.codex/archived_sessions: approximately 48 MB of archived rollout logs.
• Old threads can be read by ID.
• The UI/sidebar/recent list does not enumerate all available local threads.
• The relevant missing or incomplete UI state appears to involve project/thread assignment or sidebar ordering, e.g. keys similar to thread-project-assignments and sidebar-project-thread-orders.

I have backups of the relevant local state files, but I do not want to upload full SQLite databases or session JSONL logs because they contain private project paths, source code, research material, and conversation content.

What steps can reproduce the bug?

On my machine, the issue can be observed as follows:

1. Use Codex Desktop/App with multiple existing project conversations.
2. Update Codex Desktop/App.
3. Reopen Codex Desktop/App.
4. Observe that the sidebar/recent list only shows a few new threads.
5. Open old project roots in the app.
6. Observe that many projects show no conversations or only a partial conversation list.
7. Inspect local Codex state:

• ~/.codex/state_5.sqlite still contains historical thread records.
• ~/.codex/sessions and ~/.codex/archived_sessions still contain rollout logs.

1. Verify that some old threads can still be read by thread ID, which indicates the session data itself still exists.
2. Pinning or manually associating some threads can partially recover visibility, but the app does not fully rebuild project/sidebar history from the durable local metadata.
3. Manual edits to global/sidebar state may be overwritten by the running app, so this likely needs an official migration/backfill path rather than user-level state-file editing.

What is the expected behavior?

Codex Desktop/App should rebuild project/thread mappings from durable local metadata after an update. Existing local sessions should remain visible in their original project history. If a sidebar/project mapping cache is missing or stale, the app should treat it as rebuildable cache rather than as the source of truth. If CLI/App histories are intentionally separate, the app should provide an explicit import/rebuild command or UI action.

Additional information

This appears related to local history/project-sidebar migration or indexing. I found similar symptoms in existing Codex issues where local sessions exist but the Desktop UI shows an empty or stale project/sidebar history. I am willing to provide redacted diagnostics such as thread counts, schema fields, anonymized project roots, and sanitized logs, but not full local session logs or SQLite databases unless there is a safe redaction procedure.