›_ Claude Code Issues
Claude Code Issues / #29941

[BUG] CoworkVMService fails to start — "signature verification initialization failed: failed to get service executable path" (Windows 11 Pro)

Resolved 💬 38 comments Opened Mar 2, 2026 by ThrmalDeveloper Closed May 26, 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?

CoworkVMService consistently fails to start on Windows 11 Pro. The service loads HCS/HCN DLLs successfully but then crashes during signature verification, reporting it cannot find its own executable path — despite the executable existing and having a valid Authenticode signature.

This prevents the Cowork VM from booting, which causes:

  • "Failed to start Claude's workspace — VM service not running" on the Cowork tab
  • "Failed to load marketplaces — Marketplace not found" when browsing plugins
  • "Failed to load marketplaces — VM service not running. The service failed to start." on retry

Error from cowork-service.log

2026/02/28 23:18:52.653757 Service error: signature verification initialization failed: failed to get service executable path: The system cannot find the path specified.

This error repeats on every service start attempt. Full log sequence:

Starting CoworkVMService as Windows service
Claude VM Service starting...
Waiting for configuration from app via 'configure' method...
[HCS] Initializing HCS DLLs...
Warning: failed to open service for recovery config: Access is denied.
[HCS] vmcompute.dll loaded successfully
[HCS] computecore.dll loaded successfully
[HCS] Procs initialized, HCS ready
[HCN] Initialized HCN API from computenetwork.dll
[HCN] EnumerateNetworks result: []
Service error: signature verification initialization failed: failed to get service executable path: The system cannot find the path specified.

Diagnostic Findings

Service executable exists and is valid

PS> (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService").ImagePath
# "C:\Program Files\WindowsApps\Claude_1.1.4498.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"

PS> Test-Path "C:\Program Files\WindowsApps\Claude_1.1.4498.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
# True

PS> Get-AuthenticodeSignature "C:\Program Files\WindowsApps\Claude_1.1.4498.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
# Status: Valid
# SignerCertificate: 0D7581D2C51C59DF686C3000C70BF543F9F6C6CB

Service configuration

PS> Get-WmiObject Win32_Service -Filter "Name='CoworkVMService'" | Select StartName
# LocalSystem

PS> Get-Service CoworkVMService | Select Status
# Stopped

Hyper-V is enabled and running

PS> Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V | Select State
# Enabled

PS> Get-Service vmcompute, vmms | Format-Table Name, Status
# vmcompute  Running
# vmms       Running

PS> Get-VMSwitch | Format-Table Name, SwitchType
# Default Switch  Internal

No NAT conflicts

PS> Get-NetNat
# (empty — no NAT rules)

PS> Get-NetAdapter | Where-Object {$_.Name -like "*cowork*"}
# (empty — no Cowork network adapter created)

PS> Get-VM
# (empty — no VMs exist)

VM bundle is complete

PS> Get-ChildItem "$env:APPDATA\Claude\vm_bundles\claudevm.bundle" | Format-Table Name, Length
# initrd           175549736
# initrd.zst       171552961
# rootfs.vhdx     9252634624
# rootfs.vhdx.zst 2326875206
# vmlinuz           14965128
# vmlinuz.zst       14710568

cowork_vm_node.log shows module loads but never progresses

2026-03-01 16:05:56 [info] [VM] Loading vmClient (TypeScript) module...
2026-03-01 16:05:56 [info] [VM] Module loaded successfully

No network status or API reachability entries ever appear.

Windows Event Log

Service Control Manager:
The Claude service terminated with the following service-specific error: %%1
The CoworkVMService service terminated with the following service-specific error: %%1

Steps to Reproduce

  1. Install Claude Desktop v1.1.4498.0 on Windows 11 Pro
  2. Ensure Hyper-V, Virtual Machine Platform, and Windows Hypervisor Platform are all enabled
  3. Open Claude Desktop and switch to Cowork tab
  4. Observe "Failed to start Claude's workspace — VM service not running"
  5. Browse plugins → "Failed to load marketplaces"

Remediation Attempted (all failed)

  • Enabled Hyper-V and Windows Hypervisor Platform (were previously disabled), rebooted
  • Deleted VM bundle ($env:APPDATA\Claude\vm_bundles) and let it re-download
  • Full uninstall (Get-AppxPackage -Name "Claude" | Remove-AppxPackage) and reinstall from claude.ai/download
  • Manually attempted Start-Service CoworkVMService — fails with StartServiceFailed error
  • Confirmed no Docker, WSL2, Podman, or CRC installed (no NAT or vsock conflicts)

Suspected Root Cause

The service's internal signature verification routine is unable to resolve its own executable path from within the MSIX/WindowsApps package context, even though the file exists and is validly signed. This may be a path resolution issue specific to how the MSIX package registers the Windows service — possibly the service process cannot access or enumerate the WindowsApps virtual filesystem path at runtime despite LocalSystem privileges.

Environment

  • OS: Windows 11 Pro (64-bit)
  • Claude Desktop: v1.1.4498.0 (MSIX package)
  • Hyper-V: Enabled
  • Docker/WSL2/Podman/CRC: None installed
  • TEMP directory: Default (C: drive)

Related Issues

  • #27801 — Cowork: "Failed to start Claude's workspace" — VM service not running
  • #24918 — Cannot connect to Claude API from workspace (Windows 11 Home)
  • #25308 — Cowork VM starts but API is UNREACHABLE on Windows 11
  • #27010 — Cowork VM service not running on Windows 10 Pro
  • #26951 — Plugin install fails with HTTP 404, plugins.claude.ai does not resolve

Note: This issue is distinct from the above — the service never starts at all due to a signature verification/path resolution failure, before any networking is attempted.

What Should Happen?

The CoworkVMService should start successfully, boot the VM, create the Cowork network adapter, and establish API connectivity — enabling the Cowork workspace and plugin marketplace to function normally

Error Messages/Logs

First Error Message:

Failed to start Claude's workspace
VM service not running. The service failed to start.
Restarting Claude or your computer sometimes resolves this. If it persists, you can
reinstall the workspace or share your debug logs to help us improve.


Second Error Message:

Failed to load marketplaces
Error invoking remote method '$eipc_message$_8da60cf1-ffca-4300-be84-
6af2f603bd1c_$_claude.web_$_CustomPlugins_$_listMarketplaces': Error: VM service not
running. The service failed to start.
Restarting Claude or your computer sometimes resolves this. If it persists, you can
reinstall the workspace or share your debug logs to help us improve.


Third Error Message:

Failed to load marketplaces
Marketplace not found.
Restarting Claude or your computer sometimes resolves this. If it persists, you can
reinstall the workspace or share your debug logs to help us improve.

*images of the error messages are attached to "What's Wrong" Section*

Steps to Reproduce

  1. Open Claude program.
  2. Select Cowork from the top.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude Desktop**: v1.1.4498.0 (MSIX package)

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Attached: PowerShell diagnostic log, plus three screenshots showing the Cowork tab VM error, marketplace "not found" error, and marketplace "VM service not running" error.

<img width="2500" height="2000" alt="Image" src="https://github.com/user-attachments/assets/4211af9a-0ac9-4f63-ba3f-a5ff4433acf8" />
<img width="2500" height="2000" alt="Image" src="https://github.com/user-attachments/assets/22c8130e-6029-415c-b7db-4f0289610be7" />
<img width="2500" height="2000" alt="Image" src="https://github.com/user-attachments/assets/eb21bff9-3588-48c2-9173-0d9fd0dcc612" />

Windows PowerShell Diagnostic Steps on VM Connection issue.txt

View original on GitHub ↗

38 Comments

github-actions[bot] · 4 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/29862
  2. https://github.com/anthropics/claude-code/issues/27897
  3. https://github.com/anthropics/claude-code/issues/29657

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

ThrmalDeveloper · 4 months ago

This is not a duplicate. The root cause in my case is specific and distinct: the CoworkVMService crashes during signature verification with the error signature verification initialization failed: failed to get service executable path: The system cannot find the path specified. (from cowork-service.log). The executable exists at the registered path and has a valid Authenticode signature, yet the service cannot resolve its own path at runtime within the MSIX package context. This failure occurs before any VM boot, networking, or API reachability — none of the flagged issues describe this specific error."

Found 3 possible duplicate issues: 1. [[BUG] Cowork VM fails to start on Windows — smol-bin.x64.vhdx has EFS Encrypted attribute, CopyFileW fails #29862](https://github.com/anthropics/claude-code/issues/29862) 2. [[BUG] [Desktop App] Cowork VM completely broken on Windows 11 Insider (MSIX) - Unresolved EXDEV rename bug in v1.1.4010 #27897](https://github.com/anthropics/claude-code/issues/27897) 3. Cowork VM fails to build bundle on Windows 11 Home — VM service stops, bundle empty (rootfs.vhdx/sessiondata.vhdx missing) #29657 This issue will be automatically closed as a duplicate in 3 days. If your issue is a duplicate, please close it and 👍 the existing issue instead To prevent auto-closure, add a comment or 👎 this comment 🤖 Generated with Claude Code
ChrisbyChA · 4 months ago

Confirming this exact issue on a clean Windows 11 Pro setup.

Environment:

  • Windows 11 Pro (Build 26200), i9-14900KF, 64GB RAM, RTX 4080 Super
  • Claude Desktop v1.1.5368 (MSIX: Claude_1.1.5368.0_x64__pzs8sxrjxfjjc)
  • Hyper-V fully enabled (all features confirmed via Get-WindowsOptionalFeature)
  • vmcompute and vmms services running

Reproduction:

  • cowork-svc.exe exists and is valid at the registered ImagePath
  • Service type: WIN32_PACKAGED_PROCESS, StartName: LocalSystem
  • Every start attempt terminates immediately with Event 7024: "Incorrect function"
  • cowork-service.log consistently shows:

``
Service error: signature verification initialization failed: failed to get service executable path: The system cannot find the path specified.
``

What I've tried (all failed):

  1. Full uninstall via Remove-AppxPackage + fresh reinstall (twice)
  2. Deleting vm_bundles and letting Claude re-download (rootfs.vhdx, vmlinuz, initrd all validated)
  3. Restarting vmcompute/vmms before starting CoworkVMService
  4. VM bundle downloads succeed, SDK path (claude-code-vm) never gets created (exists: false)

The service loads HCS/HCN DLLs successfully but crashes at signature verification before it ever attempts to start a VM. This is blocking Cowork entirely — no workaround available on the user side.

elcontemplador · 4 months ago

Confirming the same issue.

Environment:

  • Windows 11 Pro, Claude Desktop v1.1.5749.0 (MSIX: Claude_1.1.5749.0_x64__pzs8sxrjxfjjc)
  • Hyper-V enabled, vmcompute and vmms running
  • cowork-svc.exe exists at the registered ImagePath and is valid
  • SignatureKind: Developer

Same behavior:

  • Service loads HCS/HCN DLLs successfully, then crashes with:

``
Service error: signature verification initialization failed: failed to get service executable path: The system cannot find the path specified.
``

  • 12 consecutive start attempts today, all identical failure
  • VM bundle downloads completed successfully (rootfs.vhdx, vmlinuz, initrd all validated)
  • Full uninstall + reinstall (twice) did not resolve

No workaround found on the user side.

theopeixoto23 · 4 months ago

Same issue here — Windows 11 Pro (upgraded from Home), Claude Desktop v1.1.6041.0

Environment

  • OS: Windows 11 Pro 25H2 (Build 26200) — in-place upgrade from Home edition
  • Claude Desktop: v1.1.6041.0 (MSIX)
  • Hyper-V: Enabled and running (vmms Running/Automatic, vmcompute Running/Manual)
  • CoworkVMService: Stopped, ExitCode 1066
  • Service executable: Exists at registered path, 11,085,136 bytes

Identical error in cowork-service.log

2026/03/10 18:59:39.583163 Service error: signature verification initialization failed: 
  failed to get service executable path: The system cannot find the path specified.

Full sequence matches exactly what's reported in this issue.

Additional finding: EXDEV bug blocks VM bundle download

Before hitting the signature verification error, I encountered a separate blocking issue: the VM bundle download completes successfully but fails when renaming from AppData\Local\Temp to AppData\Roaming\Claude\vm_bundles:

[error] [download] VM download failed: EXDEV: cross-device link not permitted, 
  rename 'C:\Users\theop\AppData\Local\Temp\wvm-tfsQMs\rootfs.vhdx' 
      -> 'C:\Users\theop\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'

Both paths are on the same physical drive (C:), but the MSIX virtualization layer treats them as different filesystems.

Workaround for EXDEV: Creating a symlink from AppData\Roaming\Claude\vm_bundles → AppData\Local\Temp\claude-vm-bundles allowed the download to complete. All bundle files are now present (rootfs.vhdx ~9.2GB, vmlinuz, initrd).

However, even with all VM bundle files in place, the CoworkVMService still fails on signature verification.

What was tried (none resolved the signature verification error)

  1. Full uninstall + deletion of all Claude data directories + clean reinstall
  2. sc.exe delete CoworkVMService before reinstall
  3. Get-AppxPackage | Remove-AppxPackage + reinstall
  4. Re-registering MSIX: Add-AppxPackage -Register AppxManifest.xml -DisableDevelopmentMode
  5. Multiple reboots
  6. Manual Start-Service CoworkVMService

Service path verification

PS> (Get-CimInstance Win32_Service -Filter "Name='CoworkVMService'").PathName
"C:\Program Files\WindowsApps\Claude_1.1.6041.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"

PS> Test-Path "C:\Program Files\WindowsApps\Claude_1.1.6041.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
True

The executable is present and accessible, confirming this is an internal path resolution issue within the MSIX container context.

Note

The Home → Pro upgrade path may leave MSIX/DCOM registrations in a different state than a fresh Pro install, potentially contributing to this bug.

claude-logs-2026-03-10T22-36-49-496Z.zip

avenirperma · 4 months ago

same issue here

Windows 11 Pro 25H2 (migrated from Home)
Erreur : signature verification initialization failed
Claude version 1.1.6041.0

tried reinstalling,
all repairs actions in claude

nuwud · 4 months ago

Confirming identical failure on Windows 11 Pro — clean system, extensive troubleshooting
Environment:

Windows 11 Pro (fully updated)
Claude Desktop v1.1.6679 (f8f4ff) — 2026-03-13
Hyper-V, VirtualMachinePlatform, HypervisorPlatform, Containers, WSL — all enabled
BIOS virtualization confirmed (systeminfo shows "A hypervisor has been detected")
No Docker, no WSL2 distros, no VPN, no conflicting VM software

Symptoms:
Cowork fails every time with "Failed to start Claude's workspace — VM service not running. The service failed to start." The service log shows the same signature verification crash on every startup attempt:
Service error: signature verification initialization failed: failed to get service executable path: The system cannot find the path specified.
The service binary exists and is validly signed at the registered path:
PathName: "C:\Program Files\WindowsApps\Claude_1.1.6679.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
Test-Path: True
HCS/HCN DLLs load successfully — the service crashes specifically during signature verification before any VM or network operations begin.
Troubleshooting performed (none resolved the signature verification error):

Full uninstall (Remove-AppxPackage) → reboot → fresh install — service recreated with same bug
Deleted CoworkVMService via registry (HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService) → reboot → reinstall — same result
Cleaned all VM artifacts (vm_bundles, cowork directories) — VM bundle re-downloaded successfully but service still crashes
Enabled additional features: Containers, HypervisorPlatform — no change
Fixed DCOM 10016 errors: took ownership of CLSID {2593F8B9-4EAF-457C-B68A-50F6B8EA6B54} and APPID {15C20B67-12E7-4BB6-92BB-7AFF07997402} (PerAppRuntimeBroker), granted Local Launch + Local Activation permissions for user, SYSTEM, and Users group — DCOM errors resolved but signature verification still fails
No leftover HNS networks (Get-HnsNetwork shows only Default Switch), no NetNat rules

Analysis:
This appears to be a bug in the service's self-path resolution within the MSIX virtual filesystem. The service runs as LocalSystem and can load system DLLs (vmcompute.dll, computecore.dll, computenetwork.dll) but cannot resolve its own executable path for signature verification. The MSIX package context may not properly expose the WindowsApps path to the service process at runtime.
This is a fresh Windows 11 Pro system with no prior Cowork history, no conflicting software, and all virtualization features enabled — strongly suggesting a platform-level bug in the MSIX service registration rather than an environmental issue.
Relevant logs:

cowork-service.log: Every attempt since March 10 shows identical signature verification initialization failed crash
cowork_vm_node.log: VM bundle downloads and validates checksums successfully; never reaches VM boot
System Event Log: Event 7024 — "The Claude service terminated with the following service-specific error: Incorrect function."

Happy to provide full log files or test patches if helpful.

gybedigitallc · 4 months ago

Confirming identical issue with the following information:

CoworkVMService Fails on Windows 11 Pro 25H2 — Three Bugs Blocking Cowork

Environment: Windows 11 Pro 25H2 (Build 26200.7462), Claude Desktop 1.1.7203.0 (MSIX)

All prerequisites confirmed: Hyper-V, VirtualMachinePlatform, HypervisorPlatform, Containers, Containers-HNS all enabled. No drive compression. No Docker/WSL2/Podman conflicts. Authenticode signature on cowork-svc.exe is valid. SYSTEM has FullControl.

---

Bug 1: Signature Verification Fatal in Service Mode, Graceful in Interactive Mode

The service crashes on startup with:

Service error: signature verification initialization failed:
  failed to get service executable path: The system cannot find the path specified.

However, running cowork-svc.exe interactively from PowerShell produces only a warning and continues:

[Server] WARNING: Could not get service executable path: The system cannot find the path specified.
[Server] WARNING: Client signature verification is DISABLED
[Server] Starting named pipe server on \\.\pipe\cowork-vm-service
Service ready. Listening on \\.\pipe\cowork-vm-service

The graceful fallback exists but is not applied in service mode. Full uninstall and reinstall did not resolve this.

Bug 2: EXDEV Infinite Download Loop

The VM bundle download succeeds and validates, then fails on move:

[info] rootfs.vhdx.zst checksum validated
[error] [download] VM download failed: EXDEV: cross-device link not permitted,
  rename '...\AppData\Local\Temp\wvm-XXXXXX\rootfs.vhdx'
  -> '...\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'

Both paths are on C:. The EXDEV is caused by the MSIX sandbox treating AppData\Local\Temp and AppData\Roaming as different filesystems. The app retries in an infinite loop with no limit — each attempt downloads ~9 GB, fails, deletes the file, and repeats. This silently consumed ~50 GB of bandwidth and temporarily filled my disk during debugging.

Workaround: Creating an NTFS junction at %APPDATA%\Claude\vm_bundles pointing to %LOCALAPPDATA%\Temp\claude_vm_bundles resolves EXDEV and allows the download to complete.

Fix: Add fs.copyFile() + fs.unlink() fallback when fs.rename() throws EXDEV.

Bug 3: VirtioFS Path Mismatch Prevents Workspace Initialization

After working around Bugs 1 and 2, the VM boots and VirtioFS mounts, but Cowork fails with:

RPC error -1: failed to open SDK binary:
  open /mnt/.virtiofs-root/shared/AppData/Local/Packages/Claude_pzs8sxrjxfjjc/
  LocalCache/Roaming/Claude/claude-code-vm/2.1.76/claude: input/output error

The VM reads from the real AppData\Roaming path, but the MSIX app writes files to the virtualized LocalCache\Roaming path. The Claude Code SDK binary exists at the MSIX path but is invisible to the VM. Junction workarounds did not resolve this — Cowork never successfully initialized a workspace.

---

Net Result

All three bugs stem from the same root problem: the MSIX sandbox creates path mismatches between where the app writes and where the service/VM reads. No combination of workarounds produced a fully working Cowork session on this system.

jstarnes88 · 3 months ago

Hitting the same issue on Windows 11 Pro (Build 26200). CoworkVMService consistently fails to start with the same error:

Service error: signature verification initialization failed: failed to get service executable path: The system cannot find the path specified.

Environment:

  • OS: Windows 11 Pro, Version 25H2 (Build 26200.7840)
  • Claude Desktop: v1.1.6041
  • CPU: AMD Ryzen 5 7600X
  • Motherboard: Gigabyte B650 AORUS PRO AX
  • Hyper-V: Enabled, vmms Running (Automatic)
  • HvHost: Running

Steps taken:

  • Full uninstall via Get-AppxPackage -Name "*Claude*" | Remove-AppxPackage and clean reinstall
  • Manually deleted VM bundle at %APPDATA%\Claude\vm_bundles\claudevm.bundle — VM files re-downloaded successfully
  • Attempted Start-Service CoworkVMService — fails with StartServiceFailed
  • Verified cowork-svc.exe exists at the registered path
  • Hyper-V fully enabled and vmms confirmed Running

The HCS/HCN DLLs initialize successfully and a NAT network is now being created (EnumerateNetworks returns a result), but the service crashes immediately after on the signature verification step. The issue persists across reinstalls.

Please prioritize — happy to provide additional logs if helpful.

greydragon21 · 3 months ago

Ran into this issue as well on my PC.

OS: Windows 11 Pro, Version 25H2 Build 26200.8037
Claude Desktop: 1.1.7714
CPU: AMD Ryzen 9 8945HS
GPU: Nvidia RTX 4070

Claude Windows service fails to start.
Tried all suggested workarounds, same result.

cowork-service log output:

2026/03/19 22:50:53.997104 Starting CoworkVMService as Windows service
2026/03/19 22:50:53.998879 Claude VM Service starting...
2026/03/19 22:50:53.998879 Waiting for configuration from app via 'configure' method...
2026/03/19 22:50:53.998879 [HCS] Initializing HCS DLLs...
2026/03/19 22:50:53.999566 Warning: failed to open service for recovery config: Access is denied.
2026/03/19 22:50:54.002044 [HCS] vmcompute.dll loaded successfully
2026/03/19 22:50:54.002732 [HCS] computecore.dll loaded successfully
2026/03/19 22:50:54.002732 [HCS] Procs initialized, HCS ready
2026/03/19 22:50:54.002732 [HCN] Initialized HCN API from computenetwork.dll
2026/03/19 22:50:54.007001 [HCN] EnumerateNetworks result: ["c08cb7b8-9b3c-408e-8e30-5e16a3aeb444"]
2026/03/19 22:50:54.020325 Service error: signature verification initialization failed: failed to get service executable path: The system cannot find the path specified.

Specifically signed up for a paid Claude subscription to use cowork and I'm forced to use it on an old, slow Macbook Pro instead of my much powerful PC, because Anthropic won't even bother to assign a dev. to this bugs after three weeks. Completely unacceptable.

csch1701 · 3 months ago

<img width="896" height="846" alt="Image" src="https://github.com/user-attachments/assets/5614a552-65df-45f6-aec9-94f5d7d884a1" />

Hitting the same issue on Windows 11 Pro (Build 26200). CoworkVMService consistently fails to start with the same error:
Service error: signature verification initialization failed: failed to get service executable path: The system cannot find the path specified.

Environment:
OS: Windows 11 Pro, Version 24H2 (Build 26200.8037)
Claude Desktop: v1.1.7714
CPU: Intel i9-13900KF
Motherboard: ASUS PRIME Z790-P WIFI
RAM: 64GB DDR5-5600
Hyper-V: Enabled and actively in use — running Windows 11 Pro and Ubuntu VMs successfully
WSL2: Installed and confirmed working (wsl --status returns Default Version: 2, Ubuntu distribution installed)
VirtualMachinePlatform: Enabled via DISM
vmcompute: Running

Steps taken:
Enabled VirtualMachinePlatform via DISM
Installed WSL2 and Ubuntu distribution manually (neither was present initially)
Multiple full uninstalls and reinstalls of Claude Desktop
Clicked "reinstall the workspace" in the Cowork UI — app relaunched, error persists
Verified cowork-svc.exe exists at the registered path in WindowsApps
Submitted debug logs via "share your debug logs" link

Notable: This machine was arguably better prepared than most — Hyper-V was already fully operational with running VMs before any Claude installation. The signature verification failure occurs regardless.
The HCS/HCN DLLs initialize successfully and EnumerateNetworks returns results, but the service crashes immediately on the signature verification step. Persists across 8+ reboots and multiple clean reinstalls over a period of several days and multiple app version updates.

Additional diagnostics:
AppX Package: Claude_1.1.7714.0_x64__pzs8sxrjxfjjc
Service type: 210 (WIN32_PACKAGED_PROCESS)
Service exit code: 1066 (ERROR_SERVICE_SPECIFIC_ERROR)
SCM event 7024: "Incorrect function" (maps to ERROR_INVALID_FUNCTION)
Service has been reinstalled multiple times (SCM logs show install events on 3/17, 3/18, and 3/19)
cowork-svc.exe confirmed present at registered path
Root cause appears to be that the service process, running as LocalSystem inside the MSIX WIN32_PACKAGED_PROCESS container, cannot resolve its own executable path — failing before any VM initialization occurs

cassatoa-cyber · 3 months ago

same issue

Environment:

  • Claude Desktop version: 1.1.7714.0 (MSIX install, non-Store)
  • OS: Windows 11 pro 25H2 build 26200.8037 (AMD x64)
  • Hyper-V: Enabled
  • VirtualMachinePlatform: Enabled
  • Containers: Enabled
  • Containers-HNS: Enabled
  • HypervisorPlatform: Enabled
  • vmcompute service: Running
  • vmms service: Running
  • Subscription: Paid plan

Behavior:
CoworkVMService (display name "Claude") is installed and set to Automatic startup, but crashes immediately on every start attempt with service-specific error code 1.

The VM bundle files download successfully (rootfs.vhdx, vmlinuz, initrd all pass checksum validation), but the service dies before the VM ever boots.

From cowork-service.log (identical on every startup attempt):

[HCS] vmcompute.dll loaded successfully
[HCS] computecore.dll loaded successfully
[HCS] Procs initialized, HCS ready
[HCN] Initialized HCN API from computenetwork.dll
[HCN] EnumerateNetworks result: ["790e58b4-...","c08cb7b8-..."]
Service error: signature verification initialization failed: failed to get service executable path: The system cannot find the path specified.

Also seeing in cowork-service.log on every attempt:

Warning: failed to open service for recovery config: Access is denied.

From cowork_vm_node.log:

[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...

The service successfully initializes all HCS/HCN DLLs and enumerates networks, then fails at the signature verification step because it cannot resolve its own executable path from within the MSIX package context.

All system-level prerequisites are confirmed enabled and running. This is not a configuration issue — it's a packaging/path resolution defect.

This has been persisting across multiple app restarts and reinstalls. As a paying subscriber, Cowork was a primary reason for my subscription and it has never worked. A fix or at minimum an official acknowledgment with a timeline would be appreciated.

cassatoa-cyber · 3 months ago

I found a workaround, here is a script you can run as admin and leave the window open. It will check for your version of Claude, take ownership of the binary, then run it interactively as admin:

$claudePath = (Get-ChildItem "C:\Program Files\WindowsApps\Claude_*_x64__pzs8sxrjxfjjc" -Directory | Sort-Object Name -Descending | Select-Object -First 1).FullName

if (-not $claudePath) {
    Write-Host "Claude installation not found." -ForegroundColor Red
    exit
}

Write-Host "Found Claude at: $claudePath" -ForegroundColor Green

takeown /F "$claudePath" /R /D Y | Out-Null
icacls "$claudePath" /grant Administrators:F /T | Out-Null

Stop-Service CoworkVMService -Force -ErrorAction SilentlyContinue

Write-Host "Starting cowork-svc.exe — leave this window open..." -ForegroundColor Yellow
& "$claudePath\app\resources\cowork-svc.exe"

The root cause: When CoworkVMService runs as a Windows service, the signature verification step fatally crashes because it can't resolve its own executable path within the MSIX package context. However, when run interactively from an elevated shell, it gracefully degrades — it warns about the path issue, disables client signature verification, and starts listening normally.

Service mode (crashes):

Service error: signature verification initialization failed: failed to get service executable path: The system cannot find the path specified.

Interactive mode (works):

[Server] WARNING: Could not get service executable path: The system cannot find the path specified.
[Server] WARNING: Client signature verification is DISABLED
[Server] Starting named pipe server on \\.\pipe\cowork-vm-service
[Server] Named pipe server listening
[VM] Event callbacks set
Service ready. Listening on \\.\pipe\cowork-vm-service

My environment:

  • Claude Desktop: 1.1.7714.0 (MSIX, non-Store)
  • OS: Windows (AMD Ryzen 5 5500, x64)
  • Hyper-V, VirtualMachinePlatform, Containers, Containers-HNS, HypervisorPlatform: all Enabled
  • vmcompute and vmms: both Running
  • cowork_vm_node.log also shows yukonSilver not supported but this doesn't prevent the workaround from succeeding

Note for Anthropic: The fix here seems straightforward... the service mode treats the path resolution failure as fatal while interactive mode treats it as a non-fatal warning and disables signature verification. Making the service mode behave the same way (graceful degradation) would likely resolve this for everyone affected.

Related issues: #25136, #32574, #27010, #31703

calebsakala · 3 months ago

Confirming the same error. Windows 11 Home. The CoworkVMService fails to start every time, and I've exhausted all troubleshooting steps.

Environment:

  • OS: Windows 11 Home
  • Computer name: Emperor
  • Claude Desktop: Latest version (installed from claude.ai/download)

The Problem:
When Claude Desktop attempts to start the CoworkVMService, it crashes during startup with the error: "Service error: signature verification initialization failed: failed to get service executable path: The system cannot find the path specified."

The System Event Log (Event ID 7024) reports: "The Claude service terminated with the following service-specific error: Incorrect function."

What I've Tried:

  1. Enabled Virtual Machine Platform, Windows Hypervisor Platform, and Windows Subsystem for Linux via Windows Features, then rebooted. (Note: The Containers feature and Hyper-V are not available on Windows 11 Home. The PowerShell commands Enable-WindowsOptionalFeature for both Containers and HypervisorPlatform returned "Class not registered" errors.)
  1. Cleared the app state by deleting:
  • %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude
  • %APPDATA%\Claude
  1. Rebooted multiple times.

After all of the above, the service gets further in its startup sequence but still fails at the same point. The Application Event Log shows this sequence:

  • "Starting CoworkVMService as Windows service"
  • "Claude VM Service starting..."
  • "Waiting for configuration from app via 'configure' method..."
  • "[HCS] Initializing HCS DLLs..."
  • "Warning: failed to open service for recovery config: Access is denied."
  • "[HCS] vmcompute.dll loaded successfully"
  • "[HCS] computecore.dll loaded successfully"
  • "[HCS] Procs initialized, HCS ready"
  • "[HCN] Initialized HCN API from computenetwork.dll"
  • "[HCN] EnumerateNetworks result: []"
  • "Service error: signature verification initialization failed: failed to get service executable path: The system cannot find the path specified."

As you can see, all the HCS and HCN components load successfully, but the service crashes at the signature verification step because it cannot resolve its own executable path.

fkx2016 · 3 months ago

Additional data point: Windows 10 Pro 25H2 Build 26220

Same exact failure. Extensive diagnostics confirm this is an MSIX VFS path resolution bug in cowork-svc.exe.

Environment

  • OS: Windows 10 Pro 25H2 Build 26220
  • Claude: v1.1.8359.0 (MSIX, SignatureKind: Developer)
  • Hyper-V: Enabled (vmcompute + vmms running)
  • VirtualMachinePlatform: Enabled
  • WSL: Enabled
  • HypervisorPlatform: Disabled (does not appear required)
  • Developer Mode: Enabled
  • NTFS Compression: Disabled (confirmed on C: and all bundle paths)
  • VM Bundle: Complete (~12GB, all files present, checksums validated by app)

Error (identical to OP)

Service error: signature verification initialization failed: 
failed to get service executable path: The system cannot find the path specified.

What I verified

  • cowork-svc.exe exists at registered ImagePath and has valid Authenticode signature (Anthropic EV cert, thumbprint 0D7581D2C51C59DF686C3000C70BF543F9F6C6CB)
  • Service loads HCS/HCN DLLs successfully, initializes Hyper-V — crashes during self-signature verification
  • No NAT conflicts, no stale HNS networks, no VM remnants
  • Service runs as LocalSystem — should have full filesystem access
  • Manually starting service via Start-Service produces same crash
  • ExitCode 1066, ServiceSpecificExitCode 1

What I tried (all failed)

  1. Manual Start-Service CoworkVMService — same crash
  2. Robocopy cowork-svc.exe to C:\ProgramData\Claude\Service\ + registry ImagePath redirect — MSIX SCM blocks non-package service paths
  3. Junction fix for vm_bundles\claudevm.bundle → %TEMP% (from prior EXDEV rename bug #25911) — junction works but unrelated to this failure
  4. Full uninstall + reinstall — same result
  5. Multiple reboots — same result

Windows Event Log confirms

Provider: CoworkVMService
Message: Claude VM Service error: signature verification initialization failed: 
         failed to get service executable path: The system cannot find the path specified.

Provider: Service Control Manager
Message: The Claude service terminated with the following service-specific error: Incorrect function.

Root cause analysis

The cowork-svc.exe binary uses some form of self-path resolution (likely GetModuleFileName or equivalent) that fails inside the MSIX VFS layer. The service runs as a Win32 service outside the MSIX package activation context, so C:\Program Files\WindowsApps\... isn't fully resolvable from the service process's perspective.

This is the same class of MSIX-on-Windows bug as the fs.rename() EXDEV error (#25911) — operations that assume a traditional filesystem but are running inside MSIX virtual paths.

Suggested fix

Use QueryFullProcessImageName or read the service's own registry ImagePath at HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService instead of relying on runtime path resolution APIs that fail in MSIX VFS contexts.

tiranmoskovitch-dev · 3 months ago

Found a workaround for this. The signature verification fails because cowork-svc.exe can't resolve its own path when running as a packaged Windows service inside WindowsApps.

Fix: Copy the exe out and run it in interactive mode:

# Admin PowerShell
Stop-Service CoworkVMService -Force -ErrorAction SilentlyContinue
Copy-Item "C:\Program Files\WindowsApps\Claude_*_x64__*\app\resources\cowork-svc.exe" "$env:USERPROFILE\cowork-svc.exe"
& "$env:USERPROFILE\cowork-svc.exe"

Keep the window open, launch Claude Desktop. Workspace works.

For a permanent fix with auto-start at logon + auto-update sync: https://github.com/tiranmoskovitch-dev/claude-vm-fix

csch1701 · 3 months ago

Heads up to anyone considering the "permanent fix" linked above at github.com/tiranmoskovitch-dev/claude-vm-fix — it's a $9.99 paywall wrapped around the exact same free manual workaround already posted in this thread:

  1. Copy cowork-svc.exe out of WindowsApps
  2. Run it interactively
  3. Add a scheduled task for auto-start

That's it. That's the $9.99 "product." The free manual steps are literally documented in his own README under "Free manual fix (no purchase needed)."

This person is monetizing a bug that Anthropic created and has not fixed. The repo has zero stars, zero forks, and no published releases. There is no reason to pay for this.

Anthropic — this is what happens when a shipped product stays broken for 6+ weeks. Someone shows up to charge your paying customers $10 to work around your bug. Please fix this.

ThrmalDeveloper · 3 months ago

My fix for this was to wipe my PC and do a fresh install of Windows 11 Pro. Run all the system updates then install Claude followed by all the other applications I use. Something about that fixed the issue. But that shouldn't be the way to go for this and everyone can't do it.

Cassatoa-Cyber wrote a solution in this thread that appears to work. Run with that one and avoid the pay solution someone recently posted.

verkaufsoptimierung · 3 months ago

Confirmed on Windows 11 Pro 10.0.26200, Claude 1.1.9310.0 (MSIX).
Same error in cowork-service.log:
signature verification initialization failed: failed to get service executable path: The system cannot find the path specified.
The workaround posted by tiranmoskovitch-dev (copying cowork-svc.exe out of WindowsApps and running interactively) also fails on my system due to EFS encryption on the source file:
Copy-Item: Die angegebene Datei konnte nicht verschlüsselt werden.
Attempts to work around the EFS encryption also failed:

robocopy /EFSRAW → Access denied on source directory
takeown + icacls + Copy-Item → takeown succeeds, copy still fails with EFS error
cipher /d → "Falscher Parameter" (wrong parameter)

The cowork-svc.exe inside WindowsApps is inaccessible even to administrators. No user-side workaround available.
All other prerequisites confirmed:

Hyper-V enabled, vmcompute + vmms running
Virtualization enabled in BIOS
Test-Path on cowork-svc.exe returns True
15+ start attempts documented in cowork-service.log since 11.03.2026

cliff-simpkins · 3 months ago

Reproducing on Windows 11 Pro, Claude Desktop v1.1.9310.0
Same failure, different system. Full diagnostics:

  • OS: Windows 11 Pro
  • Hyper-V: Enabled, VirtualMachinePlatform: Enabled, HypervisorPlatform: Enabled (had to enable the latter two manually)
  • vmcompute + vmms: Running
  • RegisteredImagePath: C:\Program Files\WindowsApps\Claude_1.1.9310.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe
  • Test-Path on that path: True
  • Get-AuthenticodeSignature: Status: Valid
  • Full MSIX uninstall + reinstall: same result

HCS/HCN DLLs all load successfully. Failure happens consistently at signature verification / path resolution step. Full log attached.

cowork-service.log

verkaufsoptimierung · 3 months ago

Still broken on Claude Desktop v1.1.9493. No change after update.

fkx2016 · 3 months ago

not sure if this helps any but i have several windows 11 where desktop
cowork works fine and one that has the problem, they are different
combinations of win 11 regular, preview, evaluation etc etc

all 25H2

my claude.ai has identified the same details as reported including ghe
unaddressed fixes.
i think there is one setting somewhere in win 11 responsible.
I expect it will be fixed by anthropic soon.

Frank Kurka inferencedevices.com
Serving the Personal AI Community
(617) 910-0092 (voicemail)

@.*** (857) 231-1046 (mobile)
44 Mechanic Street, Suite 213, Newton Upper Falls, MA 02464

Newsletter:
See the past newsletters and sign up free: https://fkxx.substack.com

Socials
X: @fkurka
LinkedIn: https://www.linkedin.com/in/fkxai/

My first book:
What is Artificial Intelligence
https://www.amazon.com/dp/B0FRGM33T4

Author Book App:
https://talk-to-the-book.lovable.app

Medium.com
@.***

Get a beehiiv subscription for your own organization
https://www.beehiiv.com?via=fkx <https://www.beehiiv.com/?via=fkx>

On Sun, Mar 29, 2026 at 4:15 PM verkaufsoptimierung <
@.***> wrote:

verkaufsoptimierung left a comment (anthropics/claude-code#29941) <https://github.com/anthropics/claude-code/issues/29941#issuecomment-4151008552> Still broken on Claude Desktop v1.1.9493. No change after update. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/29941?email_source=notifications&email_token=AD7SVYRHU6VFODQ5BWGHNTD4TGG77A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJVGEYDAOBVGUZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4151008552>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD7SVYUJE2A3PLVXGRD3RDT4TGG77AVCNFSM6AAAAACWDUUOISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCNJRGAYDQNJVGI> . You are receiving this because you commented.Message ID: @.***>
verkaufsoptimierung · 3 months ago
not sure if this helps any but i have several windows 11 where desktop cowork works fine and one that has the problem, they are different combinations of win 11 regular, preview, evaluation etc etc all 25H2 my claude.ai has identified the same details as reported including ghe unaddressed fixes. i think there is one setting somewhere in win 11 responsible. I expect it will be fixed by anthropic soon. Frank Kurka inferencedevices.com Serving the Personal AI Community (617) 910-0092 (voicemail) @.*** (857) 231-1046 (mobile) 44 Mechanic Street, Suite 213, Newton Upper Falls, MA 02464 Newsletter: See the past newsletters and sign up free: https://fkxx.substack.com Socials X: @fkurka LinkedIn: https://www.linkedin.com/in/fkxai/ My first book: What is Artificial Intelligence https://www.amazon.com/dp/B0FRGM33T4 Author Book App: https://talk-to-the-book.lovable.app Medium.com @.*** Get a beehiiv subscription for your own organization https://www.beehiiv.com?via=fkx <https://www.beehiiv.com/?via=fkx> […](#)

Do you know which specific setting differs between the working and non-working systems? I have been troubleshooting this for days and cannot identify the difference.

csch1701 · 3 months ago

I have some input. I have a vm (hyper-v) running fully licensed windows 11 pro. Claude Cowork functions fine there.

On my host machine (which is runs the hyper-v VM) it does not. It is also fully licensed windows 11 pro.

verkaufsoptimierung · 3 months ago
I have some input. I have a vm (hyper-v) running fully licensed windows 11 pro. Claude Cowork functions fine there. On my host machine (which is runs the hyper-v VM) it does not. It is also fully licensed windows 11 pro.

This is very interesting. Does Cowork require nested virtualization support? On my system Hyper-V is enabled as host, and CoworkVMService fails with the same signature verification error. Could the issue be related to how Cowork interacts with an already-active Hyper-V host environment?

csch1701 · 3 months ago

verkauf:

It could very well be. I had Hyper-V up and running with two different VMs long before I ever installed Claude Cowork. My Windows 11 Professional VM (QCoreVM) itself runs Claude Cowork fine. Just my host machine does not.
Checked nested virtualization on my Windows 11 Pro VM:

VMName   ExposeVirtualizationExtensions
------   ------------------------------
QCoreVM  True

This seems to confirm your theory — Cowork may require nested virtualization support, and something about running as a Hyper-V host breaks that path.

verkaufsoptimierung · 3 months ago

Still broken on Claude Desktop v1.2.234. No change after update.

bugparty · 3 months ago

in the meanwhile , what you can do is open the powershell administrator and execute the following code:

# Step 1: takeown all Claude versions
Get-ChildItem "C:\Program Files\WindowsApps" -Directory -Filter "Claude_*" | ForEach-Object {
    Write-Host "Taking ownership: $($_.FullName)"
    takeown /F $_.FullName /R /D Y
    icacls $_.FullName /grant Administrators:F /T
}

# Step 2: find latest cowork-svc.exe and launch it
$latest = Get-ChildItem "C:\Program Files\WindowsApps" -Directory -Filter "Claude_*" |
    Sort-Object Name -Descending |
    Select-Object -First 1

$svcPath = Join-Path $latest.FullName "app\resources\cowork-svc.exe"

if (Test-Path $svcPath) {
    Write-Host "Starting: $svcPath"
    net stop CoworkVMService 2>$null
    Start-Process $svcPath
    Write-Host "Cowork service started. You can close this window."
} else {
    Write-Host "ERROR: cowork-svc.exe not found at $svcPath"
}
verkaufsoptimierung · 3 months ago

Still broken on Claude Desktop v1.569.0. No change after update.

verkaufsoptimierung · 3 months ago
in the meanwhile , what you can do is open the powershell administrator and execute the following code: `` # Step 1: takeown all Claude versions Get-ChildItem "C:\Program Files\WindowsApps" -Directory -Filter "Claude_*" | ForEach-Object { Write-Host "Taking ownership: $($_.FullName)" takeown /F $_.FullName /R /D Y icacls $_.FullName /grant Administrators:F /T } # Step 2: find latest cowork-svc.exe and launch it $latest = Get-ChildItem "C:\Program Files\WindowsApps" -Directory -Filter "Claude_*" | Sort-Object Name -Descending | Select-Object -First 1 $svcPath = Join-Path $latest.FullName "app\resources\cowork-svc.exe" if (Test-Path $svcPath) { Write-Host "Starting: $svcPath" net stop CoworkVMService 2>$null Start-Process $svcPath Write-Host "Cowork service started. You can close this window." } else { Write-Host "ERROR: cowork-svc.exe not found at $svcPath" } ``

Tried it before in single Steps and now all in one but without positive effect.

fkx2016 · 3 months ago

I gave up on the stubborn pc and just use one where it works 🤷‍♂️

Frank Kurka inferencedevices.com
Serving the Personal AI Community
(617) 910-0092 (voicemail)

@.*** (857) 231-1046 (mobile)
44 Mechanic Street, Suite 213, Newton Upper Falls, MA 02464

Newsletter:
See the past newsletters and sign up free: https://fkxx.substack.com

Socials
X: @fkurka
LinkedIn: https://www.linkedin.com/in/fkxai/

My first book:
What is Artificial Intelligence
https://www.amazon.com/dp/B0FRGM33T4

Author Book App:
https://talk-to-the-book.lovable.app

Medium.com
@.***

Get a beehiiv subscription for your own organization
https://www.beehiiv.com?via=fkx <https://www.beehiiv.com/?via=fkx>

On Sat, Apr 4, 2026 at 5:44 AM verkaufsoptimierung @.***>
wrote:

verkaufsoptimierung left a comment (anthropics/claude-code#29941) <https://github.com/anthropics/claude-code/issues/29941#issuecomment-4186852619> in the meanwhile , what you can do is open the powershell administrator and execute the following code: # Step 1: takeown all Claude versions Get-ChildItem "C:\Program Files\WindowsApps" -Directory -Filter "Claude_" | ForEach-Object { Write-Host "Taking ownership: $($_.FullName)" takeown /F $_.FullName /R /D Y icacls $_.FullName /grant Administrators:F /T } # Step 2: find latest cowork-svc.exe and launch it $latest = Get-ChildItem "C:\Program Files\WindowsApps" -Directory -Filter "Claude_" | Sort-Object Name -Descending | Select-Object -First 1 $svcPath = Join-Path $latest.FullName "app\resources\cowork-svc.exe" if (Test-Path $svcPath) { Write-Host "Starting: $svcPath" net stop CoworkVMService 2>$null Start-Process $svcPath Write-Host "Cowork service started. You can close this window." } else { Write-Host "ERROR: cowork-svc.exe not found at $svcPath" } Tried it before in single Steps and now all in one but without positive effect. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/29941#issuecomment-4186852619>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD7SVYWIALMX7J4VG2RZRJ34UDKRPAVCNFSM6AAAAACWDUUOISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCOBWHA2TENRRHE> . You are receiving this because you commented.Message ID: @.***>
verkaufsoptimierung · 3 months ago
I gave up on the stubborn pc and just use one where it works 🤷‍♂️ Frank Kurka inferencedevices.com Serving the Personal AI Community (617) 910-0092 (voicemail) @.*** (857) 231-1046 (mobile) 44 Mechanic Street, Suite 213, Newton Upper Falls, MA 02464 Newsletter: See the past newsletters and sign up free: https://fkxx.substack.com Socials X: @fkurka LinkedIn: https://www.linkedin.com/in/fkxai/ My first book: What is Artificial Intelligence https://www.amazon.com/dp/B0FRGM33T4 Author Book App: https://talk-to-the-book.lovable.app Medium.com @.*** Get a beehiiv subscription for your own organization https://www.beehiiv.com?via=fkx <https://www.beehiiv.com/?via=fkx> […](#)

Good point but i dont have several PC around here and there is no IOS App.

fkx2016 · 3 months ago

Not to be obnoxious but how many wasted hours would it take to justify
approx $100 to pick up another used pc on facebook mktg or ebay?

I’m in Boston and there are hundreds of every make, feature set and os

Frank Kurka inferencedevices.com
Serving the Personal AI Community
(617) 910-0092 (voicemail)

@.*** (857) 231-1046 (mobile)
44 Mechanic Street, Suite 213, Newton Upper Falls, MA 02464

Newsletter:
See the past newsletters and sign up free: https://fkxx.substack.com

Socials
X: @fkurka
LinkedIn: https://www.linkedin.com/in/fkxai/

My first book:
What is Artificial Intelligence
https://www.amazon.com/dp/B0FRGM33T4

Author Book App:
https://talk-to-the-book.lovable.app

Medium.com
@.***

Get a beehiiv subscription for your own organization
https://www.beehiiv.com?via=fkx <https://www.beehiiv.com/?via=fkx>

On Sat, Apr 4, 2026 at 10:25 AM verkaufsoptimierung <
@.***> wrote:

verkaufsoptimierung left a comment (anthropics/claude-code#29941) <https://github.com/anthropics/claude-code/issues/29941#issuecomment-4187192009> I gave up on the stubborn pc and just use one where it works 🤷‍♂️ Frank Kurka inferencedevices.com Serving the Personal AI Community (617) 910-0092 (voicemail) @.*** (857) 231-1046 (mobile) 44 Mechanic Street, Suite 213, Newton Upper Falls, MA 02464 <https://www.google.com/maps/search/44+Mechanic+Street,+Suite+213,+Newton+Upper+Falls,+MA++02464?entry=gmail&source=g> Newsletter: See the past newsletters and sign up free: https://fkxx.substack.com Socials X: @fkurka LinkedIn: https://www.linkedin.com/in/fkxai/ My first book: What is Artificial Intelligence https://www.amazon.com/dp/B0FRGM33T4 Author Book App: https://talk-to-the-book.lovable.app Medium.com @.*** Get a beehiiv subscription for your own organization https://www.beehiiv.com?via=fkx https://www.beehiiv.com/?via=fkx … <#m_-7253007161333767584_> Good point but i dont have several PC around here and there is no IOS App. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/29941#issuecomment-4187192009>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD7SVYUUROB5L4ZGRE7OMWL4UELODAVCNFSM6AAAAACWDUUOISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCOBXGE4TEMBQHE> . You are receiving this because you commented.Message ID: @.***>
LozadAPP · 3 months ago

I had this exact same error on Windows 11 Pro 25H2 (Build 26200). Same log, same behavior — service loads HCS DLLs fine but crashes on signature verification.

What I checked first (wasn't the problem):

  • ✅ Hyper-V enabled
  • ✅ WSL2 installed with Ubuntu as default
  • ✅ HypervisorPlatform enabled
  • ✅ Developer Mode on
  • ✅ AllowAllTrustedApps = 1 in registry
  • ✅ Executable exists and signature is valid

What actually fixed the signature error:

  • Updated Windows to the latest cumulative patch (KB5086672, build 26200.8117)
  • Activated my Windows license (mine wasn't activated before)

After doing both, the service log changed from the error to:

[Server] Signature verification initialized [Server] Client signature verified Service ready. Listening on \\.\pipe\cowork-vm-service

No need to copy cowork-svc.exe outside WindowsApps — the service just worked after updating and activating.

⚠️ I can't say for sure if it was the update, the activation, or both. But after doing both, the error was gone.

---

Important: After fixing this, I hit a second error: EXDEV: cross-device link not permitted at ~80% of workspace setup. This was a completely different problem.

The cause: In Settings > System > Storage > Advanced storage settings > Where new content is saved, my apps were set to save on D:\ instead of C:\. This made Windows create symlinks inside the MSIX package folder pointing to D:\, and when Claude tried to rename the downloaded VM file, it failed because you can't rename across drives.

How to check if you have this:

Get-ChildItem "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc" | Format-Table Name, Attributes, Target

If you see symlinks pointing to D:\WpSystem\ → change your app storage to C:\, uninstall Claude, clean up everything, and reinstall:

Remove-Item "$env:APPDATA\Claude" -Recurse -Force
Remove-Item "$env:LOCALAPPDATA\Claude" -Recurse -Force
Remove-Item "C:\ProgramData\Claude" -Recurse -Force
Remove-Item "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Force
Remove-Item "D:\WpSystem\*\AppData\Local\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Force

After reinstalling with storage set to C:\, Cowork installed successfully. 🎉

| Error | What fixed it |
|-------|--------------|
| signature verification failed | Update Windows (latest KB) + Activate Windows |
| EXDEV: cross-device link | Change app storage location to C:\ + clean reinstall |

---
📌 Full diagnostic tool and step-by-step guide: https://github.com/LozadAPP/claude-cowork-windows-fix

csch1701 · 3 months ago

I installed Claude Version 1.1062.0 (b81bcd) on my Windows 11 host machine today — the Cowork issue is fixed. Everything is working now.

For context: this is the same host machine where Cowork was previously failing to load the environment entirely. That problem is now gone. I made no other changes to my machine.

For anyone experiencing similar issues, I'd recommend updating to this latest version of Claude — it may resolve your problem as well.

csch1701 · 3 months ago

....and, incidentally, the comment above was created my claude cowork under my direction and posted by claude cowork with my permission. I'm a little giddy now.

verkaufsoptimierung · 2 months ago

Fixed for me.

github-actions[bot] · 1 month ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.