### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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 (Windows MSIX, 1.32885.1.0) installs cleanly and verifies as Status: Ok. A single launch flips the package to "Modified, NeedsRemediation".

[BUG] Claude Desktop (Windows MSIX) transitions from Ok to Modified, NeedsRemediation on first launch, with no deployment event in any Windows log

Status Closed — duplicate

Reported on v2.1.231

Maintainer reply None cached

Activity 3 comments · opened Aug 20, 2026 · closed Aug 25, 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?

Claude Desktop (Windows MSIX, 1.32885.1.0) installs cleanly and verifies as
Status: Ok. A single launch flips the package to "Modified, NeedsRemediation".
The app window never appears. Windows Repair and Reset both fail.

The transition leaves no trace in any Windows log — not the Application log,
not AppXDeploymentServer/Operational, not Get-AppxLog. No claude.exe
Application Error, no WER report, no crash dump.

Full removal + reinstall restores Ok, and the next launch breaks it again.
An unbounded loop. Cowork is unusable as a result.

What Should Happen?

Launching the app should not invalidate its own package. Status should remain
Ok after launch, and Cowork should start.

If Windows does mark the package Modified, something should log why — currently
nothing does.

Error Messages/Logs

Get-AppxPackage -Name Claude   →  Status: Ok                         (before launch)
[launch once]
Get-AppxPackage -Name Claude   →  Status: Modified, NeedsRemediation (after launch)

Microsoft-Windows-AppModel-Runtime/Admin:
  17:24:44  210  Created Desktop AppX container for Claude_1.32885.1.0_x64__pzs8sxrjxfjjc
  17:24:44  201  Created process 6220 for Claude_pzs8sxrjxfjjc!Claude  [LaunchProcess]
  17:24:51  217  Destroyed Desktop AppX container

cowork-service.log (identical every session — configure never arrives):
  Claude VM Service starting...
  Waiting for configuration from app via 'configure' method...
  Service ready. Listening on \\.\pipe\cowork-vm-service

Steps to Reproduce

Reproduction
Clean removal: Remove-AppxPackage -AllUsers + Remove-AppxProvisionedPackage, reboot, verify both empty
Install via Claude Setup.exe as Administrator
Before launching: Get-AppxPackage -Name Claude → Status: Ok
Launch Claude Desktop once. Window does not appear.
Get-AppxPackage -Name Claude → Status: Modified, NeedsRemediation
Settings → Advanced options → Repair → "We couldn't repair this app. Try again in a bit."

100% reproducible across many cycles.

Evidence
Install succeeds
17:23:56 Event 400 Deployment Add operation ... finished successfully.
17:23:56 Event 613 Overall time: 25188 ms
Hardlinking evaluation cost: 235 ms
Stage required cost: 20906 ms
Machine register cost: 843 ms
17:23:56 Get-AppxPackage → Status: Ok

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.24012.9.0

Claude Code Version

2.1.231 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

<html>
<body>
<html><head></head><body><h1>[BUG] Claude Desktop (Windows MSIX) transitions from <code>Ok</code> to <code>Modified, NeedsRemediation</code> on first launch, with no deployment event in any Windows log</h1>
<h2>Preflight</h2>
<ul>
<li>[x] I have searched existing issues</li>
<li>[x] This is a single bug report</li>
<li>[x] Using the latest Claude Desktop release (1.32885.1.0)</li>
</ul>
<h2>Summary</h2>
<p>Claude Desktop installs cleanly and verifies as <code>Status: Ok</code>. A <strong>single launch</strong> flips the package to <code>Modified, NeedsRemediation</code>. Windows Repair and Reset both fail. Full removal and reinstall restores <code>Ok</code>, and the next launch breaks it again — an unbounded loop.</p>
<p>The transition leaves <strong>no trace in any Windows log</strong>: not the Application log, not <code>AppXDeploymentServer/Operational</code>, not <code>Get-AppxLog</code>. No <code>claude.exe</code> Application Error, no WER report, no crash dump.</p>
<p>Cowork is the reason I need the desktop app, so Claude web is not a workaround.</p>
<h2>Environment</h2>

|
-- | --
OS | Windows 11 Pro 25H2, build 26200.9168
Machine | Lenovo 81Q9 (LNVNB161216), BIOS AUCN54WW
CPU | Intel Core i7-1065G7 (Ice Lake)
GPU | Intel Iris Plus, driver 31.0.101.2141 (2026-03-30) — integrated only, no dGPU
RAM | 16 GB
Storage | Samsung MZVLB1T0HBLR NVMe
Display | 3840×2160 @ 60 Hz, 300% system DPI
Package | Claude_1.32885.1.0_x64__pzs8sxrjxfjjc, SignatureKind Developer
Last known good | 2026-07-21 (verified in coworkd log — full Cowork sessions, clean mounts and teardown)

<h3>Machine-specific anomaly</h3>
<p><code>C:\ProgramData\Microsoft\Windows\AppRepository</code> retains stale manifests:</p>
<pre><code>Claude_1.24012.1.0_x64__pzs8sxrjxfjjc.xml 2026-07-23 23:14
Claude_1.24012.9.0_x64__pzs8sxrjxfjjc.xml 2026-07-24 20:56
Claude_1.32885.1.0_x64__pzs8sxrjxfjjc.xml 2026-08-19 17:23
</code></pre>
<p>The two <code>1.24012.*</code> entries date to the interrupted-update window and have survived every <code>Remove-AppxPackage -AllUsers</code> and <code>Remove-AppxProvisionedPackage</code>. Since MSIX staging hardlinks against content it believes is already present, stale repository state may cause staging to skip content it thinks exists — which would explain why reinstalling never helps.</p>
<p><strong>This was tested and ruled out.</strong> See below.</p>
<h3>Windows in-place repair upgrade — performed, did not fix</h3>
<p>To eliminate machine-side servicing corruption, I ran a full in-place repair upgrade using the official Windows 11 25H2 en-US ISO (SHA-256 verified against Microsoft's published hash), with "Keep personal files and apps".</p>
<p>Before the upgrade, Claude was fully removed: <code>Remove-AppxPackage -AllUsers</code>, <code>Remove-AppxProvisionedPackage</code>, and deletion of <code>C:\ProgramData\Claude</code> and <code>%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc</code>. Only the two stale <code>1.24012.*</code> manifests remained in the AppRepository at that point.</p>
<p>After the upgrade:</p>
<pre><code class="language-powershell">Get-ChildItem 'C:\ProgramData\Microsoft\Windows\AppRepository' -Filter 'Claude' -Force

→ empty. Both stale manifests cleared. AppRepository rebuilt.

</code></pre>
<p>Then a clean install via <code>Claude Setup.exe</code> as Administrator:</p>
<pre><code>Get-AppxPackage -Name Claude → Status: Ok (before launch)
[launch once]
Get-AppxPackage -Name Claude → Status: Modified, NeedsRemediation (after launch)
</code></pre>
<p><strong>Identical failure on a rebuilt servicing stack and a clean AppRepository.</strong> The stale-manifest hypothesis is disproven, and with it every machine-side explanation available: antivirus, GPU driver, HVCI, Smart App Control, ACLs and ownership, Windows servicing updates, disk space, code-integrity catalogs, and repository corruption have all now been eliminated by direct test on this machine.</p>
<h2>Remediation attempted (all unsuccessful)</h2>
<p>Settings → Repair · Settings → Reset · <code>Remove-AppxPackage -AllUsers</code> + reinstall · <code>Remove-AppxProvisionedPackage</code> · <code>Add-AppxPackage -Register AppxManifest.xml</code> · <code>Add-AppxProvisionedPackage -Online -SkipLicense -Regions all</code> · install via <code>Claude Setup.exe</code> as admin · install via raw <code>.msix</code> · reboots between every attempt · GPU driver update (31.0.101.1999 → 31.0.101.2141) · deletion of <code>C:\ProgramData\Claude</code> and per-package LocalCache · <strong>Windows in-place repair upgrade (25H2 en-US ISO, keep files and apps)</strong> · verified VirtualMachinePlatform enabled, <code>vmcompute</code> / <code>hns</code> / <code>CoworkVMService</code> running</p>
<h2>Expected behaviour</h2>
<ol>
<li>Launching the app should not invalidate its own package.</li>
<li>If Windows marks the package <code>Modified</code>, something should say why — currently nothing does.</li>
<li>The installer should detect post-install <code>Modified, NeedsRemediation</code> rather than treating deployment <code>0x0</code> as success.</li>
<li><code>AppxMetadata\CodeIntegrity.cat</code> is referenced by Code Integrity at every launch but ships absent. Either include it or confirm it is intentional.</li>
<li>The packaged service should be able to configure its own SCM recovery actions.</li>
</ol>
<h2>Related</h2>
<ul>
<li>#84333 — silent <code>Modified, NeedsRemediation</code> with no deployment operation logged (closest match)</li>
<li>#83028 — same package state on Intel integrated graphics</li>
<li>#81747 — install "succeeds", package stuck in NeedsRemediation, Repair and Reset both fail</li>
<li>#83932 — auto-update deploying into running <code>claude.exe</code> / <code>cowork-svc.exe</code></li>
<li>#70700 — same end state traced to a Windows LCU (not applicable here; timeline rules it out)</li>
</ul>
<h2>Additional</h2>
<p>Full logs available on request: <code>AppXDeploymentServer/Operational</code>, <code>AppModel-Runtime/Admin</code>, <code>CodeIntegrity/Operational</code>, <code>cowork-service.log</code>, and the <code>coworkd</code> per-user log covering the last working session.</p>
<p>Disk note: <code>C:</code> had 16.9 GB free of 269 GB during the failing attempts (now 32.4 GB). Recorded in case staging headroom is relevant, though the failure occurs after staging completes successfully.</p></body></html>
</body>
</html>

View original on GitHub ↗

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