[BUG] Windows MSIX: while Desktop is down after an update, new Remote Control sessions connect but never register - machine becomes unrecoverable remotely

Summary

The known Windows/MSIX 0x80070020 failure that prevents Claude Desktop from launching after an in-app update is already well reported (#94432, #95266, #95353, #95588). This issue is about a consequence of it that I have not seen filed: it also takes out Remote Control for the whole machine, silently, and that makes the documented cure unreachable.

While Desktop cannot launch:

1. Every Claude Code session Desktop had spawned is killed — they run inside the MSIX container and die with it.
2. A new claude --remote-control "<name>" session starts, establishes TLS to Anthropic, and then never completes registration. No ~/.claude/sessions/<pid>.json is written, and the session never appears in the session list.
3. An existing RC session that registered while Desktop was still up keeps working indefinitely.

Net effect: a user who is away from the machine can still talk to whatever RC session predates the breakage, but cannot bring back a single one of the dead ones. The only known fix is a reboot — which is precisely what a remote user cannot do safely, since a reboot lands on the lock screen and kills the one surviving channel.

The silent part is the real bug. A session that cannot register should say so, not sit there looking healthy.

Environment

• Windows 11 Pro, build 26200
• Claude Desktop 2.2553.1.0 updated in-app to 2.7032.0.0
• Claude Code 2.1.280, npm-global install (running outside the MSIX container)

Timeline observed

| Time | Event |
|---|---|
| 11:56:52 | In-app update attempt fails, 0x80073D02 (package in use) |
| 12:58:45 | Retry begins; Windows forcibly tears the old package down |
| 12:58:49 | Register succeeds for 2.7032.0.0; cowork-svc.exe restarts |
| 12:58:49 | Six Claude Code sessions die in the same second — all spawned by Desktop, i.e. inside the container |
| 13:02 | Desktop prunes their entries; replBridgePlaceholders drops 7 to 1 |
| later | Every attempt to launch Desktop fails with 0x80070020 |

Evidence

Microsoft-Windows-AppModel-Runtime/Admin, on each launch attempt:

215  0x80070020: Cannot create the Desktop AppX container for package
     Claude_2.7032.0.0_x64__<pfn> because an error was encountered converting the job.
208  0x80070020: Cannot create the process for package ... while configuring runtime.

Meanwhile Microsoft-Windows-AppXDeploymentServer/Operational reports the opposite, which sends you the wrong way:

400  Deployment Register operation ... finished successfully.

Stopping the service first does not help. Verified with zero package processes alive at launch time:

package processes remaining: 0
launched
-> 0x80070020 again, and cowork-svc.exe restarts in the same second

The Remote Control part

Comparing established TCP connections per PID:

PID 2352   established=8     <- session that registered while Desktop was up, still fully working
PID 26480  established=0     <- claude --resume <id> --remote-control "<name>"
PID 26384  established=0
PID 36248  established=0
PID 17012  established=0
PID 40464  established=0
PID 8424   established=0

Those six were alive, each with a real console (a conhost.exe child) and each having written its peer key:

~/.claude/sessions/26480.<hash>.key      <- created
~/.claude/sessions/26480.json            <- never created

A clean probe with no --resume, in an already-trusted directory, does reach the network:

claude --remote-control "rc-probe"
PID 37060  established=5   -> 160.79.104.10:443

but it also never writes <pid>.json and never shows up in the session list. So the process talks to Anthropic and still does not become a usable RC session.

Expected behaviour

• --remote-control should either complete registration without a running Desktop, or fail loudly and exit non-zero, saying registration is unavailable and why.
• A session that cannot register should not sit there looking alive. Right now the only way to tell is to compare TCP connection counts per PID against a known-good session.
• Bonus, and probably the real fix: sessions spawned by Desktop should not die when the package is torn down for an update, or should be respawned after it.

Why this one matters more than the launch failure alone

The launch failure is recoverable by anyone standing at the keyboard. This turns it into a remote lockout: no autostart entry ships for Desktop, so even a reboot does not bring the sessions back on its own, and without auto-logon a remote reboot strands the machine at the lock screen with nothing running at all.

Related: #94432, #95266, #95353, #95588, #95901