Windows: Desktop crash wedged the MSIX package; recovery required manual package removal, destroying local app data (Code-tab group assignments, crash dumps)

Addendum after two days of hands-on state recovery. These findings reframe the data-loss part of this report: the loss is not just "package removal deleted local files" - three separate design decisions make recovery impossible even when the user still has all the underlying data.

1. Sidebar group assignments and pins cannot be restored from outside the app. They live in renderer localStorage (dframe-store, dframe-starred-code) and are synced (ccd-sync-* keys) with the desktop app as the sync owner. On every desktop boot, the app pulls the server copy and discards local edits. We verified this directly: well-formed leveldb WAL records written while the app was fully quit (correct CRC framing, winning sequence numbers, verified by strict replay) were applied on disk and then silently overwritten by the boot-time sync pull. Assignments written through the claude.ai web UI do not propagate back either - the web side is a read-mostly follower. The only writer that sticks is the desktop UI itself, one drag at a time.

1. The reinstall orphaned the server-side session registry. After the package removal and re-registration, 106 of this account's 132 server-registered Code sessions flipped to archived. The sidebar only fetches statuses=active&statuses=paused, so from the user's perspective two weeks of history simply vanished - it was neither deleted nor hidden by choice. Recovery required discovering and mass-calling POST /v1/code/sessions/<id>/unarchive (94 calls) through an authenticated browser session, which is not something a normal user can do.

1. Even unarchived, older sessions stay invisible. The sidebar renders roughly the 50 most recently active sessions (limit=50 fetch plus a single "Show N more" expansion - observed ceiling 53 rendered of 119 active). Custom groups only display members that happen to be inside that window. Sessions created before server sync existed (10 here) have no server record at all and cannot be re-listed once the local index is gone, even though their transcripts under ~/.claude are intact.

Suggested additions to the fix list:

• Do not let reinstall/device re-registration archive the account's sessions, or offer a one-click "restore my sessions" after reauth.
• Persist group/pin state with session data (as originally suggested), or at minimum make it exportable/importable - the sync-owner design makes every other recovery path a dead end by construction.
• Provide a way to browse or expand beyond the ~50-session sidebar window; grouped sessions outside the window currently look lost.

Happy to share the full recovery tooling and timestamps if useful.

I can reproduce a very similar failure chain on another Windows 10 Pro 19045 x64 system running Claude Desktop 1.24012.9 (direct-download MSIX).

The initial failure happened during normal Claude Desktop Code-tab use, before any manual package or local-state modifications:

• Claude Desktop closed unexpectedly mid-use.
• The app/shortcut disappeared and Windows reported:

"There's a problem with Claude. Reinstall the application."

• ClaudeSetup.log then showed:
• CoworkVMService already exists / potential conflict
• failed to remove CoworkVMService: Access is denied
• data-preserving removal rejected with 0x80073CFA
• AddPackage failed with 0x80073CF9
• misleading "Administrator access is required" message despite elevation
• Manual Remove-AppxPackage followed by reinstall temporarily restored the app.
• Session transcripts under ~/.claude/projects survived, but most Code-tab sessions/groups disappeared from the sidebar after reinstall.

One potentially useful additional clue: during a later launch failure I captured an Electron/Chromium fatal GPU-process crash:

[process-id]: ERROR: gpu_process_host.cc
GPU process exited unexpectedly: exit_code=101457950
GPU process launch failed: error_code=18
FATAL: GPU process isn't usable. Goodbye.

Immediately afterward, launching via claude:// failed with:
"Cannot start the application. Try reinstalling the application to fix the problem."

The package subsequently reported:
Status: Modified, NeedsRemediation

I cannot prove that the GPU crash caused the original package wedge, but it may be useful for correlation because the resulting MSIX/Cowork failure chain closely matches this issue.

I can provide the full ClaudeSetup.log and the console output with the GPU failure if useful.

Thanks @LucasHenriqueDiniz - that GPU-process fatal is the most useful clue in this thread. In my incident the original faulting process was unrecoverable (the Crashpad data lived in the package profile that had to be removed to un-wedge the install - the circular-evidence problem in my addendum), but your capture matches the fingerprint exactly: hard exit mid-use, no WER entry, package left needing remediation, then the identical CoworkVMService / 0x80073CFA / 0x80073CF9 chain. Also confirming your "Status: Modified, NeedsRemediation" observation is useful as an early warning: my reinstalled package currently reports Ok, and I now check the status daily so any drift gets caught while the app still launches. If you can attach your ClaudeSetup.log and the GPU console output, that gives the maintainers two independent full traces to correlate.

Addendum: two more data points from this install (Windows 10 Pro 19045, Alienware Aurora R12, Claude Desktop 1.24012.9 MSIX)

1. Second GPU-process crash, this time WITHOUT the MSIX wedge (2026-08-01)

Mid-session (heavy background-subagent fan-out running), the app window went dead at 16:09 local. The app's own logs\main.log is the only place it shows up:

2026-08-01 16:09:12 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

Logged twice back-to-back (looks like once per window), exitCode 101457950 = 0x060C201E. The main process never exited: main.log goes silent after this line until the post-reinstall app start 35 minutes later, and the OS has no record of the event at all - no WER report, no Application event log entry, no Crashpad dump. So this failure class is invisible to OS-level telemetry; the dead window plus a GPU process gone line in main.log is the whole signature. Fastest user-side triage: Select-String "GPU process" logs\main.log.

The important contrast with my 07-25 incident: the package did NOT wedge. Get-AppxPackage Status stayed Ok, and an over-the-top reinstall preserved all package state - sessions, groups, pins, wrappers. Losses were limited to in-flight background tasks, which correctly resolved as "stopped / No completion" on relaunch, and the session transcript kept every completed turn. So the GPU-death class has a benign variant when the package survives; what made 07-25 catastrophic was the NeedsRemediation wedge that followed, not the crash itself. This also correlates with the independent GPU-process repro reported earlier in this thread (the error_code=18 launch failure): same class, different aftermath.

2. Mechanism for the duplicated sidebar rows ("ghost pins")

Diagnosed 2026-07-27 on the same install. The duplicates are purely client-side render state:

• The synced pin doc (ccd/dframe-starred-code in user_settings) holds only unique session ids, and the server session list has zero duplicate rows. Server state is clean.
• The duplication lives in the persisted react-query cache (localStorage key react-query-cache-ls), query sessions_api_list_sessions: its single cached page accumulates n+1 ids for n unique sessions, and the sidebar renders one row per occurrence.
• Repro: keep the app open, touch any session (archive + unarchive is enough), and watch its sidebar row double. The touched session is re-inserted into the cached page instead of upserted - I forced this and watched the page go from 51 to 52 ids with the same session present twice.
• Growth is real while the app sits open: two affected pinned sessions gained roughly one duplicate row per 12.5 minutes, in lockstep (5 rows to 12 rows in about 88 minutes, untouched). The reliable victims are pinned sessions stuck in status_bucket: working with unread: false - sessions that were killed mid-turn and therefore parse as "running" forever. Non-pinned sessions duplicate too (found one at x2); Pinned is just where it is visible.
• Cleanup behavior, tested with an untouched twin as control: archive + unarchive does not evict ghosts (the stuck working bucket is derived state and reverts on unarchive). Unpinning stops NEW growth but does not clear existing ghost rows - they are stale row objects decoupled from pin state. Only an app relaunch clears the ones on screen.

Happy to provide the raw notes for either item if useful.