Claude Desktop (Windows MSIX) bricks itself — package flagged "Modified" after Code Integrity blocks vk_swiftshader.dll

Claude Desktop (Windows MSIX) bricks itself — package flagged "Modified" after a Code Integrity block on vk_swiftshader.dll

Platform: Claude Desktop 1.32885.1.0, Windows 10 Pro 22H2 (19045), x64, sideloaded MSIX (Claude_1.32885.1.0_x64__pzs8sxrjxfjjc, SignatureKind=Developer). NVIDIA RTX 3070 (+ Parsec virtual display).

Symptom

After using the in-app browser preview (Claude Code "launch preview" / preview_start) on a Cloudflare-challenged page (a propertyguru.com.sg listing), Claude Desktop dies and from then on refuses to start with Windows' "This app can't open — try reinstalling" dialog. Get-AppxPackage Claude reports Status: Modified, NeedsRemediation. Windows' auto-repair (Settings > Repair / shell RepairAppRegistration) runs, "finishes successfully", and the app still won't open. Reproduced twice in 20 minutes, including once on a completely fresh reinstall.

Root cause (from event logs)

1. preview_start navigates to the Cloudflare challenge → the page probes WebGPU → Chromium's GPU child process tries to load the package's own app\vk_swiftshader.dll.
2. That child process runs with Code Integrity Guard (Microsoft-signed-only). vk_swiftshader.dll is Anthropic-signed → the load is blocked:

``
Microsoft-Windows-CodeIntegrity/Operational Id 3033
process ...\WindowsApps\Claude_1.32885.1.0_x64__pzs8sxrjxfjjc\app\claude.exe attempted to load
...\app\vk_swiftshader.dll that did not meet the Microsoft signing level requirements.
RequestedPolicy=8 ValidatedPolicy=1 Status=0xC0000428 (STATUS_INVALID_IMAGE_HASH)
`
Google Chrome on the same machine hits the identical block (chrome.exe → vk_swiftshader.dll`) and continues fine.

1. Because the blocked image lives inside a WindowsApps package, CI tries to validate it against the package catalog — which the sideloaded MSIX does not ship:

``
Id 3010 Code Integrity was unable to load the
...\Claude_1.32885.1.0_x64__pzs8sxrjxfjjc\AppxMetadata\CodeIntegrity.cat catalog. Status 0xC000003A.
`
Windows then sets PackageStatus = 0x2 (Modified) on the package. The app's main.log records GPU process gone: { reason: 'crashed', exitCode: 101457950 } at the same second; on the first occurrence the whole app died (cowork-service.log: Persistent RPC: connection ended: failed to read length: EOF`).

1. The shell's auto-repair (RegisterByPackageFullName ... RepairAppRegistrationOption) fails with 0x80073D02 while CoworkVMService/Claude.exe still hold the package, and once they exit it "succeeds" but never clears the Modified bit (AppModel-Runtime event 68 shows status returning to 0x2 after every repair). The package is stuck until a full re-Add.

Payload integrity was verified: all 2672 files / 11448 blocks SHA256-match AppxBlockMap.xml. Nothing on disk was modified; the flag is purely a CI-policy consequence.

Timeline (local time, 2026-08-21)

| Time | Event |
|---|---|
| 01:04:48 | preview_start → https://www.propertyguru.com.sg/listing/for-sale-park-colonial-25631994 |
| 01:04:56 | CI 3033 block on vk_swiftshader.dll; Claude.exe dies (RPC EOF) |
| 01:05:00 | Shell auto-repair → 0x80073D02; package now Modified, NeedsRemediation |
| 01:06–01:11 | User uninstalls + reinstalls via Claude Setup.exe; app works |
| 01:25:13 | Same preview_start call |
| 01:25:29 | CI 3033 + 3010 again; GPU process crash; package Modified again |

Workaround that worked

Add-AppxPackage -Path Claude-<hash>.msix -ForceUpdateFromAnyVersion -ForceApplicationShutdown (in-place, keeps app data) → Status: Ok. Re-register/repair does not fix it. Avoiding the preview on Cloudflare-challenged sites prevents recurrence.

Suggested fixes

• Ship AppxMetadata\CodeIntegrity.cat in the MSIX (or sign vk_swiftshader.dll / the Vulkan ICD path in a way that passes the GPU process's CIG policy), or don't apply CIG to the process that loads the Vulkan ICD.
• Have the bootstrapper's repair path do a full re-Add rather than relying on Windows' RepairAppRegistration, which cannot clear Modified.
• CoworkVMService logs failed to configure SCM recovery actions ... Access is denied on every start; while it holds the package open every repair fails with 0x80073D02.