[BUG] Cowork: CoworkVMService aborts with exit 1067 on client connect — no crash record, no service log error (Windows 11 Home)

Status Open
Maintainer reply None cached
Activity 0 comments · opened Sep 1, 2026

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?

Windows 11 Home (no Hyper-V feature available), Claude Desktop on C:
VirtualMachinePlatform Enabled; vmcompute and hns both RUNNING
CoworkVMService starts, reaches RUNNING, then exits 1067 (ERROR_PROCESS_ABORTED) with service exit code 0 as soon as the app connects
No cowork-svc.exe entry in Windows Error Reporting — it aborts without logging
cowork-service.log shows only "Client connected" once per second, no VM creation, no error
Named pipe cowork-vm-service is created correctly when the service is up
Reproduces with third-party firewall service stopped
sc.exe failure CoworkVMService returns access denied because it's a packaged service, so recovery actions can't be configured

What Should Happen?

CoworkVMService should remain running when the Claude app connects to it, create the workspace VM, and the Cowork tab should load a working workspace.

If the service cannot start the VM, it should write the reason to cowork-service.log and surface an actionable error instead of aborting silently. Because the service is registered as WIN32_PACKAGED_PROCESS, it should also have recovery actions configured by the installer, since sc.exe failure is denied to administrators and the service cannot self-heal after an abort.

Error Messages/Logs

sc.exe query CoworkVMService  (after the app connects)

NOMBRE_DE_SERVICIO: CoworkVMService
        TIPO                         : 210  WIN32_PACKAGED_PROCESS
        ESTADO                       : 1  STOPPED
        CÓDIGO_DE_SALIDA_DE_WIN32    : 1067  (0x42b)
        CÓDIGO_DE_SALIDA_DEL_SERVICIO: 0  (0x0)
        PUNTO_DE_CONTROL             : 0x0
        ESPERA                       : 0x0

C:\ProgramData\Claude\Logs\cowork-service.log -- only repeated connect
attempts, no VM creation, no error:

2026/09/01 08:35:43.413855 [Server] Client connected
2026/09/01 08:35:44.424267 [Server] Client connected
2026/09/01 08:35:45.430803 [Server] Client connected
... (one per second, continues indefinitely)

sc.exe failure CoworkVMService reset= 86400 actions= restart/5000/...
[SC] OpenService ERROR 5: Acceso denegado.   (in elevated PowerShell)

Verified working:
  vmcompute                -> RUNNING
  hns                      -> RUNNING
  VirtualMachinePlatform   -> Enabled
  \\.\pipe\cowork-vm-service -> present while service is up

No cowork-svc.exe entry in Windows Error Reporting (Application log)
Reproduces with third-party firewall service (wfcs) stopped
UI error: "Claude's workspace service isn't running"

Steps to Reproduce

On Windows 11 Home with VirtualMachinePlatform enabled (Hyper-V is not available as a feature on Home), install Claude Desktop to the default location on C:.
In an elevated PowerShell, confirm the prerequisites are healthy:
sc.exe query vmcompute → RUNNING
sc.exe query hns → RUNNING
Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform → Enabled
Start the workspace service manually: sc.exe start CoworkVMService. It reaches RUNNING and creates the named pipe — confirm with:
Get-ChildItem \\.\pipe\ | Where-Object { $_.Name -like 'cowork' } → cowork-vm-service is present.
Open Claude Desktop and switch to the Cowork tab. Wait 60 seconds.
The UI shows "Claude's workspace service isn't running."
Re-run sc.exe query CoworkVMService → now STOPPED with Win32 exit code 1067 and service exit code 0. The service aborts as soon as the app connects.
C:\ProgramData\Claude\Logs\cowork-service.log contains only "Client connected" entries, one per second, with no VM creation attempt and no error.

The service stays up indefinitely while idle. It only aborts once the app connects. Reinstalling the workspace fails to help, and reinstalling the desktop app does not change the behavior. Also reproduces with the third-party firewall service (wfcs) stopped.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.40609.0.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

This is a Claude Desktop / Cowork workspace bug, not a Claude Code CLI issue. The "Claude Code Version" field above contains the Claude Desktop package version, and "Terminal/Shell" refers to the elevated PowerShell session used to inspect the service — no CLI is involved. Filing here because this repo carries the area:cowork and area:desktop labels.

Windows display language is Spanish, so sc.exe output is localized. Win32 code 1067 is ERROR_PROCESS_ABORTED; [SC] OpenService ERROR 5 is access denied.

Environment: Windows 11 Home 24H2 (Hyper-V is not offered as an optional feature on Home; VirtualMachinePlatform is Enabled). Claude Desktop installed to the default location on C:, not a secondary drive.

Two separate observations that may or may not be relevant:

sc.exe failure CoworkVMService ... returns access denied in an elevated session because the service is registered as WIN32_PACKAGED_PROCESS, so recovery actions cannot be configured and the service stays dead after an abort until started manually.
Windows Error Reporting logs repeated crashes of an unrelated third-party firewall component on this machine. Stopping that service does not change the Cowork failure, so it appears incidental — noting it only for completeness.

Possibly related existing issues: #48468, #59794, #27801, #40392, #48001. None matches this signature (service reaches RUNNING and creates the pipe, then aborts with 1067 on client connect, with no diagnostic written).

View original on GitHub ↗