[BUG] Auto-updater re-deploys same version, freezes app, orphans running sessions (Windows/MSIX)

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?

Bug report: Desktop app auto-updater freezes app and orphans running sessions

Summary

The Claude desktop app's auto-updater attempted to "update" to the same
version already installed, froze and closed the app before the user pressed
"restart to update," then hung indefinitely on "downloading update...". The
half-staged update left the app unstable for the rest of the night: running
Claude Code sessions were orphaned with a "Remote Control disconnected" error,
moved to the "Other" sidebar group, and shown under an auto-generated codename.
A full reboot the next morning completed the stuck package registration and
returned the app to normal. This has happened at least twice (~Jul 31 and
Aug 5–6, twice in one night).

Environment

• Claude desktop app 1.25927.0 (MSIX, auto-updated from downloads.claude.ai;

package Claude_..._pzs8sxrjxfjjc)

• Windows 11 Pro, build 10.0.26200
• Claude Code engine versions present: 2.1.217 / 2.1.219 / 2.1.221
• Long-running session with multiple background subagents active overnight

Timeline (local time EDT, 2026-08-05 → 08-06, from Windows event logs and app logs)

| Time | Event | Evidence |
|---|---|---|
| Aug 4, 3:31 PM | v1.25927 installed normally | AppXDeploymentServer event 400: Add of Claude-003700ef...msix "finished successfully" |
| ~12:30 AM | App shows "restart to update"; before user clicks, app freezes and closes itself; then shows "downloading update..." indefinitely | User observation |
| 12:36 AM | App UI starts logging 404 "session not found" for its own running sessions | claude.ai-web.log: {"type":"not_found_error","statusCode":404,"resource_type":"session"} (two session IDs) |
| 12:51 AM | User message queued into dead session, never processed | Session .jsonl transcript ends with unprocessed queue-operation |
| 1:00 AM, 1:16 AM | User relaunches app twice | ssh.log "ClaudeSSHManager Initialized" entries |
| 1:01:01 AM & 1:17:17 AM | Updater starts deployment of Claude-003700ef...msix — the SAME package/hash already installed Aug 4 — with DeferRegistrationWhenPackagesAreInUse. Neither deployment ever logs completion. | AppXDeploymentServer event 603 ×2; no corresponding event 400 |
| 1:18–1:19 AM | UI repeatedly fails fetchOwnedEventsPageDescV2: 404 (CcrHttpError) | claude.ai-web.log |
| 1:22–1:39 AM | Fresh session works and completes the overnight run | Session transcript |
| ~8:15 AM | The finished session is again in "Remote Control disconnected" state | User observation + screenshot |
| 8:37 AM | User reboots as a fix attempt | System event 1074 (Start menu restart) |
| 8:38:31–8:39:03 AM | Stuck deployment finally completes: OnDemandRegisterOperation + Register on Claude_1.25927.0.0 "finished successfully" | AppXDeploymentServer events 10002/854/400 |

Expected behavior

• Updater should not attempt to deploy the version that is already installed.
• A pending/deferred update should not freeze or destabilize the running app.
• If a deployment cannot complete, sessions should survive or reattach instead

of being orphaned into "Other" with a codename and a "Remote Control
disconnected" error (misleading wording, too — the session was started in the
desktop app, not from a terminal).

Impact

• Running overnight multi-agent sessions were interrupted twice.
• Queued user messages were silently dropped.
• Orphaned sessions are no longer addressable (session-management search/list

cannot find them), though .jsonl transcripts on disk remain intact.

Notes

• No OS-level cause found: no reboot/sleep/OOM/app-crash events overnight;

Crashpad, Sentry queue, and Windows Error Reporting show no Claude crashes.

• Similar app relaunch clusters appear in ssh.log around 1–2 AM on Jul 31 and

Aug 2, suggesting earlier occurrences of the same loop.

What Should Happen?

The updater should not try to install the version that is already installed (it re-deployed the exact same 1.25927.0 MSIX package). A pending "restart to update" should not freeze or close the running app on its own, and if an update deployment cannot complete, it should not hang forever on "downloading update..." — it should fail cleanly and retry later. Running sessions should survive an updater problem or reconnect afterward, instead of being permanently orphaned with a "Remote Control disconnected" error, moved to the "Other" group, and renamed to a random codename. A full PC reboot should not be required to recover the app.

Error Messages/Logs

1) In-app error shown on the broken sessions:
"Remote Control disconnected — Your terminal's Claude Code session stopped responding. Check your terminal for errors, then resend your message."
(No terminal was involved — the session was started in the desktop app.)
2) %APPDATA%\Claude\logs\claude.ai-web.log — session records go 404 while the app is running:
2026-08-06 00:36:08 [error] [REACT_QUERY_CLIENT] QueryClient error: {"type":"not_found_error","statusCode":404,"extra":{"resource_id":"session_01GdsajRdMTiF3oYscxMWHzu","resource_type":"session"}}
2026-08-06 00:36:25 [error] [REACT_QUERY_CLIENT] QueryClient error: {"type":"not_found_error","statusCode":404,"extra":{"resource_id":"session_01DJ1Qoc9TcVPsHJrCRq2kGy","resource_type":"session"}}
2026-08-06 01:18:19 [error] [REACT_QUERY_CLIENT] QueryClient error: {"fnName":"fetchOwnedEventsPageDescV2","status":404,"name":"CcrHttpError","message":"fetchOwnedEventsPageDescV2: 404"}
(last line repeats at 01:18:23, 01:18:30, 01:18:36, 01:19:25)
3) Windows event log Microsoft-Windows-AppXDeploymentServer/Operational — updater starts deploying the SAME already-installed package twice, never completes:
8/6/2026 1:01:01 AM  Event 603: Started deployment Add operation on a package with main parameter Claude-003700efafbc2ccb4b1177a5e637b14da381799e.msix and Options NormalPriorityRequest and DeferRegistrationWhenPackagesAreInUse.
8/6/2026 1:17:17 AM  Event 603: (identical — second attempt)
(No "finished successfully" Event 400 follows either. The same MSIX had already been installed successfully on 8/4/2026 3:31:42 PM.)
4) Same log, immediately after PC reboot — the stuck update finally completes:
8/6/2026 8:38:32 AM  Event 400: Deployment OnDemandRegisterOperation ... on Package Claude_1.25927.0.0_x64__pzs8sxrjxfjjc finished successfully.
8/6/2026 8:39:03 AM  Event 400: Deployment Register operation ... (AppxManifest.xml) finished successfully.
5) Ruled out via Windows logs: no reboot/sleep between 1:39 AM and 8:37 AM, no OOM events, no app crash records in WER, Crashpad, or Sentry.

Steps to Reproduce

Not reliably reproducible on demand — it depends on when the auto-updater activates. The pattern observed (at least twice, ~Jul 31 and Aug 5-6):

1. Windows desktop app (MSIX install), long-running Claude Code sessions open in a project folder, background agents working.
2. Leave the app running when the auto-updater shows "restart to update".
3. Without clicking anything, the app freezes and closes itself, then reopens showing "downloading update..." indefinitely.
4. All previously running sessions are now orphaned: "Remote Control disconnected", moved to the "Other" sidebar group, renamed to a random codename. Messages sent to them are queued but never processed.
5. Relaunching the app does not fix it (the updater re-attempts the same deployment and hangs again).
6. Only a full PC reboot completes the stuck package registration and restores normal behavior.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown / possibly none recent. The current incident happened on 1.25927.0 (installed Aug 4), but app logs show the same symptom pattern (repeated app relaunches at ~1-2 AM with broken sessions) around Jul 31 on the previous version, 1.24012.11.0. So the issue spans at least these two versions.

Claude Code Version

Engine versions present in %APPDATA%\Claude\claude-code: 2.1.219 (in use during the incident) and 2.1.221 (downloaded after the reboot). Desktop app 1.25927.0.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Full timeline reconstructed from Windows event logs and app logs:

| Time (EDT) | Event |
|---|---|
| Aug 4, 3:31 PM | v1.25927 MSIX installed normally (AppX event 400, success) |
| Aug 5, ~12:30 AM | App shows "restart to update"; before user clicks, app freezes and closes itself; then "downloading update..." indefinitely |
| 12:36 AM | App UI starts logging 404 "session not found" for its own running sessions |
| 12:51 AM | User message queued into dead session, never processed (visible in the session's .jsonl transcript as an unprocessed queue-operation) |
| 1:00 AM, 1:16 AM | User relaunches app twice (ssh.log "ClaudeSSHManager Initialized") |
| 1:01 AM & 1:17 AM | Updater starts deploying the SAME already-installed MSIX (event 603, DeferRegistrationWhenPackagesAreInUse); neither ever completes |
| 1:22-1:39 AM | A freshly created session works normally and completes its run |
| ~8:15 AM | The finished session is again in "Remote Control disconnected" state |
| 8:37 AM | User reboots PC as a fix attempt |
| 8:38-8:39 AM | Stuck deployment completes (AppX events 400, success); app fully recovers |

Additional notes:

• Orphaned sessions become unaddressable by the app's session-management tools (list/search can no longer find them), though their .jsonl transcripts on disk remain intact.
• The "Remote Control disconnected" error text blames "your terminal's Claude Code session", but these sessions were started inside the desktop app - the wording sent troubleshooting in the wrong direction.
• Machine stayed awake all night: no sleep/reboot/OOM/crash events in Windows logs between 1:39 AM and the 8:37 AM manual reboot.