[BUG] MSIX/Microsoft Store install quits for auto-update but never relaunches

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

On a Windows MSIX (Microsoft Store) install, the auto-updater quits the app to apply an update but nothing restarts it afterwards. The app simply stays closed - in my case for close to 12 hours - until I manually launch it again. Because the quit is clean and intentional, there is no crash dialog and nothing in the Windows Application event log, so from the user's side it just looks like "Claude closed itself overnight again."

This has happened on every multi-hour absence I have logs for. It correlates with being away from the machine, which makes sense if the updater waits for an idle moment to apply the update.

Related but distinct from #93003: that report describes the app hanging and refusing to launch at all (even manually) until a full reboot, with Windows hang (HamLkd) events. Mine shows no hang and no crash - the app quits cleanly (beforeQuitForUpdate fires normally) and manual relaunch afterward always works fine immediately, no reboot needed. It just never relaunches itself.

The checklist item above about using the latest version of Claude Code doesn't map cleanly onto this - this is a Claude Desktop (Electron/MSIX) bug, not a CLI bug - but Claude Code sessions running inside the app are what get killed when this happens, so I'm filing it here.

What Should Happen?

beforeQuitForUpdate quits the app, the update is applied, and the app comes back on its own - the stealth-relaunch machinery already saves z-order and navigation history specifically so the restored window looks like it never left. Either the app should perform the relaunch after an MSIX update the way the non-Store path does, or - if the Store genuinely cannot be restarted programmatically from within the app - the update should be deferred until the next natural launch instead of quitting a running app to apply it.

Error Messages/Logs

From %LOCALAPPDATA%\Claude\logs\main.log:

2026-09-10 21:15:12 [info] [stealth-relaunch] Saved z-order anchor: 0x1c05cc
2026-09-10 21:15:12 [info] [stealth-relaunch] Saved navigation history (3 entries, active=2)
2026-09-10 21:15:12 [info] Stopping shell PTY for session <redacted>
2026-09-10 21:15:13 [info] beforeQuitForUpdate handler fired, going down for update

        <<< app is not running for 11h43m -- no further log lines >>>

2026-09-11 08:58:02 [info] Starting app {
  appVersion: '1.52386.0',
  isPackaged: true,
  platform: 'win32',
  arch: 'x64',
  nodeVersion: '24.20.0'
}
2026-09-11 08:58:03 [info] [CCD] Initialized with version 2.1.266
2026-09-11 08:58:03 [info] [updater] Version changed since last launch: 1.49585.0 -> 1.52386.0
2026-09-11 08:58:03 [info] [CCD-autoupdate] Disabled: MSIX install
2026-09-11 08:58:03 [info] [updater] MSIX detected: windowsStore=true, appPathMatch=true, source=windowsStore
2026-09-11 08:58:03 [info] [stealth-relaunch] Loaded z-order anchor: 0x1c05cc
2026-09-11 08:58:03 [info] [event-loop-stall] update relaunch (stale marker) stands in for an unheard suspend

The 08:58 lines are from me launching the app manually, not from any automatic restart.

Steps to Reproduce

This isn't a user-triggered sequence - it's a timing/environmental bug that shows up whenever an update lands while the app is left running unattended.

Step 1: Leave the Claude desktop app (MSIX/Store install) running and step away from the machine for several hours.
Step 2: At some point the auto-updater decides to apply a pending update and calls beforeQuitForUpdate, which quits the app cleanly (visible in main.log).
Step 3: The update installs in the background (no window, no prompt).
Step 4: The app does not relaunch itself. It stays closed indefinitely.
Step 5: The only way to get it running again is to manually double-click the icon/shortcut - at which point it opens normally, on the new version, with no issues.

Every gap below is one "Saved z-order anchor" (going down for update) paired with the next "Loaded z-order anchor" (me manually reopening it):

App quit -> Next launch -> Down for
2026-09-04 23:40 -> 2026-09-09 10:47 -> ~4.5 days (a weekend away from the machine)
2026-09-09 14:34 -> 2026-09-10 15:04 -> ~24h
2026-09-10 21:15 -> 2026-09-11 08:58 -> ~11h45m

It correlates with being away from the machine, consistent with the updater waiting for an idle moment to apply the update, then never following through on bringing the app back.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

N/A - Desktop app bug, not the claude CLI. Claude Desktop: 1.52386.0 (updated from 1.49585.0). CCD: 2.1.266.

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Environment

Install type: MSIX / Windows Store (C:\Program Files\WindowsApps\Claude_<version>_x64__<pubhash>)
OS: Windows Server 2022 Datacenter 10.0.20348, x64
Runtime: Electron, node 24.20.0, win32 x64
Host: Amazon WorkSpaces VDI (persistent - never stops, so this isn't AutoStop tearing the session down)

Ruled out

Not a machine reboot - uptime at time of writing is 26 days, spanning all three quit/relaunch gaps.
Not a Windows logoff or session teardown - the interactive session has been continuous for 25 days; no 4634/4647/23 events.
Not a crash - no Application Error (1000), Application Hang (1002) or WER (1001) entries for the app; beforeQuitForUpdate shows a deliberate, graceful exit. This is the main way this differs from #93003, which shows HamLkd hang events and needs a full reboot to recover - mine never hangs and manual relaunch always works immediately.

Impact

Anything in flight is lost from the user's point of view - running Claude Code sessions stop, and because the exit is silent there is no indication the app updated rather than crashed. On a shared/VDI machine where people leave work open overnight, this is a daily papercut.

Note: paths, session ids and machine names redacted. <pubhash> is Claude's own MSIX publisher hash and is identical for every install.