[BUG] Windows desktop: sidebar custom groups lost on every restart — persisted clientState (folders-*) discarded at startup; theme reset to system

Summary

On the Windows desktop app, sidebar custom groups are lost on every app restart, and the appearance setting resets to "system" on every launch. Local forensics (below) show the group state is persisted to disk when created, but at startup the app discards the persisted state and overwrites it with a freshly generated one — the folders-* entry present before restart is gone from the rewritten blob.

Environment

• Claude desktop app for Windows (MSIX package Claude_pzs8sxrjxfjjc), updater version 1.17377.2
• Bundled Claude Code 2.1.197
• Windows 10 Pro 10.0.19045

Steps to reproduce

1. In the desktop app sidebar, create a custom group (and set Appearance → Dark).
2. Wait for the state to flush (~a minute of continued use to rule out quit races).
3. Quit the app completely and relaunch.

Expected: group and theme restored.
Actual: group gone (sessions fall back to ungrouped), theme back to system/light.

Forensic evidence (this machine, 2026-07-01)

1. Group creation IS persisted. Creating the group wrote a new ~395 KB blob into the profile's IndexedDB (IndexedDB/https_claude.ai_0.indexeddb.blob/..., database keyval-store) containing a serialized query-cache clientState. A string scan of that blob shows a folders-<hash> entry (folders-ce9d3bbe29eccd14a66bb8761462fb4d) — the group assignment.

2. Startup discards it. After quit + relaunch, the old blob is deleted and replaced by a same-shape, freshly written clientState blob. A string-set diff of the two blobs shows the folders-<hash> entry present pre-restart and absent post-restart. The UI accordingly shows no groups. So this is not a missing write — it is persisted state being dropped/overwritten during startup hydration.

3. Theme reset is a config rewrite at boot. Toggling Dark writes "userThemeMode": "dark" to the app's config.json. On every launch the app rewrites it to "userThemeMode": "system" (reproduced 3× while watching the file). With Windows apps mode set to Light this renders the app light every launch. (User-side workaround: set Windows app mode to Dark.)

4. Aggravating historical defect — corrupt localStorage WAL reused indefinitely. Until today this profile's Local Storage/leveldb write-ahead log had been corrupt since ~May 15. Chromium's own info LOG showed, at every launch:

Recovering log #685
(ignoring error) .../000685.log: dropping 11138721 bytes; Corruption: partial record without end(1)
Reusing old log .../000685.log

i.e. ~11 MB (essentially all localStorage writes since mid-May) silently discarded at each startup, after which the app kept appending to the same corrupt log, so it never healed. The app has no detection/repair for this. (On macOS, group assignments reportedly live in exactly this localStorage — see #72820 — so this corruption mode silently destroys sidebar organization there too.) Manually moving the corrupt WAL aside restored clean recovery, which is how the IndexedDB findings above were isolated.

Related issues

• #53340 — Windows desktop lost project-level folder grouping after 2.1.119 (closed, not planned)
• #54759 — sessions disappear from sidebar on Windows restart (closed)
• #72820 — group membership stored per-origin in localStorage (macOS), wiped on account switch
• #65177 — web session groups don't persist across environments
• #48773 — dark mode preference resets on re-authentication (closed)

Suggested areas to look

• Startup hydration of the persisted keyval-store clientState: it appears to be overwritten with a fresh snapshot before/instead of being restored (or the folders-* query is excluded/pruned during rehydration).
• The boot path that rewrites userThemeMode back to system, clobbering the user's saved choice.
• Detect-and-recover for corrupt leveldb WALs (Chromium "Reusing old log" after a corruption drop means permanent silent data loss until manual intervention).