[BUG] [Cowork] CoworkVMService is not created during install/update — AppXDeploymentServer logs "OpenService for CoworkVMService failed with 0x80070424" and continues; re-registering with -ForceApplicationShutdown creates it

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?

````markdown
The manifest declares a packaged service:

AppxManifest.xml:108   Category="windows.service"
AppxManifest.xml:112   Name="CoworkVMService"

After a deployment that reports success, the service does not exist:

• Get-CimInstance Win32_Service -Filter "Name='CoworkVMService'" → empty
• Get-Process cowork* → empty
• reg query HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService → not found (no stale leftover)
• Get-AppxPackage -Name Claude → Status: Ok, provisioned version == registered version

Microsoft-Windows-AppXDeploymentServer/Operational explains it. The packaged service deployment
extension handler parses the manifest correctly — events 9622, 9623, 9625, and 9626 pointing at
AppxManifest.xml(111,12), which is the service declaration — and then:

Event 9653  Warning  OpenService for service CoworkVMService failed with error 0x80070424

0x80070424 is ERROR_SERVICE_DOES_NOT_EXIST. Deployment attempted to open an existing service,
found none, logged a warning and continued without creating it. Deployment then reports success,
so the user ends up with an installation that has no VM service and no indication of why Cowork
cannot start.

The difference between a failing and a succeeding deployment

Re-registering the already-installed package does create the service:

Add-AppxPackage -Register "$((Get-AppxPackage -Name Claude).InstallLocation)\AppxManifest.xml" -DisableDevelopmentMode -ForceApplicationShutdown

Result:

Name      : CoworkVMService
State     : Running
StartMode : Auto
PathName  : C:\Program Files\WindowsApps\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

Comparing the two deployments in the AppX log, the successful one differs in exactly two ways: the
option ForceApplicationShutdownOption is present (event 603), and TerminateApplications succeeds
several times. The failing one has neither and has the 9653 warning instead. That points at the
service extension being skipped when package files are in use — i.e. when Claude Desktop is running
at registration time. Any deployment flow that launches or restarts the app around registration will
hit this.

````

What Should Happen?

```markdown
Either the service extension should be applied — creating the service — rather than warning and
continuing, or deployment should not report success when a declared windows.service` extension was
not registered.

Silently succeeding produces an installation where Cowork can never start, with nothing in the UI or
in the deployment result to indicate the cause. A non-fatal warning buried in the AppX operational
log is not discoverable by users or administrators.

````

Error Messages/Logs

`
# Microsoft-Windows-AppXDeploymentServer/Operational, during a deployment that reported success:

Event 9622 / 9623 / 9625   PackagedServiceDEH parsing the manifest
Event 9626                 AppxManifest.xml(111,12)        <- the CoworkVMService declaration
Event 9653  Warning        OpenService for service CoworkVMService failed with error 0x80070424

# 0x80070424 = ERROR_SERVICE_DOES_NOT_EXIST

# The same log for a manual re-registration that succeeded:

Event 603                  ForceApplicationShutdownOption present
                           TerminateApplications succeeded (4 occurrences)
# no 9653 warning, and the service exists afterwards
`

Steps to Reproduce

````markdown

1. Provision the MSIX per machine, then register it per user while Claude Desktop is running.

1. Deployment reports success. Check for the service:

``powershell
Get-CimInstance Win32_Service -Filter "Name='CoworkVMService'" | Format-List Name,State,StartMode,PathName
``

Observed: empty result.

1. Inspect the deployment log:

``powershell
Get-WinEvent -LogName "Microsoft-Windows-AppXDeploymentServer/Operational" -MaxEvents 200 |
Where-Object { $_.Id -in 9622,9623,9625,9626,9653 } |
Select-Object TimeCreated,Id,LevelDisplayName,Message
``

Observed: event 9653 with 0x80070424, immediately after the manifest parse events.

1. Re-register with the force option:

``powershell
Add-AppxPackage -Register "$((Get-AppxPackage -Name Claude).InstallLocation)\AppxManifest.xml" -DisableDevelopmentMode -ForceApplicationShutdown
``

1. The service now exists, StartMode Auto, State Running, with its binary under WindowsApps.

````

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Desktop 1.26832.0.0 (x64 MSIX, Claude_1.26832.0.0_x64__pzs8sxrjxfjjc) — not the Claude Code CLI; this is a Claude Desktop / Cowork packaging defect

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

````markdown

Environment

Same host as the companion report: Claude Desktop 1.26832.0.0 x64 MSIX
(Claude_1.26832.0.0_x64__pzs8sxrjxfjjc), Windows 10 Enterprise Build 19045, managed deployment with
per-machine provisioning followed by per-user registration.

Ruled out

• Stale service registry key — HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService was absent.
• Stale provisioning — the provisioned version matched the registered version.
• Virtualization prerequisites — HypervisorPlatform enabled, vmms / vmcompute / hns running.
• Missing OS support for packaged services — MSIX services are supported from Windows 10 version

2004 (Build 19041), and this host is 19045.

Note

On Windows 10 this fix alone is not sufficient to make Cowork work, because the data path split
described in the companion report remains. The two are independent defects: with the service running
correctly, cowork-svc still reads a directory the app never writes to.

````