›_ Codex Issues
Codex Issues / #37566

Codex desktop app does not consistently repopulate project thread tree after restart until threads are manually navigated

Resolved 💬 4 comments Opened Aug 8, 2026 by TodWulff Closed Aug 15, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

Observed repeatedly across late July and early August 2026 builds of the Codex desktop app on Windows. Exact current app version can be supplied from the reporter's About dialog if needed.

What subscription do you have?

ChatGPT/Codex desktop app user with Codex app project threads.

What platform is your computer?

Windows desktop app on Windows, using a saved local Codex project whose path is a network-mounted project directory. The project path is backed by WebDAV (\\host@port\DavWWWRoot\...) and previously by SSHFS.

What issue are you seeing?

After fully quitting/restarting the Codex desktop app, the sidebar/project tree often fails to repopulate the known project thread list for a saved project. The underlying threads are not lost: list_threads still returns the expected Codex thread records and they remain individually navigable. The UI sidebar only repopulates after a manual/non-mutating refresh pattern: call list_threads, then navigate to each known project thread ID one by one, then navigate back to the root/pinned refresh thread.

This creates recurring anxiety about apparent conversation history loss, even though the session data and task index are intact.

Steps to reproduce

  1. Use Codex desktop app on Windows with a saved project rooted at a network-mounted directory, e.g. a WebDAV-backed path under \\host@port\DavWWWRoot\project.
  2. Accumulate multiple Codex project threads under that project.
  3. Fully quit/restart the Codex desktop app.
  4. Open the app and inspect the project tree/sidebar.
  5. Observe that only a subset of project threads may render, or the project may appear sparsely populated.
  6. From a root/pinned Codex thread, call the app thread index (list_threads).
  7. Observe that the missing project threads are still present and addressable.
  8. Navigate to each missing/known project thread using app navigation only.
  9. Observe that the sidebar/project tree repopulates.

Expected behavior

On app startup, the project tree should be hydrated from the same task/thread index that list_threads can already see. Known project threads should render without requiring manual navigation through every thread.

Actual behavior

The UI sidebar/project tree can show an incomplete list after restart. Manual navigation to each thread appears to force the app to rediscover or rehydrate the conversation tree.

Workaround

A pinned/root Codex task is used to run a non-mutating refresh sequence:

  1. list_threads
  2. navigate project threads newest to oldest
  3. return to the root refresh task

No files under .codex are edited. The workaround restores the sidebar until the next app restart.

Suggested fix / feature request

Please make the project tree/sidebar hydrate reliably on app startup from the task index, including for network-backed project paths. If startup hydration is intentionally lazy, please add a safe UI command such as "Refresh project task tree" that performs the same non-mutating reindex/navigation-free refresh without requiring the user to open every thread manually.

Additional context

The affected project path has used network filesystems, first SSHFS and then WebDAV. The current workaround confirms the underlying session history is not gone; this appears to be a UI/project-tree hydration/cache issue rather than data loss.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 20 days ago

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

  • #37310
  • #36504

Powered by Codex Action

TodWulff · 20 days ago

Follow-up after checking for prior reports: this issue may share an underlying sidebar/catalog hydration defect with several open reports, but I am leaving it open because this reproduction has a slightly different and potentially useful signal.

Related open issues I found:

  • #35088: Windows Desktop sidebar shows no Projects/Recent while the backend thread list and core state remain intact.
  • #34076: local project registrations / active threads disappear while the core database remains healthy, with local_thread_catalog divergence.
  • #36504: Desktop sidebar hides existing local Codex sessions after restart/update.
  • #37310: pinned conversations disappear after restart and reappear after another UI action forces sidebar refresh.
  • #30385: project threads missing from sidebar/search while direct thread access still works.

The distinguishing detail here is that the missing project tree entries are restored by a purely non-mutating app-navigation sequence: list_threads, navigate the known project thread IDs, then return to the root/pinned task. That makes it look less like transcript loss and more like startup sidebar/project-tree hydration failing to consume an already-readable task index. The network-backed WebDAV project path may be relevant, but the issue family appears broader than WebDAV alone.

TodWulff · 13 days ago

Additional reproduction/update on the current Windows Desktop build:

  • ChatGPT/Codex Desktop app: 26.810.50856
  • Release shown in About dialog: Aug 14, 2026
  • Codex CLI: codex-cli 0.146.0
  • Platform: Windows Desktop

The sidebar/project-tree hydration issue still reproduces on this build.

Observed latest behavior:

  1. A non-mutating refresh pass using list_threads plus app navigation through known thow-stack task IDs partially rehydrates the project tree.
  2. Newer/current thow-stack tasks appear under the thow-stack project group.
  3. Several older tasks that are visibly associated with the same project still remain under Recents instead of the project group.
  4. Opening one such visually orphaned task shows its detail/header metadata includes the project thow-stack and branch main, so the app appears to know the task-project association at the task-detail level while the sidebar grouping does not consistently consume or reconcile that same association.

This seems like a derived sidebar/catalog projection problem rather than missing project metadata or transcript loss. In other words, the task-level association is present, but the project tree grouping remains stale/partial after restart and after the manual navigation refresh workaround.

No .codex files were edited during this observation; the workaround used app navigation only.

TodWulff · 13 days ago

Resolution update from the original reporter context:

The project tree is now restored after local remediation, and this no longer appears to be a Codex Desktop application defect in this specific environment.

What changed during the lifetime of this project:

  • The same Linux project directory was accessed from Windows through multiple path mechanisms over time:
  • SSHFS: \\sshfs\todwulff@10.0.0.68\thow\thow-stack
  • WebDAV/WsgiDAV: \\10.0.0.68@18080\DavWWWRoot\thow\thow-stack
  • mapped H: drive backed by WebDAV
  • finally mapped H: drive backed by Samba/SMB
  • The project root currently resolves reliably as H:\thow\thow-stack, backed by SMB share \\10.0.0.68\todwulff-home.
  • After normalizing local Codex metadata so older thread/project path references pointed at the current canonical project root, the Codex sidebar/project tree correctly grouped the older tasks under thow-stack again.

Remediation performed locally:

  1. Replaced the unstable Windows WebDAV drive mapping with a Samba/SMB share from the Linux host.
  2. Confirmed from Windows:
  • H: maps to \\10.0.0.68\todwulff-home
  • H:\thow\thow-stack resolves successfully.
  1. Fully closed Codex/ChatGPT.
  2. Took a clean snapshot of %USERPROFILE%\.codex high-value UI/context state.
  3. Ran a narrow local metadata repair to normalize stale thow-stack thread/project path references from the old SSHFS/WebDAV paths to H:\thow\thow-stack.
  4. Reopened Codex Desktop and confirmed the sidebar now shows the expected thow-stack project grouping with the previously orphaned older tasks restored.

Given that outcome, the original failure was likely caused by path instability and path churn across SSHFS/WebDAV/SMB rather than a general Codex Desktop sidebar hydration bug. There may still be broader related issues around stale project catalogs, but this particular report is resolved locally and can be closed from the reporter side.