Cowork VM fails to start: signature verification rejects valid multi-volume AppX package copy

Update: root cause was more specific than originally reported, and one part of the original theory was wrong

Further investigation (with VM debug logging enabled, plus the service's own historical log under C:\ProgramData\Claude\Logs\cowork-service.log) refines — and partly corrects — the original report.

Correction: this is not "two equally-legitimate replicated copies"

The original report treated the C: and D: copies as two valid, in-sync replicas produced by routine multi-volume package replication. That's wrong. C:\ProgramData\Claude\Logs\cowork-service.log retains service-side history going back to 2026-05-21. Across that entire history — roughly 3 months, ~24 distinct app versions — every single successful Client signature verified entry was for a D:\WindowsApps\... client path. Zero exceptions. Zero rejections of any kind are logged before 2026-08-13 03:22:26 (the last successful D: verification). D: has been the sole, long-standing, properly-authorized install location on this machine the whole time — not a passive duplicate.

The C:\Program Files\WindowsApps\... copy only exists as of the current app version. It has never once been successfully verified.

The actual user-facing symptom

Before VM debug logging was enabled, the error visible to the user was simply "Workspace unavailable. The isolated Linux environment failed to start." With debug logging on, the underlying error is:

[error] [VM:start] Startup failed: Error: RPC pipe closed
...
  code: 'ERR_VM_PIPE_CLOSED'

occurring specifically inside [ScheduledTasks] startVM / [HostLoop], at the "Configuring Windows VM service..." step. This has been failing on a steady ~5 minute cadence since at least 2026-08-14 (confirmed in main.log, using the app's normal non-debug logging — this is not new or intermittent). The repeating [vm-client] Event resubscribe failed: signature verification failed warning (the focus of the original report) is a secondary symptom of the same root cause, not a separate issue.

Scope: only the scheduled/background VM-start path is affected

Every foreground/interactive launch of claude.exe, checked repeatedly via Get-Process -IncludeUserName, resolves correctly to C:\Program Files\WindowsApps\... (matching the current, though newly-established, InstallLocation) and is unaffected. Only the scheduled/background VM-start code path resolves execution from the D: copy (confirmed via a stack trace in the VM debug log showing the failing code executing from D:\WindowsApps\...\app.asar\...) and then gets rejected by a signature check that apparently assumes the client must match the single current InstallLocation (C:), rather than tolerating the package's actual, historically-authorized location.

New evidence: C: itself appears to lack proper capability authorization

Attempting Move-AppxPackage -Package Claude_<version>_x64__pzs8sxrjxfjjc -Volume <C: volume> fails with:

Deployment failed with HRESULT: 0x80073CF6, Package could not be registered.
Authorization of capabilities for Claude_<version>_x64__pzs8sxrjxfjjc failed with error code 0x800701C5.

This app declares restricted capabilities (e.g. the computerUse/automation-related features visible in its own desktop-features flag dump). Restricted capabilities normally require proper Store-mediated authorization. This failure suggests the C: deployment never received that authorization, while D: has three months of proven, successful authorization behind it — consistent with C: being the newly (and incompletely) provisioned side of this split, not D:.

Remediation attempts that did NOT resolve it

For anyone else hitting this, or for triage — none of the following fixed it:

• Remove-AppxPackage -Package <id> -User <secondary-local-account-SID> (un-registering the package for a second local account that had it Staged but never launched) — no effect.
• Move-AppxPackage -Volume <C:> — fails with the capability-authorization error above.
• Move-AppxPackage -Volume <D:> — succeeds (no error) but is a silent no-op: InstallLocation remains C: afterward, D:'s files were already present so nothing was actually migrated.
• Full package Repair via Settings → Apps → Advanced options — completes successfully, rebuilds the C: copy, but does not touch or remove the D: copy, and the scheduled VM-start failure is unchanged afterward.
• Direct filesystem removal of the C: copy (takeown /r, icacls /grant Administrators:F /t, then Rename-Item) — ownership and permissions succeed cleanly (confirmed via icacls; Administrators ends up with effective Full Control), Controlled Folder Access is confirmed disabled, and Resource Monitor's handle search confirms no process has any file in that folder open — yet Rename-Item still fails with Access to the path is denied. This points to Windows enforcing package integrity on an actively-registered AppX folder at a level below ACLs/open-handle checks, not a permissions problem — direct filesystem tampering on a live-registered package folder appears to be structurally blocked outside the AppX servicing APIs.

Currently proceeding to a full uninstall (via Settings, confirming both the C: and D: copies are actually gone from disk afterward) + reinstall, since every lighter-weight remediation has been exhausted.

Suggested fix (revised)

The scheduled/background VM-start path's signature check should validate the calling process's package identity via the proper AppX APIs (as originally suggested), tolerant of the package's actual authorized location — not assume the single most-recently-registered InstallLocation is automatically correct. On this machine, the most-recently-registered location (C:) is in fact the less-trustworthy one: it has never passed capability authorization, while the location it's rejecting (D:) has three months of proven, successful use.

Update 2: confirmed regression, no viable local fix exists

A full uninstall + fresh reinstall does not resolve this

After exhausting the lighter-weight remediation attempts listed in the previous update, I did a full uninstall via Settings (confirmed via Get-AppxPackage -AllUsers returning completely empty, and Test-Path confirming neither the C: nor D: package folders existed anymore) followed by a fresh install of the current version, from the same source originally used (direct download from claude.ai, not the Microsoft Store).

The fresh install recreated the exact same C:/D: split automatically. dir D:\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc immediately after the fresh install shows the package folder with timestamps matching the install itself (same day, minutes after Get-AppxPackage's C: InstallLocation was confirmed). This was not a leftover, not a stale cache, not anything carried over from the old install — it was written fresh, by the current installer, on a machine that had zero prior Claude package registration.

The signature-check failure resumed immediately afterward, citing the identical D: client path as before.

This means the root cause is structural, not incidental

This machine has a second AppX package volume registered (D:\WindowsApps, PackageVolumes\2 in the registry) — likely from a past "install new apps to D:" configuration, and shared with several other unrelated Store apps. As long as that second volume stays registered, Windows' own deployment stack writes every install/update/repair of this package to both volumes simultaneously. That's not unique to this app or something a user did wrong — it's ordinary AppX behavior on any machine with more than one registered package volume. It's very likely reproducible on any machine in the same configuration, not specific to this machine's history.

Confirmed regression

Per the previous update, the service's own historical log shows this exact machine — in this exact dual-volume configuration — worked correctly for three months across roughly two dozen prior app versions, always being served from (and always successfully verified from) the D: copy. The signature-verification logic that now rejects that same D: copy is new in the current version. The dual-volume deployment itself did not change; the app's tolerance for it did.

No reasonable local remediation exists

The only action that reliably stops Windows from re-splitting the deployment is Remove-AppxVolume on the D: volume — but that volume is also currently used by other, unrelated installed apps on this machine (confirmed via matching Windows Firewall rules for those apps' own D:-based binaries). Removing it to work around this bug would mean accepting unknown impact on completely unrelated software, which isn't a reasonable ask of anyone hitting this. Given that, and that a full uninstall/reinstall (the most disruptive option available to an end user) doesn't help either, there does not appear to be any viable client-side workaround — this needs a fix in Cowork's client verification logic itself: it must tolerate the package being validly deployed to more than one registered AppX volume, rather than hard-rejecting any client not served from the single most-recently-registered InstallLocation.

Note: This seems to be the same as "Claude Desktop for Windows: Cowork RPC pipe closed Workaround" (https://github.com/anthropics/claude-code/issues/85199), and the workaround that is suggested there is working for me (obviously this still needs a fix, running the service myself every time is not an acceptable solution).