[BUG] Windows: Claude Desktop MSIX package reverts to Modified, NeedsRemediation within minutes of clean install; Repair impossible due to CoworkVMService

Status Closed — duplicate
Maintainer reply None cached
Activity 4 comments · opened Aug 11, 2026 · closed Aug 15, 2026

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?

Summary

On Windows 11, the Claude Desktop MSIX package (Claude 1.26832.0.0) enters a Modified, NeedsRemediation state within minutes of a clean install and the app fails to launch. Every non-destructive remedy fails. Reproduced across three separate clean installs over four days.

Steps to reproduce

  1. Install Claude Desktop for Windows from claude.com/download
  2. Use the app normally (Cowork and Code sessions)
  3. Within minutes to hours, the app fails to launch with the Windows MSIX error directing the user to Settings > Apps > Advanced options > Repair
  4. Get-AppxPackage *laude* | Select Status returns Modified, NeedsRemediation

Why Repair cannot succeed

CoworkVMService runs as SYSTEM with Automatic startup. Observed behaviour:

  • Stopping the service via Stop-Service CoworkVMService -Force works, but the service restarts during the repair operation itself, so Repair reports "We couldn't repair this app because it's currently running" even when the service is confirmed Stopped immediately before clicking Repair.
  • Set-Service CoworkVMService -StartupType Manual fails with Access is denied even from an elevated administrator prompt, apparently due to a hardened service security descriptor. The user therefore cannot prevent the restart.
  • On the attempt where the service stayed down, Repair failed with "We couldn't repair this app. Try again in a bit."
  • Add-AppxPackage -Register AppXManifest.xml completes without error but leaves Status unchanged at NeedsRemediation.

Net effect: the only remaining remedy is removing the package. Remove-AppxPackage -PreserveApplicationData fails with HRESULT 0x80073CFA because that flag only applies to development-mode deployments, so removal necessarily discards the app data container.

Impact

Removing the package destroys the working-directory bindings for existing sessions. After reinstall, every session prompts "Select folder for local session" before it will run. No warning is presented that following the remedy Windows itself recommends will have this effect.

Latest reinstall stayed functional for approximately 45 seconds before returning to NeedsRemediation.

Environment

  • Windows 11 (build 26100)
  • Claude Desktop Claude_1.26832.0.0_x64__pzs8sxrjxfjjc
  • Windows Defender only; no third-party antivirus; protection history shows no quarantine entries for Claude or WindowsApps
  • vmcompute and hns both Running
  • Single user session (query user confirms no second session)
  • Deployment ActivityId from a failed removal: 05569a82-2688-0007-a8c0-aa058826dd01

Requests

  1. Confirm whether CoworkVMService being Automatic with a restrictive security descriptor is intended, given it makes the documented Repair path unusable.
  2. Provide a supported non-destructive recovery path for NeedsRemediation.
  3. Warn users before package removal that working-directory bindings will be lost.

What Should Happen?

someone should get back to me instead of ignoring me

Error Messages/Logs

Steps to Reproduce

it shuts down in the middle of stuff

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Desktop for Windows 1.26832.0.0 Package: Claude_1.26832.0.0_x64__pzs8sxrjxfjjc

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗