[BUG] Project disappears from desktop app sidebar after crash, despite intact session data
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
- Have an active Claude Code session against a local project folder.
- Machine/app experiences a sudden restart mid-session.
- Relaunch the desktop app.
- 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.jsonlfiles, one 5.4MB). - Project registry: entry present (twice — once with
\path separators, once with/) inC:\Users\<user>\.claude.jsonunderprojects. - 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 markedisArchived: true, including the current session (matched bycliSessionId). - Account/workspace linkage:
config.json'slastKnownAccountUuidmatches the account folder above; the workspace UUID has adxt:allowlistLastUpdatedtimestamp 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
- Have an active Claude Code session against a local project folder.
- Machine/app experiences a sudden restart mid-session.
- Relaunch the desktop app.
- 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.jsonlfiles, one 5.4MB). - Project registry: entry present (twice — once with
\path separators, once with/) inC:\Users\<user>\.claude.jsonunderprojects. - 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 markedisArchived: true, including the current session (matched bycliSessionId). - Account/workspace linkage:
config.json'slastKnownAccountUuidmatches the account folder above; the workspace UUID has adxt:allowlistLastUpdatedtimestamp 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
- Have an active Claude Code session against a local project folder.
- Machine/app experiences a sudden restart mid-session.
- Relaunch the desktop app.
- 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.jsonlfiles, one 5.4MB). - Project registry: entry present (twice — once with
\path separators, once with/) inC:\Users\<user>\.claude.jsonunderprojects. - 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 markedisArchived: true, including the current session (matched bycliSessionId). - Account/workspace linkage:
config.json'slastKnownAccountUuidmatches the account folder above; the workspace UUID has adxt:allowlistLastUpdatedtimestamp 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_