[BUG] Windows MSIX: desktop auto-update hangs explorer.exe; taskbar never comes back until reboot

Preflight Checklist

• [x] I have searched existing issues. The closest are #89660, #89687 and #83932, where an update or repair-register kills the Claude app or leaves it unable to launch. This report is different: the update hung the Windows shell itself (explorer.exe), not just the app.
• [x] This is a single bug report
• [x] I am using the latest version (Claude Desktop 2.26454.0.0, which is the version this update installed)

What's Wrong?

When the Claude desktop app (MSIX install) updated itself overnight, Windows Explorer stopped responding at the exact second the old package was taken down for servicing. Windows closed Explorer as "not responding" and it was never restarted, leaving a desktop with no taskbar. Task Manager would not open either. Only a full restart recovered the machine.

Timeline (local time, UTC+1, 7 October 2026)

| Time | Source | Event |
|---|---|---|
| 00:58:32 | AppXDeploymentServer 603 | RegisterByPackageFamilyName started for Claude_pzs8sxrjxfjjc with ForceApplicationShutdownOption |
| 00:59:03 | AppXDeploymentServer 10000 | "About to service package Claude_2.19675.1.0 … setting the package state to disabled" |
| 00:59:03 | Application Hang 1002 | explorer.exe "stopped interacting with Windows and was closed" |
| 00:59:03 | CoworkVMService | "Claude VM Service: failed to disarm SCM recovery actions for this stop…", then "Claude VM Service stopped." |
| 00:59:04 | Service Control Manager 7045 | "Claude Service" installed from the new package |
| 00:59:04 | CoworkVMService | "failed to configure SCM recovery actions; if the service crashes it stays down…" |
| 00:59:04 | AppXDeploymentServer 400 | Register operation for Claude_2.26454.0.0 finished successfully (32.1 s overall) |
| 01:00:10 | Application Hang 1002 | TextInputHost.exe (MicrosoftWindows.Client.CBS, InputApp) stopped responding and was closed |

Explorer was not relaunched after 00:59:03: no Winlogon "shell stopped unexpectedly and userinit.exe was restarted" event followed. On the previous day the same event appeared each time Explorer was terminated. The machine stayed without a taskbar until it was restarted at 10:42.

What Should Happen?

The update completes without hanging Explorer. If Explorer does hang and get closed, the taskbar comes back without a reboot.

Error Messages/Logs

• Explorer: event AppHangB1, consent key AppHangXProcB1 (a cross-process hang, meaning it was waiting on another process), hang type 0x200000, hang signature 6048. WER bucket 42584f0875bf0144933155a049357d1b (legacy 1382980707490823451), report ID 1f3c97f9-7792-4f40-b418-2429b804e921.
• TextInputHost: event MoAppHang, consent key AppHangXProcB1, hang signature 433a. WER bucket 5f478e784a5a1b4729fe27dfce8c76a2 (legacy 1872978337229207202).
• No dump or wait chain was captured, so the process Explorer was waiting on isn't recorded. The timing points at the Claude app being force-shut-down for servicing.

Steps to Reproduce

1. Install Claude Desktop (MSIX) on Windows 11 26H2 and leave it running.
2. Let the in-app auto-update install a new version. Here it was 2.19675.1.0 → 2.26454.0.0 at about 00:58 local time.
3. At the moment the old package is disabled for servicing, explorer.exe hangs, is closed by Windows, and is not restarted.

It is not reliable: 2 of the last 4 Claude package registrations on this machine coincided with a shell hang. The other was on 6 October at 13:29, when Claude was installed in a freshly created local account; that session then hung on sign-out and needed a hard reset (user-reported, no hang report captured). The updates on 2 October (20:30) and 6 October (01:18) caused no logged shell problems.

Claude Model

Not applicable

Is this a regression?

I don't know

Claude Code Version

Claude Desktop 2.26454.0.0 (bundled Claude Code 2.1.289)

Platform

Other (Claude Desktop with a claude.ai account)

Operating System

Windows 11 Pro 26H2, OS build 10.0.26300 (explorer.exe 10.0.26100.9444)

Terminal/Shell

Other (Claude Desktop app)

Additional Information

• The update itself succeeded, and the package state repository was healthy afterwards: two other package updates at 09:15 completed in under a second.
• No driver, GPU or kernel errors were logged around 00:59. The BlueScreen / LiveKernelEvent WER entries at the same second are reports from July being re-queued, not new events.
• Workaround: Ctrl+Alt+Del, then Sign out (or Restart).