[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_
3 Comments
Corroborating this from a different trigger — not a crash, but a regular app update. Environment: Windows 11 Pro (10.0.26200), Claude Code CLI
2.1.169 (Claude Code), PowerShell.Symptom match: After updating the desktop app, the left sidebar session list showed almost nothing, and two actively-used project working directories had dropped out of the folder-picker's known-projects list, even though their on-disk data was completely intact.
Verification performed:
C:\Users\<user>\.claude.json→projectskey: two working directories with real, ongoing session history (last commits within the past few days) were missing from this list after the update. Other, older-but-less-active project paths were still present. I manually re-added the two missing entries and confirmed via diff that no other top-level keys or existing project entries were altered by the edit.C:\Users\<user>\.claude\projects\<encoded-path>\, for all affected projects (one with 2 session-id subfolders +workflows\, last modified same week; another with only amemory\subfolder).This suggests the same root cause as the OP's hypothesis: the sidebar/session-list is driven by a separate index from the raw
~/.claude/projects/*transcripts and the.claude.jsonproject registry, and that index either isn't being reconciled against on-disk state after certain app lifecycle events (crash or update, in our two reports), or never got backfilled with pre-existing local history at all.Workaround used: same as OP — manually re-adding the missing entries to
.claude.json'sprojectskey restores the folder-picker list, but does not restore the sidebar's session/history entries for those projects, since that's driven by the separate index mentioned above, which has no manual repair path from the local filesystem.Another independent Windows repro, with one extra data point that narrows this down further. Same underlying pattern: multiple projects vanished from the sidebar after an app restart (in this case triggered while troubleshooting the separate Remote Control bridge bug in #94049), while every underlying .jsonl transcript under ~/.claude/projects remained fully intact and unmodified.
The useful new evidence: two of the missing projects had their original working directory physically moved by the user (a folder reorganization), so the literal path recorded at ~/.claude/projects/<encoded-path> no longer existed on disk at all. As a test, I recreated the exact original path as a Windows directory junction pointing at the folder's new real location, confirmed with ls that the old path now resolves correctly and lists the real files, then had the user fully quit and relaunch the app. The project still did not reappear in the sidebar.
That rules out fs.existsSync-style path resolution as the sidebar's gating check, and points even more specifically at a stale renderer-side index/cache that a restart does not rebuild or reconcile against what is actually on disk, exactly as suspected above. Also confirming the workaround holds: running claude directly from the affected folder still resumes the existing history correctly, it is only the sidebar listing that is wrong.
Additional data point that narrows this further: on Windows, with the desktop app open and a fresh claude.ai session in a regular browser (same account, no local desktop-app cache) open side by side, the browser shows fewer Projects/sidebar folders than the desktop app's own local cache.
Concretely: the desktop app's Chromium IndexedDB store (
AppData\Roaming\Claude\IndexedDB\https_claude.ai_0.indexeddb.leveldb) still reflects a richer set of project/folder entries than what the live claude.ai backend currently returns to a plain browser session for the same account. That rules out a purely client-side desktop-app rendering bug (a stale-cache theory would predict the browser, with no local cache, shows the correct, complete state) — instead it points at the account-side project list itself having lost entries server-side, with the desktop app's local IndexedDB cache being the only surviving copy of the pre-loss state on this machine.Given that, anyone hitting this should treat their local desktop app cache as the highest-fidelity remaining evidence of what their project list used to contain, and should avoid actions that would force a full resync/cache-clear of the desktop app until support has had a chance to inspect it, since that's likely the only remaining copy of the richer list.