[BUG] Cowork: restarting the Claude app destroys the MSIX container and kills packaged CoworkVMService, which then cannot restart until reboot

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

Quitting or restarting the Claude app kills CoworkVMService, and nothing can restart it until the machine reboots. The in-app banner says "Claude's workspace service isn't running. Restart your computer to restore it. Reinstalling won't help." — so the natural first remedy (restart the app) is precisely the action that re-triggers the fault.

CoworkVMService is declared as a packaged service (sc qc → TYPE : 210 WIN32_PACKAGED_PROCESS), so it runs inside the Claude MSIX container rather than beside it. When the container is torn down, the service dies with it. Three things then prevent recovery:

1. No SCM recovery actions. sc qfailure CoworkVMService → no actions, reset period 0. SCM never restarts it.
2. Named-pipe activation is inert. The on-demand trigger is registered as SERVICE_TRIGGER_TYPE_CUSTOM (20) rather than SERVICE_TRIGGER_TYPE_NETWORK_ENDPOINT (6), so it can never fire — see #86157. I can confirm this is still present in 1.30096.5.0, not just the 1.28929.0.0 in that report.
3. Users cannot mitigate it. The service DACL grants SERVICE_CHANGE_CONFIG to a single service SID and not to Administrators, so sc failure returns Access is denied even from an elevated shell. (Same ACL observation as #84180, different symptom.)

Net effect: StartupType=auto is the only thing that ever starts this service, which means one boot = one service lifetime. Every app restart after that leaves Cowork offline for the rest of the session.

The correlation is exact. Every 7034 "terminated unexpectedly" lands on the same second as an AppX container teardown (Microsoft-Windows-AppModel-Runtime/Admin event 217) for the Claude package:

| Container destroyed (217) | Service died (7034) |
|---|---|
| 14:16:43 | 14:16:43 |
| 20:57:37 | 20:57:37 |
| 21:16:19 | 21:16:19 |

The two teardown flavours behave differently, which is the tell:

| Teardown | cowork-service.log | Service comes back? |
|---|---|---|
| App update | Service stop requested → Service stopped. | Yes — 7045 reinstalls and starts it |
| App quit/restart | nothing — the log just stops mid-stream | No |

The app is aware of the dead end and gives up by design:

[warn] [VM:start] Skipping auto-reinstall (Windows VM service is not running; a computer restart restores it), leaving VM offline

After that, vm-client retries the pipe once per second indefinitely with no backoff and no ceiling, which is a lot of log volume for a condition the app has already decided is unrecoverable.

What Should Happen?

Restarting the Claude app should not permanently disable Cowork for the rest of the boot session. Any one of these would fix it:

1. Give the service SCM recovery actions (e.g. restart/5000). The DACL already prevents users from adding them, so this has to ship in the package.
2. Fix the named-pipe trigger type (#86157) so on-demand activation actually works — this alone would make the whole failure self-healing.
3. Don't let container teardown take the service with it, or have the app start it on launch instead of only probing it.
4. Correct the banner. "Restart your computer to restore it" is true but incomplete, and it sits next to the one action that guarantees the problem recurs. Something like "quit and reopen Claude will not fix this; a reboot is required" would save users the loop.

Fix (1) or (2) would also make the 1 Hz pipe-retry loop moot.

Error Messages/Logs

# --- service is packaged, has no recovery actions ---------------------------
> sc qc CoworkVMService
        TYPE               : 210  WIN32_PACKAGED_PROCESS
        START_TYPE         : 2   AUTO_START
        ERROR_CONTROL      : 0   IGNORE
        BINARY_PATH_NAME   : "C:\Program Files\WindowsApps\Claude_1.30096.5.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
        DEPENDENCIES       : staterepository
        SERVICE_START_NAME : LocalSystem

> sc query CoworkVMService
        STATE              : 1  STOPPED
        WIN32_EXIT_CODE    : 1067  (0x42b)      # ERROR_PROCESS_ABORTED
        SERVICE_EXIT_CODE  : 0  (0x0)

> sc qfailure CoworkVMService
        RESET_PERIOD (in seconds)    : 0
        REBOOT_MESSAGE               :
        COMMAND_LINE                 :          # no actions at all

# --- users cannot add recovery actions, even elevated -----------------------
> sc failure CoworkVMService reset= 86400 actions= restart/5000/restart/10000/restart/30000
[SC] OpenService FAILED 5:
Access is denied.

> sc sdshow CoworkVMService
D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1949724575-2387902436-65106593-1201171665-3967308604)
# AU = start/stop/query only. Administrators are absent entirely.

# --- on-demand activation is inert (still true in 1.30096.5.0, cf. #86157) ---
> sc qtriggerinfo CoworkVMService
        START SERVICE
          CUSTOM        : 1f81d131-3e60-4c76-9860-37334e4ffce3 [ETW PROVIDER UUID]
            DATA        : \pipe\cowork-vm-service

# --- the app's own log, after the service dies ------------------------------
[info]  [VM:start] Configuring Windows VM service...
[error] [VM:start] Startup failed: Error: VM service not running. The service failed to start.
[warn]  [VM:start] Skipping auto-reinstall (Windows VM service is not running; a computer restart restores it), leaving VM offline
[info]  Dispatching startup error: VM service not running. Restart your computer to restore it.

# then, once per second, indefinitely:
[warn] [vm-client] Event resubscribe failed: Error: connect ENOENT \\.\pipe\cowork-vm-service

# --- cowork-service.log stops mid-stream, no shutdown line ------------------
21:15:58.466 [Server] Client connected: user=<user> exe=claude.exe isDev=false
21:15:58.466 [HCS] Properties result: {"Id":"cowork-vm-<id>","State":"Running"}
21:15:58.466 [Server] Reusing existing session for <user>
<-- log ends here; container destroyed 21:16:19, no "Service stop requested" -->

Full session timeline from one boot (times local, single machine):

20:59:04  machine boots
20:59:32  CoworkVMService starts via AUTO_START            <-- the only thing that starts it
21:00:37  VM up, CA certs installed, API reachable          <-- healthy
21:15:58  last healthy log line in BOTH main.log and cowork-service.log
21:16:19  AppX container destroyed (217) + service 7034     <-- same second
21:16:22  new container + new claude.exe process
21:16:34  "VM service not running. The service failed to start."  (3 attempts, 5s apart)
21:16:39+ ENOENT on \\.\pipe\cowork-vm-service, 1/sec, forever

Steps to Reproduce

1. Install Claude Desktop (MSIX, package Claude_<version>_x64__pzs8sxrjxfjjc) on Windows 11 with Hyper-V/VMP enabled and a working Cowork VM.
2. Reboot. Confirm Cowork works — Get-Service CoworkVMService is Running and a Cowork space opens normally.
3. Quit Claude fully and reopen it. (Do not update; a plain quit/relaunch.)
4. Observe Get-Service CoworkVMService is now Stopped, and Cowork spaces show "Claude's workspace service isn't running."
5. Restart the app again — no change. The service stays stopped.
6. Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-AppModel-Runtime/Admin'; Id=217} and the 7034 in the System log share a timestamp to the second.
7. Only a reboot restores it — until the next time the app is restarted.

Workaround (instant, no reboot): Start-Service CoworkVMService from an elevated shell. Starting the service is permitted by the DACL even though changing its config is not.

For anyone hitting this repeatedly, a scheduled task triggered on System event 7034 filtered to Data[@Name='param1']='Claude', running Start-Service CoworkVMService as SYSTEM, heals it in ~8 seconds. That needs no right over the service beyond SERVICE_START, which Authenticated Users already hold, so it touches nothing hardened. Verified working by force-killing cowork-svc.exe — note a graceful Stop-Service will not test it, since SCM only logs 7034 on unexpected termination.

Related

• #86157 — the misregistered named-pipe trigger. Complementary: that issue explains why the service cannot be started on demand; this one explains what kills it in the first place. Confirmed still present in 1.30096.5.0.
• #84180 — same DACL / Access is denied for recovery config, observed in the auto-update-relaunch context rather than this one.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.226 (CLI) — but the affected surface is Claude Desktop build 1.30096.5.0 (Cowork VM service), not the CLI.

Platform

Claude Desktop (Windows, MSIX)

Operating System

Windows 11 Pro 10.0.26200 (x64)