[BUG] Claude Desktop Windows enters "Modified, NeedsRemediation" AppX state after failed update deployment

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?

Claude Desktop on Windows repeatedly becomes unable to launch after entering an AppX package state of Modified, NeedsRemediation.

When the issue occurs, Windows displays:

"This app can't be opened. There's a problem with Claude. Reinstall the application from its original location or contact your administrator."

The problem has recurred more than five times across multiple Claude Desktop versions and installation methods.

Deployment logs show update attempts occurring, followed by deployment failures with 0x80073D02 because Claude is still running. After these events, the package eventually transitions into Modified, NeedsRemediation.

What Should Happen?

Claude Desktop should either:

• successfully update to the newer package version, or
• cleanly abort the update and leave the currently installed version functional.

A failed update attempt should not leave the application in a state where Windows reports Modified, NeedsRemediation and the application becomes unable to launch.

Error Messages/Logs

0x80073D02

The package could not be installed because the following app must be closed: Claude

The affected app is still running, therefore the package was not updated.

Deployment aborted due to active service:
Claude_pzs8sxrjxfjjc!Claude


updateList:
Claude_1.13576.4.0_x64__pzs8sxrjxfjjc
is updating to
Claude_1.14271.0.0_x64__pzs8sxrjxfjjc


Status : Modified, NeedsRemediation

Steps to Reproduce

1. Install Claude Desktop on Windows 10.

1. Launch Claude Desktop.

1. Use the application normally or leave it running/minimized.

1. At some later point:

• Claude may suddenly lose connectivity and stop functioning, or
• Claude may become unusable immediately after a reinstall.

1. Attempt to relaunch Claude.

1. Windows reports that the application cannot be opened.

1. Run:

Get-AppxPackage -AllUsers Claude

1. Observe:

Status : Modified, NeedsRemediation

The issue is not reliably reproducible on demand, but has occurred more than five times across multiple versions.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.13576.4.0

Claude Code Version

Claude Code Version: 1.13576.4.0

Platform

Other: claude.ai consumer subscription (Pro/Max) via Claude Desktop app

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

[BUG] Claude Desktop for Windows — Recurring "Modified, NeedsRemediation" AppX Package State, Persists After Disabling Auto-Updates

Summary

Claude Desktop on Windows repeatedly enters a corrupted package state and fails to launch with:

"This app can't be opened. There's a problem with Claude. Reinstall the application from its original location or contact your administrator."

Get-AppxPackage consistently reports Status : Modified, NeedsRemediation for the package at the time of failure. This has recurred 5+ times over several days, across multiple package versions, through multiple installation methods, and persists even after disabling auto-updates via the official registry policy.

Environment

• OS: Windows 10, build 19045, Korean language edition
• Package: Claude_pzs8sxrjxfjjc
• Versions observed: 1.13576.0.0, 1.13576.1.0, 1.13576.4.0, 1.14271.0.0
• Install methods tried: standard ClaudeSetup.exe, and direct .msix install via Add-AppxPackage

Timeline / Reproduction History

1. Repeated install failures with the generic "this app can't be opened" error.
2. Full clean uninstall + reinstall temporarily fixes it; corruption returns after the app is minimized/idle for a while.
3. At one point, two package versions were found coexisting: 1.13576.0.0 (Modified, NeedsRemediation) and 1.13576.1.0 (stuck in Servicing/Staged, SYSTEM-only). Both removed and reinstalled.
4. Switched from ClaudeSetup.exe to direct MSIX install — same corruption recurred on a newer version (1.14271.0.0).
5. Disabled auto-updates via the official policy:

``powershell
New-Item -Path "HKLM:\SOFTWARE\Policies\Claude" -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Claude" -Name "disableAutoUpdates" -Value 1 -Type DWord
`
Confirmed set (disableAutoUpdates : 1`).

1. Removed the corrupted 1.14271.0.0 package; a previously-hidden, healthy 1.13576.4.0 (Status : Ok) was revealed underneath.
2. After a healthy package state (Status : Ok) was observed, the package later returned to Modified, NeedsRemediation despite the disableAutoUpdates policy being set. The exact triggering event has not yet been captured.

Additional User-Observed Failure Patterns

The failure does not always occur at the same point in the lifecycle.

Pattern A — Immediate Failure After Install

Sometimes after a successful reinstall:

Install succeeds
↓
Claude launches
↓
Claude reports it cannot connect
↓
Start Menu shortcut briefly highlights/darkens when clicked
↓
Windows displays: "This app can't be opened"
↓
Get-AppxPackage reports: Modified, NeedsRemediation

Pattern B — Delayed Failure During Normal Use

Other times:

Install succeeds
↓
Claude operates normally
↓
Minutes or hours later
↓
Connection suddenly appears to drop
↓
Claude becomes unresponsive or exits
↓
Cannot relaunch
↓
Get-AppxPackage reports: Modified, NeedsRemediation

This suggests the issue is not limited to installation time and may occur during a later background operation.

Deployment-log evidence presented below confirms that update-deployment activity was occurring during the same general time period. However, direct causation between those deployment events and the eventual transition to Modified, NeedsRemediation has not yet been conclusively established.

Diagnostic Findings

AppX Deployment Log (Microsoft-Windows-AppXDeploymentServer/Operational)

• Confirmed update attempts are still initiated despite disableAutoUpdates = 1:

``
updateList:
Claude_1.13576.4.0_x64__pzs8sxrjxfjjc is updating to Claude_1.14271.0.0_x64__pzs8sxrjxfjjc
`
Download source: https://downloads.claude.ai/releases/...`

• Update deployment fails with:

``
0x80073D02
The package could not be installed because the following app must be closed: Claude
The affected app is still running, therefore the package was not updated.
Deployment aborted due to active service: Claude_pzs8sxrjxfjjc!Claude
``

• Several events reference CoworkVMService being stopped/terminated during deployment attempts.
• No AppX integrity/hash-mismatch/corruption events were found in this log — the corruption does not appear to stem from external file tampering.

Process Investigation

• While Claude Desktop was running normally, Get-Process claude showed 9 processes — all launched from the same version path (...\Claude_1.13576.4.0_x64__pzs8sxrjxfjjc\app\Claude.exe). No evidence of two different package versions running simultaneously (multi-process count is consistent with normal Electron architecture).
• A duplicate Claude tray icon was observed once during a reinstall cycle; process inspection at a different time did not corroborate a true dual-instance/dual-version run. This remains unexplained — possibly a transient Electron/tray UI artifact rather than an actual conflict.
• Get-ScheduledTask found no Claude- or AppInstaller-related scheduled tasks, ruling out a classic Task Scheduler-based background updater as the trigger.

Current Leading Theory

Claude running (package version N)
↓
Background update to version N+1 is attempted (despite disableAutoUpdates policy)
↓
Windows blocks replacement because the app/service is still active (0x80073D02)
↓
Deployment is aborted, but package registration state is left inconsistent
↓
Subsequent Get-AppxPackage queries report: Modified, NeedsRemediation

Open Questions for Anthropic

1. Does the HKLM:\SOFTWARE\Policies\Claude\disableAutoUpdates registry policy actually gate the background update-check/download process, or only an in-app prompt? Logs show update attempts continuing after this was set.
2. Is there a known issue where a failed/aborted MSIX deployment (blocked by 0x80073D02 because the app is running) leaves the package in a Modified state rather than cleanly failing and leaving the prior version intact?
3. What is CoworkVMService's role in blocking package replacement, and is it expected to release its hold before an update attempt?
4. Is a transition from Status : Ok to Status : Modified, NeedsRemediation expected behavior after a deployment is aborted by 0x80073D02? Or would Anthropic consider that package-state transition itself a bug?

Data Safety Note (for other users hitting this)

Throughout all of the above, local Claude Code session history (~/.claude/projects/*.jsonl) and account-level usage stats remained fully intact. Only the desktop app's ability to launch was affected — no user data was lost.

Steps Already Attempted (none fully prevented recurrence)

• Multiple full uninstall/reinstall cycles
• Deleting %LOCALAPPDATA%\AnthropicClaude, %APPDATA%\Claude, %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc
• Reboots between attempts
• Enabling Windows Developer Mode / Trusted App Installs
• Force re-registering all AppX packages (Add-AppxPackage -DisableDevelopmentMode -Register)
• sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth
• Switching from EXE installer to direct MSIX install
• Disabling auto-updates via the official registry policy