[BUG] Bug Report: Claude Desktop for Windows — Update fails to register due to stale background processes ("still running" deferred-registration loop)

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: Claude Desktop for Windows — Update fails to register due to stale background processes ("still running" deferred-registration loop)

Note: This report was generated by Claude (Anthropic's AI assistant) after walking through a live troubleshooting session with the affected user. It compiles the diagnostic steps, log evidence, and root-cause hypothesis produced during that conversation. It is not an automated crash report — every step below was manually reproduced and confirmed by the user on their own machine.

Summary

An in-app auto-update of Claude Desktop for Windows (from 1.18286.x to 1.19367.0.0) failed to complete registration. The app became unable to launch. The failure was traced, via Microsoft-Windows-AppXDeploymentServer/Operational event logs, to the AppX deployment system repeatedly deferring registration because the previous version's package was still considered "running", even after the user had closed the application window (and, in one attempt, after a full PC restart).

A full uninstall → clean registry/folder cleanup → fresh install resolved the issue immediately, with no further errors on reinstall.

Environment

• OS: Windows (build not explicitly captured; standard consumer install)
• App: Claude Desktop for Windows
• Package family: Claude_pzs8sxrjxfjjc
• Affected versions: update path Claude_1.18286.0.0 → Claude_1.18286.2.0 → Claude_1.19367.0.0
• Install method: direct MSIX installer from claude.ai/download (not Microsoft Store)

Timeline of symptoms

1. User applied an in-app auto-update. Afterward, Claude Desktop would not launch.
2. Closing and reopening the app did not help.
3. Restarting the PC did not help either — this ruled out a simple zombie-process issue and pointed to something persisting at the package-registration level.
4. Signing out and back in to the Windows user session eventually allowed the app to launch — but during that same launch, an unrelated third-party process (QuickShareCore.exe, belonging to SAMSUNGELECTRONICSCoLtd.SamsungQuickShare, a pre-existing/independent MSIX package on the machine, unrelated to Anthropic) crashed with Exception Processing Message 0xc0000005 - Unexpected parameters. This is very likely an unrelated, pre-existing instability on the machine that happened to surface when the shared Windows AppX Deployment subsystem (Appxsvc) cycled through a stop/start transition — not something triggered by Claude's installer directly. Flagged here only for completeness, since it was investigated at length before being ruled out as coincidental.
5. A full uninstall + cleanup + reinstall (see below) completed with no errors at all, confirming the update-over-existing-install path was the actual point of failure — not the installer package itself.

Root cause (from event log evidence)

Pulled via:

Get-WinEvent -LogName "Microsoft-Windows-AppXDeploymentServer/Operational" -MaxEvents 50 | Where-Object {$_.TimeCreated -gt (Get-Date).AddHours(-6)} | Format-List TimeCreated, Id, Message

Key excerpts:

15:01:40  Id 404   AppX Deployment operation failed for package Claude_1.18286.2.0_x64__pzs8sxrjxfjjc
          with error 0x80073D02: Unable to install because the following apps need to be closed
          Claude_1.18286.0.0_x64__pzs8sxrjxfjjc.

15:01:40  Id 638   Packages were not updated because affected apps are still running.
          Running apps: {Claude_pzs8sxrjxfjjc!Claude}

15:05:52  Id 658   Marking package {Claude_1.19367.0.0_x64__pzs8sxrjxfjjc} for deferred registration
          because {Claude_1.18286.0.0_x64__pzs8sxrjxfjjc} is still running.

Interpretation: Windows' AppX Deployment service considered the previous version of Claude Desktop "still running" and repeatedly deferred registration of the new package version — even after the visible application window was closed, and even after a full system restart. This strongly suggests that closing the Claude Desktop window does not fully terminate all associated background processes/services (e.g. any companion helper processes such as a Cowork service host or a native messaging host process used for browser integration), and that one or more of these keeps the package "alive" from the OS's perspective, blocking clean in-place registration of the update.

Only an Appxsvc service lifecycle cycle (observed at 15:11:06 and 15:18:24, coinciding with a Windows sign-out/sign-in) was enough to clear the deferred state — a restart alone was not.

Why a clean reinstall "fixes" it

Uninstalling removes the old package registration entirely, so there is no "still running" prior version for the deployment service to wait on. This is a workaround, not a fix — it avoids the update path rather than resolving the defect in it.

Suggested fix direction

• On update, the installer/updater should ensure all processes belonging to the package (not just the main window/process) are fully terminated before requesting registration of the new version — including any long-lived helper/service processes that may auto-respawn (services, native messaging hosts, etc.).
• Alternatively, the update flow should not depend on window-close as a proxy for "app fully stopped"; it should explicitly quiesce/stop any companion processes before requesting deployment.
• Consider surfacing a clearer in-app error/notification when an update is stuck in deferred registration, rather than failing silently until a session sign-out/sign-in or full reinstall is performed.

Reproduction steps

1. Have an existing Claude Desktop install running normally.
2. Let it auto-update in-app.
3. Close the app window normally (not via Task Manager force-kill).
4. Attempt to relaunch — app fails to start.
5. Restart the PC — issue persists.
6. Sign out and sign back in to Windows — app may launch, but update/registration state was clearly stuck per the AppX event log until this point.
7. As a workaround: fully uninstall (Get-AppxPackage *Claude* | Remove-AppxPackage), remove %LOCALAPPDATA%\AnthropicClaude and %LOCALAPPDATA%\Packages\Claude_*, then reinstall from claude.ai/download. This completes with no errors.

Attachments / evidence available on request

• Full 50-event AppXDeploymentServer/Operational log export (timestamps, event IDs, and messages as quoted above)
• Screenshot of the unrelated QuickShareCore.exe crash dialog encountered mid-investigation (included for completeness, not believed to be causally related)

What Should Happen?

Bug Report: Claude Desktop for Windows — Update fails to register due to stale background processes ("still running" deferred-registration loop)

Note: This report was generated by Claude (Anthropic's AI assistant) after walking through a live troubleshooting session with the affected user. It compiles the diagnostic steps, log evidence, and root-cause hypothesis produced during that conversation. It is not an automated crash report — every step below was manually reproduced and confirmed by the user on their own machine.

Summary

An in-app auto-update of Claude Desktop for Windows (from 1.18286.x to 1.19367.0.0) failed to complete registration. The app became unable to launch. The failure was traced, via Microsoft-Windows-AppXDeploymentServer/Operational event logs, to the AppX deployment system repeatedly deferring registration because the previous version's package was still considered "running", even after the user had closed the application window (and, in one attempt, after a full PC restart).

A full uninstall → clean registry/folder cleanup → fresh install resolved the issue immediately, with no further errors on reinstall.

Environment

• OS: Windows (build not explicitly captured; standard consumer install)
• App: Claude Desktop for Windows
• Package family: Claude_pzs8sxrjxfjjc
• Affected versions: update path Claude_1.18286.0.0 → Claude_1.18286.2.0 → Claude_1.19367.0.0
• Install method: direct MSIX installer from claude.ai/download (not Microsoft Store)

Timeline of symptoms

1. User applied an in-app auto-update. Afterward, Claude Desktop would not launch.
2. Closing and reopening the app did not help.
3. Restarting the PC did not help either — this ruled out a simple zombie-process issue and pointed to something persisting at the package-registration level.
4. Signing out and back in to the Windows user session eventually allowed the app to launch — but during that same launch, an unrelated third-party process (QuickShareCore.exe, belonging to SAMSUNGELECTRONICSCoLtd.SamsungQuickShare, a pre-existing/independent MSIX package on the machine, unrelated to Anthropic) crashed with Exception Processing Message 0xc0000005 - Unexpected parameters. This is very likely an unrelated, pre-existing instability on the machine that happened to surface when the shared Windows AppX Deployment subsystem (Appxsvc) cycled through a stop/start transition — not something triggered by Claude's installer directly. Flagged here only for completeness, since it was investigated at length before being ruled out as coincidental.
5. A full uninstall + cleanup + reinstall (see below) completed with no errors at all, confirming the update-over-existing-install path was the actual point of failure — not the installer package itself.

Root cause (from event log evidence)

Pulled via:

Get-WinEvent -LogName "Microsoft-Windows-AppXDeploymentServer/Operational" -MaxEvents 50 | Where-Object {$_.TimeCreated -gt (Get-Date).AddHours(-6)} | Format-List TimeCreated, Id, Message

Key excerpts:

15:01:40  Id 404   AppX Deployment operation failed for package Claude_1.18286.2.0_x64__pzs8sxrjxfjjc
          with error 0x80073D02: Unable to install because the following apps need to be closed
          Claude_1.18286.0.0_x64__pzs8sxrjxfjjc.

15:01:40  Id 638   Packages were not updated because affected apps are still running.
          Running apps: {Claude_pzs8sxrjxfjjc!Claude}

15:05:52  Id 658   Marking package {Claude_1.19367.0.0_x64__pzs8sxrjxfjjc} for deferred registration
          because {Claude_1.18286.0.0_x64__pzs8sxrjxfjjc} is still running.

Interpretation: Windows' AppX Deployment service considered the previous version of Claude Desktop "still running" and repeatedly deferred registration of the new package version — even after the visible application window was closed, and even after a full system restart. This strongly suggests that closing the Claude Desktop window does not fully terminate all associated background processes/services (e.g. any companion helper processes such as a Cowork service host or a native messaging host process used for browser integration), and that one or more of these keeps the package "alive" from the OS's perspective, blocking clean in-place registration of the update.

Only an Appxsvc service lifecycle cycle (observed at 15:11:06 and 15:18:24, coinciding with a Windows sign-out/sign-in) was enough to clear the deferred state — a restart alone was not.

Why a clean reinstall "fixes" it

Uninstalling removes the old package registration entirely, so there is no "still running" prior version for the deployment service to wait on. This is a workaround, not a fix — it avoids the update path rather than resolving the defect in it.

Suggested fix direction

• On update, the installer/updater should ensure all processes belonging to the package (not just the main window/process) are fully terminated before requesting registration of the new version — including any long-lived helper/service processes that may auto-respawn (services, native messaging hosts, etc.).
• Alternatively, the update flow should not depend on window-close as a proxy for "app fully stopped"; it should explicitly quiesce/stop any companion processes before requesting deployment.
• Consider surfacing a clearer in-app error/notification when an update is stuck in deferred registration, rather than failing silently until a session sign-out/sign-in or full reinstall is performed.

Reproduction steps

1. Have an existing Claude Desktop install running normally.
2. Let it auto-update in-app.
3. Close the app window normally (not via Task Manager force-kill).
4. Attempt to relaunch — app fails to start.
5. Restart the PC — issue persists.
6. Sign out and sign back in to Windows — app may launch, but update/registration state was clearly stuck per the AppX event log until this point.
7. As a workaround: fully uninstall (Get-AppxPackage *Claude* | Remove-AppxPackage), remove %LOCALAPPDATA%\AnthropicClaude and %LOCALAPPDATA%\Packages\Claude_*, then reinstall from claude.ai/download. This completes with no errors.

Attachments / evidence available on request

• Full 50-event AppXDeploymentServer/Operational log export (timestamps, event IDs, and messages as quoted above)
• Screenshot of the unrelated QuickShareCore.exe crash dialog encountered mid-investigation (included for completeness, not believed to be causally related)

Error Messages/Logs

Exception Processing Message 0xc0000005 - Unexpected parameters.

Steps to Reproduce

1. Have an existing Claude Desktop install running normally on Windows.
2. Let it auto-update in-app (observed update path: Claude_1.18286.0.0 → Claude_1.18286.2.0 → Claude_1.19367.0.0).
3. Close the app window normally (not via Task Manager force-kill).
4. Attempt to relaunch — app fails to start.
5. Restart the PC — issue persists (this rules out a simple zombie-process/reboot fix).
6. Sign out and sign back in to Windows — app may launch, but the AppX event log shows the update was stuck in deferred registration until this point.
7. Workaround that resolves it cleanly: fully uninstall the app, remove leftover folders, then reinstall from claude.ai/download. This completes with no errors.

Uninstall/cleanup commands used (run as Administrator):

Get-Process claude -ErrorAction SilentlyContinue | Stop-Process -Force
Get-AppxPackage Claude | Remove-AppxPackage
Remove-Item -Recurse -Force "$env:LOCALAPPDATA\AnthropicClaude" -ErrorAction SilentlyContinue
Remove-Item -Recurse -Force "$env:LOCALAPPDATA\Packages\Claude_*" -ErrorAction SilentlyContinue

Diagnostic command used to confirm root cause via Windows event log:

Get-WinEvent -LogName "Microsoft-Windows-AppXDeploymentServer/Operational" -MaxEvents 50 | Where-Object {$_.TimeCreated -gt (Get-Date).AddHours(-6)} | Format-List TimeCreated, Id, Message

Relevant log excerpt

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.18286.0.0

Claude Code Version

N/A — this is a Claude Desktop (Windows) installer/update issue, not a Claude Code CLI issue. Affected Desktop app version: 1.19367.0.0 (update target); previous working version: 1.18286.0.0.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_