Cowork bash sandbox unrecoverable when CoworkVMService silently fails to autostart (Windows, MSIX install)

Environment

• Claude desktop app 1.5354.0.0 (MSIX, WindowsApps\Claude_1.5354.0.0_x64__pzs8sxrjxfjjc)
• Windows 11 Home, build 10.0.26200
• Hyper-V stack healthy (vmcompute, HvHost both Running)

Symptom

Cowork's mcp__workspace__bash is dead from the first call of every session. User-visible error: Workspace unavailable. The isolated Linux environment failed to start. Retries (37+ in a prior session, dozens today) all fail identically. Every other Cowork tool works (Read/Write/Edit/Glob/Grep, request_cowork_directory).

Root cause

The Anthropic-installed Windows service CoworkVMService (running cowork-svc.exe, StartMode Auto) is Stopped. The Electron app's [VM:start] Configuring Windows VM service... step then fails with Error: VM service not running. The service failed to start. (stack trace at app.asar/.vite/build/index.js:164:34542 -> configure()). Manual Start-Service CoworkVMService from PowerShell fixes it without restarting the app, and the next bash call boots the VM normally.

Three issues this exposes

1. Service is registered with ErrorControl=Ignore, so SCM silently swallows boot-time autostart failures - no 7000/7001/7034 events appear in the System log. Diagnosing this from the user side is effectively impossible without reading %APPDATA%\Claude\logs\cowork_vm_node.log. Suggest changing to ErrorControl=Normal or at minimum logging the boot-time failure to the Application log under a CoworkVMService provider.
2. Auto-reinstall lock-out is one-shot per bundle. After a single failed attempt, the bundle drops .auto_reinstall_attempted and every subsequent VM start logs Skipping auto-reinstall (already attempted once) - turning every retry into a deterministic-fail. The flag should at least reset on app restart, on a successful boot, or after some TTL.
3. The user-facing error swallows the real cause. "Workspace unavailable / failed to start" gives no signal that the failure is a stopped Windows service. Surfacing the underlying Get-Service CoworkVMService state, or auto-attempting Start-Service before falling back, would fix the most common manifestation.

Reliable workaround

A user-scope scheduled task at logon (30s delay) that runs Start-Service -Name CoworkVMService recovers the issue without elevation, since the service's DACL allows the interactive user to start it. The binary itself is healthy - only the autostart path is broken.

Authoritative log

%APPDATA%\Claude\logs\cowork_vm_node.log. Today's failures from ~12:14 onward all show the same Configuring Windows VM service... -> VM service not running pattern; the auto-reinstall fired once at 10:33 and locked itself out for the rest of the session.