Codex desktop loses local project registrations and hides active threads while CLI/core database remains healthy

Codex version

• ChatGPT desktop: 26.715.31925 (build 5551)
• Embedded Codex runtime: 0.145.0-alpha.18
• Standalone Codex CLI: 0.144.6

Environment

• macOS 27.0 (26A5378n), Apple Silicon
• Local project: /Users/tucker/projects/chatgpt
• Sidebar mode: Project, priority sorting

Summary

Throughout July 18, local projects and active threads repeatedly disappeared from the Codex desktop sidebar. The affected threads were not deleted: they remained active and unarchived in ~/.codex/state_5.sqlite, retained their rollout files, and could be resumed with the Codex CLI.

This appears to be a synchronization failure between the core thread database, the desktop local-thread catalog, and the desktop project/sidebar state.

Feedback and diagnostics were uploaded from thread:

019f7754-3609-7521-b6c6-a401f1788304

Primary affected thread:

019f76fb-159b-7841-978d-59551f1d7f02 — “Review CDRL Workflow Compatibility”

Expected behavior

• Active, unarchived threads remain visible in the sidebar.
• Registered local projects persist across app restarts and host refreshes.
• An active thread without project assignment metadata appears in a chronological or projectless fallback view.
• Resuming an existing thread reconnects to it instead of creating a duplicate.

Actual behavior

• The local project disappeared from the project list.
• Projects that remained visible showed “No chats.”
• The affected thread disappeared from the UI while it was still running.
• codex resume 019f76fb-159b-7841-978d-59551f1d7f02 could resume it.
• Recovery produced a second thread with the same title and cwd: 019f774e-e553-79c2-aa8e-284af891964f. There is no parent/fork edge connecting it to the original.

Diagnostic evidence

• Both standalone and embedded codex doctor reported 17 ok | 1 idle | 0 warn | 0 fail; core database and rollout inventory agree.
• At final capture, the core database contained 70 active/unarchived threads (65 with previews), while the desktop local-thread catalog contained only 38 rows.
• The desktop catalog contained only one row for the affected cwd.
• Every host in local_thread_catalog_sync_state had initial_build_complete=0.
• An approximately 02:58 ET sidebar-state snapshot contained 17 local projects and 22 project-order entries. Later/current state contained 7 local projects and 6 project-order entries. Eleven prior local projects disappeared.
• The affected project was absent from both local-projects and project-order.
• The original thread had no thread-project-assignments entry, projectless assignment, or workspace-root hint, leaving it with no UI bucket in Project mode.
• The core DB record continued updating after CLI recovery while its session-index timestamp remained unchanged.
• The desktop log showed 97 successful thread/list responses and one transient failure, so this was not a sustained local app-server outage.
• Startup selected remote-ssh-discovered:pi-node1 even though the persisted selected host was null. The remote-control environment then logged 143 handshake failures and 142 reconnect attempts.
• macOS generated two disk-write resource diagnostics for the embedded Codex process: approximately 8.6 GB dirtied over 5,057 seconds early in the day, and approximately 2.1 GB over 5,877 seconds later. Samples include SQLite WAL/checkpoint and plugin-catalog cache writes. No Codex/ChatGPT crash report was found.

Timeline

• ~03:01 ET: first excessive disk-write diagnostic.
• 14:08–14:09 ET: missing-thread and state-database discrepancy warnings; UI showed “No chats.”
• 14:12 ET: confirmed the issue existed before updating the standalone CLI.
• 14:13–14:19 ET: after the problem began, user-authorized cleanup/hydration of archived rows and session index was attempted, followed by an app restart. The visibility problem persisted.
• 15:45 ET: repeated read_repair_rollout_path: upsert_needed (slow path).
• 16:38 ET: ChatGPT launched and auto-selected the remote SSH host.
• 16:46 ET: primary affected thread created.
• ~17:50 ET: desktop activity for the original thread stopped.
• 18:16 ET: second disk-write diagnostic.
• 18:18 ET: duplicate thread created.
• 18:23 ET: macOS displayed “Dock Tile Extension Added — ChatGPT added 1 Dock tile extension.” This is included as correlated timing only; there is no evidence it caused the catalog failure.
• 18:25 ET: global sidebar state was atomically rewritten with the substantially smaller project registry.

The manual database/session-index repair attempts occurred after the missing-thread symptom and are not the initial cause.

Reproduction

The issue is intermittent:

1. Open ChatGPT/Codex desktop in Project sidebar mode.
2. Open a local project and start or continue a long-running thread.
3. Allow an app restart/update, host refresh, or remote-host reconnection.
4. The project or thread may disappear, or the project may show “No chats.”
5. Resume the supposedly missing thread by ID with the CLI.
6. The thread remains active in the core database while its desktop project/assignment/catalog metadata is absent.

Questions

• Why can local-projects, project-order, thread assignments, and local_thread_catalog diverge from state_5.sqlite?
• Why does the catalog remain at initial_build_complete=0 without rebuilding or self-repairing?
• Why are active orphaned threads not surfaced in a chronological/projectless fallback view?
• Why did recovery create a duplicate session rather than reattach the original?
• Can automatic stale remote-host selection alter catalog ownership or reconciliation?
• Are the excessive SQLite and plugin-catalog writes related?
• Is there a supported way to rebuild the sidebar catalog without deleting transcripts?

Full diagnostics and logs were uploaded through /feedback under thread ID 019f7754-3609-7521-b6c6-a401f1788304. Sensitive raw logs and databases are intentionally not attached publicly.