›_ Codex Issues
Codex Issues / #27516

Codex Desktop: thread reappears after restart, then disappears from project sidebar when clicked

Open 💬 2 comments Opened Jun 11, 2026 by Bruce-lzh
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

After restarting Codex Desktop, previously missing threads reappear under a project in the left sidebar. However, clicking one of those threads causes it to disappear from the project thread list immediately.

This does not look like intentional filtering or actual data loss. It looks like a Desktop sidebar / thread indexing / rendering bug.

Environment

  • Date observed: June 11, 2026
  • Platform: macOS
  • Codex Desktop version: unknown
  • Bundled Codex CLI version: unknown
  • Project type: local project-backed thread

Steps to reproduce

  1. Open Codex Desktop.
  2. Restart the app.
  3. Observe that previously missing threads reappear in the left sidebar under a project.
  4. Click one of the reappeared threads.
  5. Observe that the clicked thread disappears from the project's thread list immediately after selection.

Expected behavior

  • Clicking a thread should open/select it.
  • The selected thread should remain visible in the project sidebar.
  • Active unarchived local threads should remain discoverable from the Desktop UI.

Actual behavior

  • Missing threads temporarily reappear after restart.
  • Clicking one of those threads causes it to vanish from the project sidebar list.
  • The behavior is repeatable.

What I already checked

  • Sidebar filter / show options
  • Chronological organization
  • Archived threads / archived chats

These do not explain the behavior.

Why this looks like a real bug

This appears consistent with other Codex Desktop sidebar/session visibility issues where:

  • threads still exist locally
  • threads are not intentionally archived
  • the Desktop sidebar/search visibility diverges from local thread state
  • clicking or reloading can make affected threads disappear again

Impact

  • I cannot reliably resume affected project threads from the left sidebar.
  • The sidebar cannot be treated as a reliable source of truth for active conversations.
  • Restarting the app only restores visibility temporarily.

Evidence I can provide

  • Screen recording of:
  1. restart
  2. thread reappears
  3. click thread
  4. thread disappears
  • App logs
  • Affected thread IDs
  • Local diagnostics if needed

Related issues

  • #17317
  • #17970
  • #27159

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

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

  • #27159
  • #27314
  • #27453
  • #27408
  • #26411

Powered by Codex Action

Ongiei · 1 month ago

Additional confirmed evidence from macOS

I reproduced the exact restart-then-click behavior and found a persistent project-assignment mismatch behind it.

Environment

  • ChatGPT/Codex Desktop: 26.715.31925 (build 5551)
  • Bundled Codex CLI: 0.145.0-alpha.18
  • macOS: 26.4.1 (build 25E253)
  • Affected thread: local, unarchived, project-backed

Observed state after the thread disappeared

  • The rollout JSONL still existed and was readable.
  • The row in ~/.codex/state_5.sqlite still existed with archived = 0.
  • The SQLite threads.cwd had already been corrected to the current project root.
  • However, ~/.codex/.codex-global-state.json still had three conflicting Desktop-layer values for the same thread:
  • thread-project-assignments[thread] pointed to an orphan project ID and ~/Documents/obsidian.
  • thread-writable-roots[thread] contained the old pre-move project path plus ~/Documents/obsidian.
  • electron-persisted-atom-state["thread-workspace-state-v1:<thread>"] applied ~/Documents/obsidian as the project, cwd, and runtime workspace root.

This explains the visible sequence: after restart, the SQLite cwd makes the thread appear under the current project; clicking it rehydrates the stale Desktop workspace atom, and the sidebar immediately removes it from that project even though the thread remains open.

Toggle proof and workaround

Updating only SQLite restored visibility after restart but did not survive clicking the thread. Updating the three Desktop-layer values while the app was running was overwritten again by in-memory state on exit.

The workaround that persisted was:

  1. Fully quit the ChatGPT/Codex Desktop main process.
  2. Set the thread's thread-project-assignments, thread-writable-roots, and thread-workspace-state-v1 entries to the registered current project ID/path.
  3. Keep threads.cwd aligned with that same project path.
  4. Restart the app.

Before the offline correction, a consistency predicate across those fields returned false; after the correction and a fresh app start it returned true, and remained true on delayed read-back.

Suggested fix

When loading or moving a local thread, reconcile the SQLite cwd and Desktop project/workspace atom transactionally. A stale or orphaned thread-workspace-state-v1 entry should not override a valid registered project assignment on selection. A regression test should cover: move project path -> restart -> select thread -> thread remains visible under the project.

---
This issue or PR was generated by LazyCodex.
Tag: lazycodex-generated