[BUG] Desktop (Windows/MSIX): after an auto-update the app hangs and closes itself, then silently refuses to launch until a full reboot

Preflight

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

On the Claude Desktop app for Windows (MSIX / Store package), some time after an auto-update the app window disappears on its own (the user never closed it), and from that point the app cannot be started again. Double-clicking the shortcut, the Start menu entry, or the taskbar icon does nothing at all - no window, no splash, no error dialog, no tray icon. It fails completely silently.

The only thing that fixes it is a full Windows restart. After a reboot the app launches normally again. Killing the visible window/processes by hand and retrying does not reliably help; the reboot is what clears it.

This has happened repeatedly, and it appears to follow an auto-update.

Evidence from an occurrence on 2026-09-08 / 09

The timestamps line up directly with an update:

| Time (local) | Event |
|---|---|
| 2026-09-08 22:08:20 | MSIX package files written - Claude_1.49585.0.0_x64__pzs8sxrjxfjjc\app created (auto-update installed) |
| 2026-09-08 22:23:02 | Windows Error Reporting HamLkd (application hang), Event ID 1001, ~15 min after the update |
| 2026-09-08 22:23:05 | Second HamLkd WER event |
| 2026-09-09 08:34 | After a manual reboot, the app starts normally again |

The same pairing shows up on an earlier occurrence: HamLkd hang events at 2026-09-04 09:39:43 / 09:39:46, with a bundled claude-code version directory (2.1.260) created at 09:48 the same morning.

HamLkd is the Windows hang-detection bucket, so Windows is classifying this as the app hanging, not crashing cleanly.

Suspected cause - a stale single-instance lock held by orphaned processes

This looks like a single-instance/lock problem rather than a plain crash:

• There is a lock file at %APPDATA%\Claude\lockfile (0 bytes), rewritten at each successful start.
• A healthy running instance has ~14 claude.exe processes (main + helpers).
• The app is an MSIX package, and an MSIX in-place update cannot replace files that are still in use, so the previous version's process tree can survive the update.

If even one orphaned process from the pre-update version survives the hang, it plausibly keeps holding the single-instance lock (or named mutex). A subsequent launch then detects "an instance is already running", tries to hand off/signal to that dead-or-hung instance, and exits silently - which is exactly the observed "nothing happens at all" behaviour. A reboot tears down the orphans, which is why only a restart fixes it.

Two things that make this hard to diagnose

1. No crash dump is captured. %APPDATA%\Claude\Crashpad\ contains only settings.dat - no reports for these hangs.
2. App logging appears to have stopped. Every file in %APPDATA%\Claude\logs\ (main.log, unknown-window.log, claude.ai-web.log, etc.) has a last-write time of 2026-08-21, weeks before these incidents, despite daily use. So there is no app-side log covering the failure at all. If logging silently stopped, that is arguably a second bug and it removes the main evidence trail for the first one.

What Should Happen?

• An auto-update should not leave the app in a state where it cannot be relaunched.
• Launching the app when a stale/orphaned instance holds the lock should either take over the lock and start, or surface an error explaining why it will not start. Exiting silently with no window and no message is the worst outcome, because the user has no way to tell the app even tried.
• If a previous instance must be superseded, the launcher should detect the stale lock (owner process gone or not responding) and reclaim it, so that a reboot is never required.
• Crash/hang telemetry should actually be captured for this failure, and app logging should not silently stop.

Environment

• Claude Desktop app 1.49585.0 (MSIX: Claude_1.49585.0.0_x64__pzs8sxrjxfjjc)
• Bundled claude-code versions present: 2.1.258, 2.1.260
• Windows 11 Pro, build 26200 (10.0.26200)
• Installed per-user under C:\Program Files\WindowsApps\, app data in %APPDATA%\Claude\

Workaround

Restart Windows. Nothing short of that has reliably restored the ability to launch the app.