Cowork fails with VM service not running. The service failed to start. CoworkVMService never starts — packaged-service activation fails with ERROR_INVALID_PARAMETER (87) on Windows 11 25H2 (26200) - workaround found

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?

Surface: Claude Desktop 1.28929.0.0 (Cowork / sandbox VM service), not the Claude Code CLI. Claude Code CLI version installed on this machine: 2.1.228 (latest at time of filing).

Cowork fails with "VM service not running. The service failed to start." The packaged service CoworkVMService never executes.

SCM does accept and attempt the start — it transitions the service to SERVICE_START_PENDING and then back to SERVICE_STOPPED 10 milliseconds later, without ever resolving an image or creating a process. StartService returns ERROR_INVALID_PARAMETER (87). This happens identically at boot, on every app-initiated start, and on manual sc.exe start.

The failure is confined to the AppX packaged-process activation handoff. Everything on either side of it is healthy and proven so:

• cowork-svc.exe is present, correctly signed, and fully functional — launched by hand it boots the VM end to end (HCS compute system created, vsock RPC up, sdk-daemon ready, network CONNECTED, API REACHABLE).
• The MSIX manifest's windows.service declaration is well-formed and matches the registry key.
• The package is registered with Status: Ok and a PackageFullName that matches the service key exactly.

This is not the same failure mode as the existing 25H2 cluster (#38396, #38241, #32186, #27652): there is no exit code 1066, no signature verification error, no HCN error, because the service binary never runs.

See "Error Messages/Logs" for the SCM ETW trace, event log, and service registration details, and "Additional Information" for suggested fixes and adjacent defects found while diagnosing.

What Should Happen?

CoworkVMService should start automatically at boot and on app-initiated StartService calls, exactly as it does when cowork-svc.exe is launched interactively by hand (HCS compute system created, vsock RPC up, sdk-daemon ready, network CONNECTED, API REACHABLE). Packaged-service activation should resolve the image via PackageFullName + AppUserModelId and create the process, instead of failing with ERROR_INVALID_PARAMETER (87) before any process is ever created.

Error Messages/Logs

SCM ETW trace (Microsoft-Windows-Services provider {0063715b-eeda-4007-9429-ad526f62696e}) around a manual sc.exe start CoworkVMService:

15:32:10.807906  103 StartingGroup Start        GroupName: Null
15:32:10.807955  105 ServiceStatusChange        CoworkVMService, CurrentState 2 (START_PENDING), StartType 2, PID 0, ImageName ""
15:32:10.817972  105 ServiceStatusChange        CoworkVMService, CurrentState 1 (STOPPED), StartType 2, PID 0, ImageName ""
15:32:10.817984  104 StartingGroup Stop         GroupName: Null

sc.exe start returned FAILED 87: The parameter is incorrect.

For comparison, a normal service captured in the same trace session carried ImageName: C:\WINDOWS\system32\svchost.exe -k netsvcs -p. There is not one Microsoft-Windows-AppModel-Runtime/Admin event 201 ("Created process N for application <AUMID> in package <PFN>") for cowork-svc.exe, ever, and no error-level events in that log at all.

Corresponding SCM event log (after setting ErrorControl=1; it ships as 0/SERVICE_ERROR_IGNORE, which suppresses this entirely):

Event 7000, Service Control Manager, Error, 15:12:07
The CoworkVMService service failed to start due to the following error:
The parameter is incorrect.

Logged once at boot, then again on each Cowork launch (15:22:26, 15:22:33, 15:23:16, 15:24:23) as the app calls StartService itself.

Service configuration as registered (HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService):

Type            = 528 (0x210)  SERVICE_WIN32_OWN_PROCESS | SERVICE_PKG_SERVICE
Start           = 2            AUTO_START
ErrorControl    = 0            SERVICE_ERROR_IGNORE
ImagePath       = "C:\Program Files\WindowsApps\Claude_1.28929.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
ObjectName      = LocalSystem
DependOnService = staterepository
PackageFullName = Claude_1.28929.0.0_x64__pzs8sxrjxfjjc
AppUserModelId  = Claude_pzs8sxrjxfjjc!Claude
PackageOrigin   = 5
ServiceSidType  = 1

Manually launching the identical binary succeeds completely:

Running CoworkVMService in interactive/debug mode
[HCS] vmcompute.dll / computecore.dll loaded successfully
[HCN] EnumerateNetworks result: ["c08cb7b8-9b3c-408e-8e30-5e16a3aeb444"]
[Server] Named pipe server listening
[Server] Client signature verified: ...\app\claude.exe (subject: Anthropic, PBC)
[HCS] HcsCreateComputeSystem returned: hr=0x0
[HCS] HcsStartComputeSystem returned: hr=0x0
[VM] VM started successfully
[RPC] sdk-daemon connected from VM f43564c4-...
[RPC] Network status: CONNECTED
[VM] Installed 54 CA certificates in guest
[RPC] API reachability: REACHABLE

Steps to Reproduce

1. On Windows 11 25H2 (build 26200), install Claude Desktop 1.28929.0.0 (MSIX, package Claude_1.28929.0.0_x64__pzs8sxrjxfjjc) and open Cowork.
2. Observe: "VM service not running. The service failed to start."
3. Make SCM log the failure (it is silent by default):

reg add "HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService" /v ErrorControl /t REG_DWORD /d 1 /f
Reboot, then check the System log for event 7000 from Service Control Manager.

1. Capture SCM's internal state transitions:

logman create trace scmtrace -p "{0063715b-eeda-4007-9429-ad526f62696e}" 0xffffffffffffffff 5 -o "$env:TEMP\scm.etl" -ets
sc.exe start CoworkVMService
logman stop scmtrace -ets
tracerpt "$env:TEMP\scm.etl" -o "$env:TEMP\scm.xml" -of XML -y -lr

1. Confirm no packaged process is created — look for event 201 mentioning "Claude" in Microsoft-Windows-AppModel-Runtime/Admin. There is none.
2. For comparison, run cowork-svc.exe directly from a terminal — it boots the VM end to end successfully (see Error Messages/Logs), proving the binary itself is not at fault.

Reproduces identically at boot, on every app-initiated start, and on manual sc.exe start.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.228 (Claude Code CLI, latest at time of filing) — Claude Desktop app build 1.28929.0.0 is the actual affected surface (Cowork VM service).

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Ruled out:

• cowork-svc.exe present: Yes, 12,797,264 bytes
• Authenticode: Valid, CN="Anthropic, PBC" (EV)
• Package registration: Status: Ok; PackageFullName matches service key exactly — no stale-PFN mismatch
• Smart App Control: VerifiedAndReputablePolicyState = 0 (off)
• User-mode WDAC: UsermodeCodeIntegrityPolicyEnforcementStatus = 0
• CodeIntegrity/Operational: routine policy refreshes only, zero blocks
• Activation stack: AppXSvc, ClipSVC, StateRepository, TokenBroker all Running
• Third-party EDR: none — only Defender, Dell SupportAssist Remediation, Tailscale
• Hyper-V stack: hns, vmcompute, vfpext, vmms running; hypervisorlaunchtype Auto; VirtualMachinePlatform, HypervisorPlatform, Microsoft-Hyper-V-All all Enabled
• Clean reinstall: winget uninstall + Remove-AppxPackage -AllUsers + Remove-AppxProvisionedPackage + manual service key and %LOCALAPPDATA%\AnthropicClaude / %APPDATA%\Claude removal, then reinstall — no change
• Removing the service trigger entirely: reg delete ...\TriggerInfo /f + reboot — no change, still error 87

CoworkVMService is the only SERVICE_PKG_SERVICE on this machine, so there's no local baseline for whether packaged-service activation is broken machine-wide or specific to this service. If another 26200 user can run the diagnostics in Steps to Reproduce, that distinction would be the most useful addition to this report.

Possibly relevant: the manifest declares MaxVersionTested="10.0.22621.0" (Windows 11 22H2) while this machine runs 26200. Not enforced at runtime, so not causal, but suggestive given the 25H2 issue cluster.

Workaround — registering the identical binary as an ordinary (unpackaged) Win32 service bypasses the broken activation path and works completely:

sc.exe create CoworkVMServiceAlt binPath= '"C:\Program Files\WindowsApps\Claude_1.28929.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"' start= auto obj= LocalSystem DisplayName= "Claude Cowork VM Service (unpackaged)"
sc.exe failure CoworkVMServiceAlt reset= 86400 actions= restart/5000/restart/10000/restart/30000
sc.exe start CoworkVMServiceAlt

Result: service Running, \\.\pipe\cowork-vm-service created, C:\ProgramData\Claude\Logs\cowork-service.log written for the first time, app connected within a second, sandbox fully operational. Signature enforcement is active in this mode (Enforce: true, versus false in interactive/debug), so the security posture is preserved. The service name doesn't matter — the app locates the service by opening the named pipe, which the process creates itself.

Caveat: the binary path is version-pinned, so a Claude Desktop update silently breaks it until re-pointed:
sc.exe config CoworkVMServiceAlt binPath= "\"$((Get-AppxPackage Claude).InstallLocation)\app\resources\cowork-svc.exe\""

Suggested fixes:

1. Investigate why AppX packaged-process activation returns E_INVALIDARG for this service on build 26200.
2. Ship ErrorControl = 1 so SCM failures are visible. As it stands, a start failure produces no log, no event, no exit code, and no service log file — nothing to diagnose from.
3. Have the app fall back to registering/starting an unpackaged service when packaged activation fails, rather than reporting "The service failed to start" and giving up. The app already classifies this correctly (Skipping auto-reinstall (service transport error)), so it knows the difference.

Adjacent defects found while diagnosing (filed separately to keep this report to a single bug):

• The windows.service named-pipe trigger can never fire. The manifest uses desktop6:TriggerCustom with NAMED_PIPE_EVENT_GUID, producing a SERVICE_TRIGGER_TYPE_CUSTOM (20) trigger instead of SERVICE_TRIGGER_TYPE_NETWORK_ENDPOINT (6). Confirmed not the cause of this issue — removing it changed nothing.
• Recovery actions are never configured on any installation. The service tries to set its own restart policy at startup and cannot, because SCM does not permit config changes on a packaged service. Likely explains #36590.
• StartVMWithBundle receives the unredirected bundle path while configure passes the MSIX-redirected one.
• Machine-store CA certificates are skipped when the service does not run as LocalSystem (Loaded 0 CA certificates from LocalMachine\ROOT).

Environment:
OS: Windows 11 Pro 25H2, build 26200.9168
Feature Experience Pack: 1000.26100.344.0
Claude Desktop: 1.28929.0.0
Package: Claude_1.28929.0.0_x64__pzs8sxrjxfjjc (MSIX, sideload-signed)
Hardware: Dell, with Dell management software present