Windows MSIX: auto-start CoworkVMService races package servicing -> 0x80073D02, app won't launch until repeated Repair

Summary

Claude Desktop ships an AUTO_START packaged Windows service, CoworkVMService
(cowork-svc.exe), inside its MSIX package. A packaged service pins the package
"in use", so every package servicing operation (update registration, repair,
re-register) must terminate it first. Because it is AUTO_START, it comes back
during servicing — the Register step then aborts with 0x80073D02, and Windows
refuses to activate the app, showing:

Go to Claude's advanced options and select "Repair". If the problem persists, reinstall the app or contact your administrator.

Clicking Repair in Settings hits the same race, so it commonly fails on the
first attempt and the app looks unrecoverable.

Environment

• Windows 11 Pro 10.0.26200
• Claude Desktop 1.34493.1.0 (MSIX, Claude_..._x64__pzs8sxrjxfjjc)
• Outage window: 2026-08-23, 09:06 → 12:04 local

Service configuration

SERVICE_NAME       : CoworkVMService
TYPE               : 210  WIN32_PACKAGED_PROCESS
START_TYPE         : 2    AUTO_START
BINARY_PATH_NAME   : "C:\Program Files\WindowsApps\Claude_1.34493.1.0_x64__...\app\resources\cowork-svc.exe"
DEPENDENCIES       : staterepository
SERVICE_START_NAME : LocalSystem

The race, to the second

From Microsoft-Windows-AppXDeploymentServer/Operational and
C:\ProgramData\Claude\Logs\cowork-service.log:

12:04:04  [603]  RepairPackageOperation started
12:04:12  [666]  Repair step 1 of 2 (Add) finished with result 0x0
12:04:12.471470  cowork-service.log: "Starting CoworkVMService as Windows service"
12:04:12  [9641] 0x80004004: Deployment aborts due to active service Claude_pzs8sxrjxfjjc!Claude
12:04:12  [638]  Packages were not updated because affected apps are still running.
                 Running apps: {Claude_pzs8sxrjxfjjc!Claude}
12:04:12  [419]  ERROR 0x80073D02: Unable to install because the following apps need to be closed
12:04:12  [8107] ERROR Illegal non-AppStore or non-AppInstaller package integrity
                 validation attempted for package Claude_... Flags: 0x0
12:04:12  [8104] ERROR Failed to set the Trust Label on package Claude_... Error: 0x80070057
12:04:12  [666]  Repair step 2 of 2 (Register) finished with result 0x80073D02

The Add step re-enables the package, SCM starts the AUTO_START service, and the
Register step immediately finds it active and aborts. The identical sequence
occurred at 09:19:58. An earlier instance hit version 1.30096.5.0 on 08-17 16:33,
so this is not specific to one build.

The service cannot protect itself against this

cowork-svc.exe attempts to manage its own SCM recovery actions and fails, on
every start and every stop:

Warning: failed to configure recovery actions (a crashed service will stay down
until reboot): open service: Access is denied.

Warning: failed to disarm recovery actions for this stop: open service: Access is denied.

The corresponding Application event log entries (provider CoworkVMService) state
the consequence explicitly:

Claude VM Service: failed to disarm SCM recovery actions for this stop; if the stop overruns, the service may be auto-restarted during package servicing: open service: Access is denied.

The service runs as LocalSystem yet cannot open its own service handle with
SERVICE_CHANGE_CONFIG. This looks like the packaged-service token lacking the
required right.

Observed impact

Five launch attempts produced no process at all. Microsoft-Windows-TWinUI/Operational
logged event 1621 (activation attempted) at 09:06:49, 11:18:02, 12:02:32, 12:03:52
and 12:03:56, with no corresponding Microsoft-Windows-AppModel-Runtime/Admin
event 201 (process created). Each failed activation triggered Windows' auto-heal
path (RegisterByPackageFullName with RepairAppRegistrationOption).

Windows also repeatedly reported damaged package ACLs:

[649] Deployment Register operation: Trying to repair ACLs for
      \?\C:\Program Files\WindowsApps\Claude_1.34493.1.0_x64__...
[649] ACLs repaired successfully ... Register next time should succeed.

Recovery required a full Repair (Add + Register) followed by a further
register-only Repair before the app finally launched at 12:04:41.

Aggravating factor

MSIX update registration is deferred while the app is running
(DeferRegistrationWhenPackagesAreInUse), so it lands at shutdown/boot. On a
machine that shuts down uncleanly, that window is exactly where package payload and
ACL damage occurs. The auto-start service widens this window considerably, because
the package is pinned in use even when the app itself is closed.

Workaround

Stop the service before re-registering, instead of using Settings → Repair
(elevated PowerShell):

Stop-Service CoworkVMService -Force
Get-Process claude, cowork-svc -ErrorAction SilentlyContinue | Stop-Process -Force
Get-AppxPackage -Name Claude | ForEach-Object {
    Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppxManifest.xml"
}

This succeeds on the first attempt.

Suggested fixes

1. Do not run the packaged service as AUTO_START. A demand-start service with a

start trigger, launched by the app when a Cowork VM session is actually needed,
would leave the package unpinned the rest of the time and remove the race.

1. Grant the service the rights needed to manage its own SCM recovery configuration

— or, if that is not possible for a packaged service, stop attempting it and
drop the warning to debug level rather than shipping a known-unfixable warning
on every start and stop.

1. Have the service stay down for the whole servicing window rather than restarting

between the Add and Register steps of a repair.

Secondary issue: app file logging stopped after 1.34493.1.0

Since the update to 1.34493.1.0 on 08-21, nothing has been written to
%APPDATA%\Claude\logs\ — main.log, mcp.log and the per-MCP-server logs all
stop at the moment of the last shutdown under the previous build, while the app
runs normally. C:\ProgramData\Claude\Logs\cowork-service.log continues to write
correctly, so this appears limited to the Electron side. The practical effect is
that there is no app-side evidence available when an incident like the above occurs.