[BUG] Uninstall/reinstall of Desktop (Windows MSIX) permanently orphans existing sessions — confirmed missing from claude.ai/code too, not just local cache

Summary

Uninstalling and reinstalling the Claude Desktop app on the same Windows machine (a full manual uninstall/reinstall, not an auto-update relaunch) permanently orphaned ~19 pre-existing sessions. This looks like the same underlying bug family as #94613, #96384, #90822, #96049 and #96220 (Remote Control / session-bridge identity breaking across Desktop lifecycle events), but with two things I haven't seen documented elsewhere:

1. The trigger is a full uninstall/reinstall, not an auto-update or plain restart.
2. The orphaning is confirmed not just a local display/cache issue — it's identical on a fully independent client (claude.ai/code).

Environment

• Claude Desktop: 2.9939.2.0 (Windows Store/MSIX build, Claude_2.9939.2.0_x64__pzs8sxrjxfjjc)
• Bundled Claude Code CLI: 2.1.281 (%APPDATA%\Roaming\Claude\claude-code\2.1.281\claude.exe)
• OS: Windows 10 Pro 10.0.19045
• ~20 sessions in a single project directory

Steps to Reproduce

1. Have several active sessions in a project folder (Remote Control connected by default).
2. Fully uninstall the Claude Desktop app (Windows, MSIX/Store build) and reinstall it, on the same machine. (Note: reports having done this exact uninstall/reinstall before with no issue — this may be intermittent or version-dependent, not deterministic.)
3. Reopen the app and sign back in.

Observed

• ~19 sessions move from their project's sidebar group into "Other"
• Opening one shows "Remote Control disconnected — Claude Code on the computer running this session is offline," despite it being the same physical machine
• Attempting to send a new message into one of them hangs indefinitely on "sending" (reproduced on a session titled "Content Creation")
• A brand-new session created after the reinstall works completely normally (this report is being filed from one)

Confirmed this is not a local-cache/display issue

Checked claude.ai/code (a fully independent client with no shared local state with Desktop) — it shows the identical gap: same new session visible, same ~19 old sessions absent/unreachable. So this isn't a case of the server having a valid reconnected session that the local UI just fails to render — the sessions appear inaccessible at the account level from any client.

What did NOT fix it

1. Fully quitting all Claude/claude processes (verified via process list, not just closing the window) and relaunching.
2. A full sign-out + sign-in. Confirmed this triggered a genuine re-authentication (the local ant-device-registry.json file was rewritten at the moment of sign-in), but the device id itself (ant-did) was unchanged throughout, and the account-side session list was unchanged before/after.
3. Starting a fresh claude remote-control relay session in the same project directory. This registered successfully as a brand-new session ("Connected", capacity 1/32) but did not reclaim or reconnect any of the 19 existing ones — it only added one more new session to the list.

Data status

Not lost. All ~20 session transcripts are intact on disk (~/.claude/projects/<project>/*.jsonl) and untouched throughout every step above. This is purely a loss of live/account-level session access, not data loss — which suggests the fix is a server-side session-ownership/device-pointer correction rather than anything recoverable client-side.

Ask

A supported way to relink sessions orphaned by a Desktop reinstall to the current install/device, or a server-side correction of these sessions' device pointer, since neither re-authentication nor a fresh Remote Control connection can do this from the client side.

Related

#94613, #96384, #90822, #96049, #96220, #95296, #95407