Cowork: windows.service named-pipe trigger registers as SERVICE_TRIGGER_TYPE_CUSTOM and can never fire

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 VM service), not the Claude Code CLI.

CoworkVMService declares a named-pipe activation trigger that is registered with the wrong trigger type, making it permanently inert. SCM subscribes to a nonexistent ETW provider instead of watching the named pipe.

1f81d131-3e60-4c76-9860-37334e4ffce3 is the well-known NAMED_PIPE_EVENT_GUID, but named-pipe activation requires SERVICE_TRIGGER_TYPE_NETWORK_ENDPOINT (6). Registered as SERVICE_TRIGGER_TYPE_CUSTOM (20), SCM treats the GUID as an ETW provider to subscribe to — nothing publishes under it, so the trigger can never fire. The data string should also be the bare pipe name (cowork-vm-service), not \pipe\cowork-vm-service.

On installations where the service does start, Start = 2 (AUTO_START) is doing all the work and the trigger contributes nothing. On-demand activation does not exist.

This is not the cause of the service failing to start entirely — see #86140. Deleting the TriggerInfo key and rebooting reproduced the identical ERROR_INVALID_PARAMETER failure.

What Should Happen?

The windows.service manifest declaration should register a SERVICE_TRIGGER_TYPE_NETWORK_ENDPOINT (6) named-pipe trigger with the bare pipe name (cowork-vm-service), so SCM actually watches the pipe and starts the service on demand instead of subscribing to a nonexistent ETW provider.

Worth checking whether the desktop6 schema exposes a named-pipe trigger element at all — if not, TriggerCustom with this GUID was never going to work and the on-demand activation path needs rethinking.

Error Messages/Logs

Manifest declaration (C:\Program Files\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc\AppxManifest.xml):

<desktop6:TriggerEvents>
  <desktop6:TriggerCustom
    Action="ActionStart"
    Subtype="1f81d131-3e60-4c76-9860-37334e4ffce3">
    <desktop6:StringData>
      <desktop6:DataItem Value="\pipe\cowork-vm-service" />
    </desktop6:StringData>
  </desktop6:TriggerCustom>
</desktop6:TriggerEvents>

What it registers as (HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService\TriggerInfo\0):

Type      = 20   SERVICE_TRIGGER_TYPE_CUSTOM
Action    = 1    SERVICE_TRIGGER_ACTION_SERVICE_START
Guid      = 1f81d131-3e60-4c76-9860-37334e4ffce3
DataType0 = 2    SERVICE_TRIGGER_DATA_TYPE_STRING
Data0     = "\pipe\cowork-vm-service"

sc.exe qtriggerinfo CoworkVMService renders this as:
CUSTOM : 1f81d131-... [ETW PROVIDER UUID]

Steps to Reproduce

1. Install Claude Desktop 1.28929.0.0 (MSIX, package Claude_<version>_x64__pzs8sxrjxfjjc).
2. Inspect the manifest's windows.service TriggerEvents declaration — it uses desktop6:TriggerCustom with Subtype 1f81d131-3e60-4c76-9860-37334e4ffce3 (NAMED_PIPE_EVENT_GUID).
3. Run: sc.exe qtriggerinfo CoworkVMService

Observe it renders as CUSTOM (type 20) with the GUID interpreted as an ETW provider, not as a NETWORK_ENDPOINT (type 6) named-pipe trigger.

1. Confirm via registry: HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService\TriggerInfo\0 shows Type = 20.
2. To confirm the trigger contributes nothing either way: reg delete "HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService\TriggerInfo" /f, then reboot. The service fails identically with ERROR_INVALID_PARAMETER (see #86140), confirming the trigger was never the operative activation path.

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

Impact: on installations where the service does start, Start = 2 (AUTO_START) is doing all the work and the trigger contributes nothing — on-demand activation via the named pipe does not exist.

Related: found while diagnosing #86140 (CoworkVMService never starts — packaged-service activation fails with ERROR_INVALID_PARAMETER). Confirmed not the cause of that issue — removing this trigger entirely changed nothing.