[BUG] Project disappears from desktop app sidebar after crash, despite intact session data

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 4, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Bug: Project disappears from desktop app sidebar after crash, despite intact session data

Summary

After an unexpected restart mid-session, a project stopped appearing in the desktop app's left sidebar. All underlying data (session transcripts, project registry, desktop session cache) is confirmed intact on disk. A full app restart (quit from tray + relaunch) did not restore the sidebar entry.

Environment

  • Platform: Windows 10 Pro 10.0.19045
  • App: Claude desktop app (Electron), updater last-seen version 1.24012.11
  • Account UUID: 0d6c2f24-9aa8-459e-8ac2-0f2e7d9a75e3
  • Workspace/project UUID: a7eb6299-20c5-44bb-945c-5ff558f2e8eb
  • Project path: E:\Parrot_Music\parrot-music-player

Steps to reproduce

  1. Have an active Claude Code session against a local project folder.
  2. Machine/app experiences a sudden restart mid-session.
  3. Relaunch the desktop app.
  4. Observe: the project is no longer listed in the left sidebar.

Expected behavior

The project reappears in the sidebar with its session history intact, since the underlying data was never lost.

Actual behavior

The project is missing from the sidebar. A full quit-from-tray + relaunch of the app does not bring it back.

Verification performed (all data confirmed intact)

  • Project folder on disk: fully present, git history and files untouched (E:\Parrot_Music\parrot-music-player).
  • Session transcripts: present and unmodified in C:\Users\<user>\.claude\projects\E--Parrot-Music-parrot-music-player\ (2 .jsonl files, one 5.4MB).
  • Project registry: entry present (twice — once with \ path separators, once with /) in C:\Users\<user>\.claude.json under projects.
  • Desktop app session cache: 55 session records present under AppData\Roaming\Claude\claude-code-sessions\0d6c2f24-9aa8-459e-8ac2-0f2e7d9a75e3\a7eb6299-20c5-44bb-945c-5ff558f2e8eb\, none marked isArchived: true, including the current session (matched by cliSessionId).
  • Account/workspace linkage: config.json's lastKnownAccountUuid matches the account folder above; the workspace UUID has a dxt:allowlistLastUpdated timestamp from the same day as the crash, indicating the app recognizes the workspace as recently active.
  • New-session attachment behavior: starting a brand-new conversation in the same folder (E:\Parrot_Music\parrot-music-player) after the sidebar entry vanished correctly appended to the same existing workspace UUID (a7eb6299-...) rather than creating a new/duplicate one — session count went from 55 to 64 records, all still in the original workspace folder. No second workspace folder for this path exists anywhere under the account.

Suspected cause

Given all local file-based state is correct, and new sessions still correctly attach to the existing workspace ID rather than forking a new one, this points specifically at the sidebar's project-list rendering/fetch logic, not lost data and likely not a lost account-side record:

  • A stale in-memory/renderer-side cache (e.g. IndexedDB/LevelDB under AppData\Roaming\Claude\) that didn't get invalidated/rebuilt after the crash, or
  • The sidebar's project list query excluding this workspace for some other reason (e.g. a corrupted list entry, a filter/sort bug) despite the workspace itself being fully functional.

Workaround

The CLI (claude) run directly from the project directory still resumes against the existing session history, since it reads the same on-disk transcripts. Only the desktop app's sidebar UI is affected.

What I've already tried

  • Full quit from system tray + relaunch (no change)
  • Sign out and sign back in (no change)
  • Checked for app updates (none pending)
  • Looked for an "Add/Open Project" option to manually reattach (not available — only an "Open file" option exists, no folder/project-level add action)
  • Started a new conversation in the same folder as a test (see "New-session attachment behavior" above) — did not restore the sidebar entry, but confirmed the workspace itself is healthy

What Should Happen?

Bug: Project disappears from desktop app sidebar after crash, despite intact session data

Summary

After an unexpected restart mid-session, a project stopped appearing in the desktop app's left sidebar. All underlying data (session transcripts, project registry, desktop session cache) is confirmed intact on disk. A full app restart (quit from tray + relaunch) did not restore the sidebar entry.

Environment

  • Platform: Windows 10 Pro 10.0.19045
  • App: Claude desktop app (Electron), updater last-seen version 1.24012.11
  • Account UUID: 0d6c2f24-9aa8-459e-8ac2-0f2e7d9a75e3
  • Workspace/project UUID: a7eb6299-20c5-44bb-945c-5ff558f2e8eb
  • Project path: E:\Parrot_Music\parrot-music-player

Steps to reproduce

  1. Have an active Claude Code session against a local project folder.
  2. Machine/app experiences a sudden restart mid-session.
  3. Relaunch the desktop app.
  4. Observe: the project is no longer listed in the left sidebar.

Expected behavior

The project reappears in the sidebar with its session history intact, since the underlying data was never lost.

Actual behavior

The project is missing from the sidebar. A full quit-from-tray + relaunch of the app does not bring it back.

Verification performed (all data confirmed intact)

  • Project folder on disk: fully present, git history and files untouched (E:\Parrot_Music\parrot-music-player).
  • Session transcripts: present and unmodified in C:\Users\<user>\.claude\projects\E--Parrot-Music-parrot-music-player\ (2 .jsonl files, one 5.4MB).
  • Project registry: entry present (twice — once with \ path separators, once with /) in C:\Users\<user>\.claude.json under projects.
  • Desktop app session cache: 55 session records present under AppData\Roaming\Claude\claude-code-sessions\0d6c2f24-9aa8-459e-8ac2-0f2e7d9a75e3\a7eb6299-20c5-44bb-945c-5ff558f2e8eb\, none marked isArchived: true, including the current session (matched by cliSessionId).
  • Account/workspace linkage: config.json's lastKnownAccountUuid matches the account folder above; the workspace UUID has a dxt:allowlistLastUpdated timestamp from the same day as the crash, indicating the app recognizes the workspace as recently active.
  • New-session attachment behavior: starting a brand-new conversation in the same folder (E:\Parrot_Music\parrot-music-player) after the sidebar entry vanished correctly appended to the same existing workspace UUID (a7eb6299-...) rather than creating a new/duplicate one — session count went from 55 to 64 records, all still in the original workspace folder. No second workspace folder for this path exists anywhere under the account.

Suspected cause

Given all local file-based state is correct, and new sessions still correctly attach to the existing workspace ID rather than forking a new one, this points specifically at the sidebar's project-list rendering/fetch logic, not lost data and likely not a lost account-side record:

  • A stale in-memory/renderer-side cache (e.g. IndexedDB/LevelDB under AppData\Roaming\Claude\) that didn't get invalidated/rebuilt after the crash, or
  • The sidebar's project list query excluding this workspace for some other reason (e.g. a corrupted list entry, a filter/sort bug) despite the workspace itself being fully functional.

Workaround

The CLI (claude) run directly from the project directory still resumes against the existing session history, since it reads the same on-disk transcripts. Only the desktop app's sidebar UI is affected.

What I've already tried

  • Full quit from system tray + relaunch (no change)
  • Sign out and sign back in (no change)
  • Checked for app updates (none pending)
  • Looked for an "Add/Open Project" option to manually reattach (not available — only an "Open file" option exists, no folder/project-level add action)
  • Started a new conversation in the same folder as a test (see "New-session attachment behavior" above) — did not restore the sidebar entry, but confirmed the workspace itself is healthy

Error Messages/Logs

Steps to Reproduce

Bug: Project disappears from desktop app sidebar after crash, despite intact session data

Summary

After an unexpected restart mid-session, a project stopped appearing in the desktop app's left sidebar. All underlying data (session transcripts, project registry, desktop session cache) is confirmed intact on disk. A full app restart (quit from tray + relaunch) did not restore the sidebar entry.

Environment

  • Platform: Windows 10 Pro 10.0.19045
  • App: Claude desktop app (Electron), updater last-seen version 1.24012.11
  • Account UUID: 0d6c2f24-9aa8-459e-8ac2-0f2e7d9a75e3
  • Workspace/project UUID: a7eb6299-20c5-44bb-945c-5ff558f2e8eb
  • Project path: E:\Parrot_Music\parrot-music-player

Steps to reproduce

  1. Have an active Claude Code session against a local project folder.
  2. Machine/app experiences a sudden restart mid-session.
  3. Relaunch the desktop app.
  4. Observe: the project is no longer listed in the left sidebar.

Expected behavior

The project reappears in the sidebar with its session history intact, since the underlying data was never lost.

Actual behavior

The project is missing from the sidebar. A full quit-from-tray + relaunch of the app does not bring it back.

Verification performed (all data confirmed intact)

  • Project folder on disk: fully present, git history and files untouched (E:\Parrot_Music\parrot-music-player).
  • Session transcripts: present and unmodified in C:\Users\<user>\.claude\projects\E--Parrot-Music-parrot-music-player\ (2 .jsonl files, one 5.4MB).
  • Project registry: entry present (twice — once with \ path separators, once with /) in C:\Users\<user>\.claude.json under projects.
  • Desktop app session cache: 55 session records present under AppData\Roaming\Claude\claude-code-sessions\0d6c2f24-9aa8-459e-8ac2-0f2e7d9a75e3\a7eb6299-20c5-44bb-945c-5ff558f2e8eb\, none marked isArchived: true, including the current session (matched by cliSessionId).
  • Account/workspace linkage: config.json's lastKnownAccountUuid matches the account folder above; the workspace UUID has a dxt:allowlistLastUpdated timestamp from the same day as the crash, indicating the app recognizes the workspace as recently active.
  • New-session attachment behavior: starting a brand-new conversation in the same folder (E:\Parrot_Music\parrot-music-player) after the sidebar entry vanished correctly appended to the same existing workspace UUID (a7eb6299-...) rather than creating a new/duplicate one — session count went from 55 to 64 records, all still in the original workspace folder. No second workspace folder for this path exists anywhere under the account.

Suspected cause

Given all local file-based state is correct, and new sessions still correctly attach to the existing workspace ID rather than forking a new one, this points specifically at the sidebar's project-list rendering/fetch logic, not lost data and likely not a lost account-side record:

  • A stale in-memory/renderer-side cache (e.g. IndexedDB/LevelDB under AppData\Roaming\Claude\) that didn't get invalidated/rebuilt after the crash, or
  • The sidebar's project list query excluding this workspace for some other reason (e.g. a corrupted list entry, a filter/sort bug) despite the workspace itself being fully functional.

Workaround

The CLI (claude) run directly from the project directory still resumes against the existing session history, since it reads the same on-disk transcripts. Only the desktop app's sidebar UI is affected.

What I've already tried

  • Full quit from system tray + relaunch (no change)
  • Sign out and sign back in (no change)
  • Checked for app updates (none pending)
  • Looked for an "Add/Open Project" option to manually reattach (not available — only an "Open file" option exists, no folder/project-level add action)
  • Started a new conversation in the same folder as a test (see "New-session attachment behavior" above) — did not restore the sidebar entry, but confirmed the workspace itself is healthy

Claude Model

_No response_

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

1.24012.11

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗