[BUG] Desktop app: crash/interrupted update corrupts session sidebar — projects reset to "Other", titles/order lost, sessions appear merged (possible same root cause as #76430)

Additional diagnostic detail (Windows Desktop, build 1.40609.1)

Dug into the actual on-disk data behind this rather than just the symptom, since it points fairly specifically at where the bug lives. Three separate storage layers are involved, and only one of them is actually broken in a way that explains what's on screen.

Timeline

Several unrelated app folders under %APPDATA%\Claude (claude-code, local-agent-mode-sessions, ChromeNativeHost) all share a last-write timestamp of 2026-09-01 ~23:21-23:43, consistent with an app update/relaunch. That's the same window the corruption below is dated to.

Layer 1 — Claude Code CLI project storage (~/.claude/projects/): intact

22 project directories, each correctly named after the real filesystem path (e.g. C--Users-ADGEl-OneDrive-Desktop-Second-Brain-06-Games-MOLTKIN), with sensible last-write timestamps spanning weeks — not touched or clustered by the incident. This layer is not the problem.

Layer 2 — Desktop's own session-metadata cache: provably corrupted, but not the main cause of "Other"

Path: %APPDATA%\Claude\claude-code-sessions\<account-uuid>\<workspace-uuid>\local_<sessionId>.json — one JSON file per session, used to populate the sidebar.

Of 90 non-task session files, 79 were rewritten in a 12-minute window (2026-09-01 23:31-23:43), shrinking from a "full" ~17KB record to a skeleton ~0.7-0.85KB record. Compare:

// FULL (healthy) — 17KB, real summarized title
{"sessionId":"local_2b5902ba-...","cwd":"C:\\","title":"Claude Desktop crashes on Windows","titleSource":"auto", ...}

// SKELETON (post-incident) — 0.8KB, title is just the raw first user message, truncated mid-word
{"sessionId":"local_0d3e6b02-...","cwd":"C:\Users\ADGEl\OneDrive\Desktop\TETHERED rework file new series outline file","title":"what chapter do we need to run pipeline on","titleSource":"auto","classifierSummaryEnabled":true, ...}

Despite the size collapse, cwd survived correctly in 86 of 90 files — only 4 sessions have a legitimately rootless cwd (C:\ or D:\) that would have nowhere sensible to group. So per-session data loss does not explain most sessions ending up in "Other" — the data needed to group them correctly is right there on disk.

One specific example worth tracing directly: local_c3fb37ee-4218-4afa-858a-83fc0d487fdf — full-size (17KB), cwd correctly set to a real project folder, remoteControlAutoEligible: true with a populated bridgeSessionIds (a phone/remote-control-bridged session, active at the time of the crash), title never got past the "Untitled session" placeholder, and it's still showing under "Other."

Layer 3 — whatever the sidebar UI actually renders from: this is where the bug is

The titles actually shown in my live sidebar (screenshot on request) — e.g. "Galaxy S22 Plus pocket Linux AI", "SONNET BOSS", "TikTok video maker with image posting" — don't match the title field in either the full or skeleton records above. That means the UI is reading from a third, separate cache (almost certainly the app's own Chromium IndexedDB/LocalStorage sidebar index under the same %APPDATA%\Claude profile) that has its own, independently-stale project/title state. A full quit-and-relaunch of the app did not fix the grouping, meaning whatever's wrong there persists across restarts rather than being purely in-memory.

Suggested direction

Given layers 1 and 2 are largely intact, this doesn't look like a data-recovery problem — it looks like the sidebar's cached index isn't being invalidated/rebuilt from the underlying session + project data after a crash or interrupted update. A forced rebuild of that index on next launch (detecting an unclean previous shutdown) would likely resolve this without needing any on-disk repair.

Happy to pull more detail (full file dumps, more examples) if useful — I have the raw session-metadata files available.

One more clarification worth recording: all the sessions currently sitting under "Other" were actively organized under their correct projects and in active use at the moment the crash/update occurred — they weren't stale, unsorted, or never-filed sessions that happened to lack a project assignment. That rules out "these were just never categorized" as an explanation and confirms the incident itself is what reset a working, organized sidebar state back to "Other" for basically everything at once.

If crashes continue to recur, I now have a local watchdog running that polls for zombie Claude processes, full crashes, and hangs, correlating each against the Windows Event Log. That should let me report back with precise timestamped evidence next time instead of just "it happened again."

Small scoped note, not new evidence for this issue's root cause — just flagging a related-but-distinct mechanism in case it's useful context for whoever picks this up: #64304 (closed as inactive, but the mechanism is corroborated by two independent reporters there) documents that Desktop keeps two separate title stores — the native local file (claude-code-sessions/.../local_*.json, title/titleSource) and a separate cloud "Bridge" record in the app's own IndexedDB (kind:"bridge", tag:"remote-control-sdk") that iOS/claude.ai/remote-control read and write. They only reconcile when a rename happens from the Desktop app itself.

I found a session in my own data with that exact signature (remoteControlAutoEligible: true, populated bridgeSessionIds) whose displayed title didn't match its local file record — consistent with #64304's mechanism rather than this issue's crash/update corruption. Not claiming it's the same bug as this one, but if a fix here ends up touching title/session reconciliation logic, it may be worth checking whether it also closes the gap #64304 describes, since both surface as "the sidebar shows a title/state that doesn't match what's actually stored."