Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Bug Report: Cowork workspace fails with cryptic "VM service not running" error; root cause is stale SDK cache + Manual-startup service

Summary

Claude Desktop's Cowork workspace repeatedly failed with the error Failed to start Claude's workspace — VM service not running. The service failed to start. The in-app "reinstall workspace" flow also failed. After several hours of debugging, the root cause turned out to be a combination of the CoworkVMService being set to Manual startup (so it wasn't running when the app tried to talk to it) and a stale cached Claude Code SDK inside the VM that caused /usr/local/bin/claude to exit with code 1 immediately on startup — with no captured stderr, which made diagnosis extremely difficult.

The user-facing error message is deeply misleading: it reports "VM service not running" when in fact the VM starts successfully, networks successfully, reaches the API, and mounts all virtiofs shares. The real failure is that Claude Code itself crashes inside the VM after all of that succeeds.

Environment

• OS: Windows 11 (Pro edition with Hyper-V)
• Claude Desktop: v1.3036.0.0 (previously v1.2773.0.0 — app updated during troubleshooting)
• Bundle version: 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d
• Claude Code SDK in VM: v2.1.111
• Hyper-V: enabled during troubleshooting (was not enabled by default)
• Domain-joined machine
• AV: Windows Defender + Symantec Endpoint Protection (ruled out as cause)

Reproduction path (what I actually hit)

1. Clean Windows 11 Pro machine, Hyper-V not enabled by default
2. Launched Claude Desktop, tried to open workspace
3. Got "VM service not running" error
4. Restarted machine — same error
5. Tried in-app "Reinstall workspace" — also failed with same error
6. Had to manually enable Hyper-V via PowerShell (Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All -All)
7. After Hyper-V enabled, VM would sometimes start but the app still reported "VM service not running" because CoworkVMService was installed with StartupType: Manual and wasn't running when the app queried it
8. Even after manually starting the service, opening workspace showed "Claude Code process exited with code 1"

What the logs showed

Three separate logs had to be correlated to make sense of the failure:

%APPDATA%\Claude\logs\cowork_vm_node.log

Reports VM service not running and gives up. This is the only log the user sees referenced. It contains no information about why the service isn't responding — the app just times out waiting for it.

C:\ProgramData\Claude\Logs\cowork-service.log

Shows the service actually starts cleanly, VM boots, network connects, API reachability = REACHABLE. So when the app reports "VM service not running", the service is actually running fine. The app and service are out of sync.

Also logs this repeatable shutdown error on every clean app exit:

[VM] Graceful shutdown failed, forcing termination:
HcsShutdownComputeSystem failed with HRESULT 0x0/0x8037010d:
{"Error":-1070137075,"ErrorMessage":"The virtual machine or container JSON
document is invalid.", ... "Invalid JSON document '$'"}

This force-termination recovers, but leaves junk state behind and pollutes local-agent-mode-sessions with orphaned directories across sessions.

C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log

This is the log that told us the real story. All virtiofs mounts succeed. Then:

[coworkd] SDK binary v2.1.111 already installed, skipping
[process:<uuid>] started PID <N>
[process:<uuid>] direct child exited: code=1 signal=<nil>

/usr/local/bin/claude exits in under 1 second with code 1 and no signal. No stderr is captured anywhere. This was the hardest part of debugging — there's literally no way to see why Claude Code failed because its stdout and stderr aren't being logged.

What actually fixed it

# Kill everything
Get-Process | Where-Object { $_.Name -like "*claude*" -or $_.Name -like "*cowork*" } | Stop-Process -Force
Stop-Service CoworkVMService -Force

# Wipe session VHDX
Remove-Item -Force "$env:APPDATA\Claude\vm_bundles\claudevm.bundle\sessiondata.vhdx"

# Wipe the cached Claude Code SDK inside the VM — this was the fix
Remove-Item -Recurse -Force "$env:APPDATA\Claude\claude-code-vm"

# (Tried to wipe local-agent-mode-sessions too but hit Windows MAX_PATH
# errors — see "secondary bugs" below)

# Lock service to auto-start
Set-Service CoworkVMService -StartupType Automatic
Start-Service CoworkVMService

Then launch Claude, wait 60+ seconds for fresh SDK install, start a new conversation. Workspace finally worked.

Suggested fixes (ordered by impact)

1. Capture stderr from /usr/local/bin/claude in coworkd

This is the single highest-leverage fix. A child process that exits with code 1 and has no captured output is essentially undebuggable from logs. At minimum, pipe stderr of the spawned claude binary to the coworkd log (or a sidecar file).

2. Fix the misleading top-level error message

"VM service not running" is displayed even when the VM is running and the failure is downstream (Claude Code crashing inside the VM). This sends everyone down the wrong path (Hyper-V, services, antivirus) before they realize the VM side is fine. The error should distinguish between:

• VM service unreachable
• VM didn't boot
• VM booted but API not reachable
• Claude Code child process failed to start

3. Set CoworkVMService StartupType to Automatic on install

Installing it as Manual means it doesn't start on boot, but the app expects it to be running. If there's a reason it's Manual (delayed start to not slow boot), consider "Automatic (Delayed Start)" instead.

4. Invalidate SDK cache on app version change

The log line SDK binary v2.1.111 already installed, skipping runs on every session regardless of whether the host app has been updated. If the host app version changes, the in-VM SDK cache should be invalidated and re-downloaded. Right now the only way to force this is manually deleting %APPDATA%\Claude\claude-code-vm.

5. Fix the "Invalid JSON document '$'" shutdown error

HcsShutdownComputeSystem is being called with invalid JSON on every graceful shutdown. It recovers via force-termination, but this is producing orphaned state that accumulates across sessions. Whatever is serializing the shutdown request is producing $ instead of a valid JSON document.

Secondary bugs found along the way

• MAX_PATH violation in local-agent-mode-sessions: The nested session directory structure generates paths over 260 chars, which breaks Remove-Item in PowerShell and likely breaks File Explorer too. Users cannot clean this up without using robocopy /MIR tricks. Consider flatter path structure or enabling long paths in the app.

• Warning: failed to open service for recovery config: Access is denied logged on every service startup. The service is trying to configure its own recovery settings and being denied. Minor but noisy.

• Duplicate startup attempts: Logs repeatedly show two VM startups within one second of each other with the same instance ID, causing "VM startup already in progress, waiting..." — suggests a race condition when the app launches.

Attached logs

Please attach all three:

• %APPDATA%\Claude\logs\cowork_vm_node.log
• C:\ProgramData\Claude\Logs\cowork-service.log
• C:\ProgramData\Claude\Logs\coworkd\user-<your-SID>.log

Time spent debugging

Several hours across enabling Hyper-V, exploring SEP exceptions, multiple workspace reinstalls, and three separate log analyses before landing on the SDK cache wipe. A better error message in item #2 above would have saved probably 80% of this time.

What Should Happen?

Bug Report: Cowork workspace fails with cryptic "VM service not running" error; root cause is stale SDK cache + Manual-startup service

Summary

Claude Desktop's Cowork workspace repeatedly failed with the error Failed to start Claude's workspace — VM service not running. The service failed to start. The in-app "reinstall workspace" flow also failed. After several hours of debugging, the root cause turned out to be a combination of the CoworkVMService being set to Manual startup (so it wasn't running when the app tried to talk to it) and a stale cached Claude Code SDK inside the VM that caused /usr/local/bin/claude to exit with code 1 immediately on startup — with no captured stderr, which made diagnosis extremely difficult.

The user-facing error message is deeply misleading: it reports "VM service not running" when in fact the VM starts successfully, networks successfully, reaches the API, and mounts all virtiofs shares. The real failure is that Claude Code itself crashes inside the VM after all of that succeeds.

Environment

• OS: Windows 11 (Pro edition with Hyper-V)
• Claude Desktop: v1.3036.0.0 (previously v1.2773.0.0 — app updated during troubleshooting)
• Bundle version: 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d
• Claude Code SDK in VM: v2.1.111
• Hyper-V: enabled during troubleshooting (was not enabled by default)
• Domain-joined machine
• AV: Windows Defender + Symantec Endpoint Protection (ruled out as cause)

Reproduction path (what I actually hit)

1. Clean Windows 11 Pro machine, Hyper-V not enabled by default
2. Launched Claude Desktop, tried to open workspace
3. Got "VM service not running" error
4. Restarted machine — same error
5. Tried in-app "Reinstall workspace" — also failed with same error
6. Had to manually enable Hyper-V via PowerShell (Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All -All)
7. After Hyper-V enabled, VM would sometimes start but the app still reported "VM service not running" because CoworkVMService was installed with StartupType: Manual and wasn't running when the app queried it
8. Even after manually starting the service, opening workspace showed "Claude Code process exited with code 1"

What the logs showed

Three separate logs had to be correlated to make sense of the failure:

%APPDATA%\Claude\logs\cowork_vm_node.log

Reports VM service not running and gives up. This is the only log the user sees referenced. It contains no information about why the service isn't responding — the app just times out waiting for it.

C:\ProgramData\Claude\Logs\cowork-service.log

Shows the service actually starts cleanly, VM boots, network connects, API reachability = REACHABLE. So when the app reports "VM service not running", the service is actually running fine. The app and service are out of sync.

Also logs this repeatable shutdown error on every clean app exit:

[VM] Graceful shutdown failed, forcing termination:
HcsShutdownComputeSystem failed with HRESULT 0x0/0x8037010d:
{"Error":-1070137075,"ErrorMessage":"The virtual machine or container JSON
document is invalid.", ... "Invalid JSON document '$'"}

This force-termination recovers, but leaves junk state behind and pollutes local-agent-mode-sessions with orphaned directories across sessions.

C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log

This is the log that told us the real story. All virtiofs mounts succeed. Then:

[coworkd] SDK binary v2.1.111 already installed, skipping
[process:<uuid>] started PID <N>
[process:<uuid>] direct child exited: code=1 signal=<nil>

/usr/local/bin/claude exits in under 1 second with code 1 and no signal. No stderr is captured anywhere. This was the hardest part of debugging — there's literally no way to see why Claude Code failed because its stdout and stderr aren't being logged.

What actually fixed it

# Kill everything
Get-Process | Where-Object { $_.Name -like "*claude*" -or $_.Name -like "*cowork*" } | Stop-Process -Force
Stop-Service CoworkVMService -Force

# Wipe session VHDX
Remove-Item -Force "$env:APPDATA\Claude\vm_bundles\claudevm.bundle\sessiondata.vhdx"

# Wipe the cached Claude Code SDK inside the VM — this was the fix
Remove-Item -Recurse -Force "$env:APPDATA\Claude\claude-code-vm"

# (Tried to wipe local-agent-mode-sessions too but hit Windows MAX_PATH
# errors — see "secondary bugs" below)

# Lock service to auto-start
Set-Service CoworkVMService -StartupType Automatic
Start-Service CoworkVMService

Then launch Claude, wait 60+ seconds for fresh SDK install, start a new conversation. Workspace finally worked.

Suggested fixes (ordered by impact)

1. Capture stderr from /usr/local/bin/claude in coworkd

This is the single highest-leverage fix. A child process that exits with code 1 and has no captured output is essentially undebuggable from logs. At minimum, pipe stderr of the spawned claude binary to the coworkd log (or a sidecar file).

2. Fix the misleading top-level error message

"VM service not running" is displayed even when the VM is running and the failure is downstream (Claude Code crashing inside the VM). This sends everyone down the wrong path (Hyper-V, services, antivirus) before they realize the VM side is fine. The error should distinguish between:

• VM service unreachable
• VM didn't boot
• VM booted but API not reachable
• Claude Code child process failed to start

3. Set CoworkVMService StartupType to Automatic on install

Installing it as Manual means it doesn't start on boot, but the app expects it to be running. If there's a reason it's Manual (delayed start to not slow boot), consider "Automatic (Delayed Start)" instead.

4. Invalidate SDK cache on app version change

The log line SDK binary v2.1.111 already installed, skipping runs on every session regardless of whether the host app has been updated. If the host app version changes, the in-VM SDK cache should be invalidated and re-downloaded. Right now the only way to force this is manually deleting %APPDATA%\Claude\claude-code-vm.

5. Fix the "Invalid JSON document '$'" shutdown error

HcsShutdownComputeSystem is being called with invalid JSON on every graceful shutdown. It recovers via force-termination, but this is producing orphaned state that accumulates across sessions. Whatever is serializing the shutdown request is producing $ instead of a valid JSON document.

Secondary bugs found along the way

• MAX_PATH violation in local-agent-mode-sessions: The nested session directory structure generates paths over 260 chars, which breaks Remove-Item in PowerShell and likely breaks File Explorer too. Users cannot clean this up without using robocopy /MIR tricks. Consider flatter path structure or enabling long paths in the app.

• Warning: failed to open service for recovery config: Access is denied logged on every service startup. The service is trying to configure its own recovery settings and being denied. Minor but noisy.

• Duplicate startup attempts: Logs repeatedly show two VM startups within one second of each other with the same instance ID, causing "VM startup already in progress, waiting..." — suggests a race condition when the app launches.

Attached logs

Please attach all three:

• %APPDATA%\Claude\logs\cowork_vm_node.log
• C:\ProgramData\Claude\Logs\cowork-service.log
• C:\ProgramData\Claude\Logs\coworkd\user-<your-SID>.log

Time spent debugging

Several hours across enabling Hyper-V, exploring SEP exceptions, multiple workspace reinstalls, and three separate log analyses before landing on the SDK cache wipe. A better error message in item #2 above would have saved probably 80% of this time.

Error Messages/Logs

Steps to Reproduce

Bug Report: Cowork workspace fails with cryptic "VM service not running" error; root cause is stale SDK cache + Manual-startup service

Summary

Claude Desktop's Cowork workspace repeatedly failed with the error Failed to start Claude's workspace — VM service not running. The service failed to start. The in-app "reinstall workspace" flow also failed. After several hours of debugging, the root cause turned out to be a combination of the CoworkVMService being set to Manual startup (so it wasn't running when the app tried to talk to it) and a stale cached Claude Code SDK inside the VM that caused /usr/local/bin/claude to exit with code 1 immediately on startup — with no captured stderr, which made diagnosis extremely difficult.

The user-facing error message is deeply misleading: it reports "VM service not running" when in fact the VM starts successfully, networks successfully, reaches the API, and mounts all virtiofs shares. The real failure is that Claude Code itself crashes inside the VM after all of that succeeds.

Environment

• OS: Windows 11 (Pro edition with Hyper-V)
• Claude Desktop: v1.3036.0.0 (previously v1.2773.0.0 — app updated during troubleshooting)
• Bundle version: 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d
• Claude Code SDK in VM: v2.1.111
• Hyper-V: enabled during troubleshooting (was not enabled by default)
• Domain-joined machine
• AV: Windows Defender + Symantec Endpoint Protection (ruled out as cause)

Reproduction path (what I actually hit)

1. Clean Windows 11 Pro machine, Hyper-V not enabled by default
2. Launched Claude Desktop, tried to open workspace
3. Got "VM service not running" error
4. Restarted machine — same error
5. Tried in-app "Reinstall workspace" — also failed with same error
6. Had to manually enable Hyper-V via PowerShell (Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All -All)
7. After Hyper-V enabled, VM would sometimes start but the app still reported "VM service not running" because CoworkVMService was installed with StartupType: Manual and wasn't running when the app queried it
8. Even after manually starting the service, opening workspace showed "Claude Code process exited with code 1"

What the logs showed

Three separate logs had to be correlated to make sense of the failure:

%APPDATA%\Claude\logs\cowork_vm_node.log

Reports VM service not running and gives up. This is the only log the user sees referenced. It contains no information about why the service isn't responding — the app just times out waiting for it.

C:\ProgramData\Claude\Logs\cowork-service.log

Shows the service actually starts cleanly, VM boots, network connects, API reachability = REACHABLE. So when the app reports "VM service not running", the service is actually running fine. The app and service are out of sync.

Also logs this repeatable shutdown error on every clean app exit:

[VM] Graceful shutdown failed, forcing termination:
HcsShutdownComputeSystem failed with HRESULT 0x0/0x8037010d:
{"Error":-1070137075,"ErrorMessage":"The virtual machine or container JSON
document is invalid.", ... "Invalid JSON document '$'"}

This force-termination recovers, but leaves junk state behind and pollutes local-agent-mode-sessions with orphaned directories across sessions.

C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log

This is the log that told us the real story. All virtiofs mounts succeed. Then:

[coworkd] SDK binary v2.1.111 already installed, skipping
[process:<uuid>] started PID <N>
[process:<uuid>] direct child exited: code=1 signal=<nil>

/usr/local/bin/claude exits in under 1 second with code 1 and no signal. No stderr is captured anywhere. This was the hardest part of debugging — there's literally no way to see why Claude Code failed because its stdout and stderr aren't being logged.

What actually fixed it

# Kill everything
Get-Process | Where-Object { $_.Name -like "*claude*" -or $_.Name -like "*cowork*" } | Stop-Process -Force
Stop-Service CoworkVMService -Force

# Wipe session VHDX
Remove-Item -Force "$env:APPDATA\Claude\vm_bundles\claudevm.bundle\sessiondata.vhdx"

# Wipe the cached Claude Code SDK inside the VM — this was the fix
Remove-Item -Recurse -Force "$env:APPDATA\Claude\claude-code-vm"

# (Tried to wipe local-agent-mode-sessions too but hit Windows MAX_PATH
# errors — see "secondary bugs" below)

# Lock service to auto-start
Set-Service CoworkVMService -StartupType Automatic
Start-Service CoworkVMService

Then launch Claude, wait 60+ seconds for fresh SDK install, start a new conversation. Workspace finally worked.

Suggested fixes (ordered by impact)

1. Capture stderr from /usr/local/bin/claude in coworkd

This is the single highest-leverage fix. A child process that exits with code 1 and has no captured output is essentially undebuggable from logs. At minimum, pipe stderr of the spawned claude binary to the coworkd log (or a sidecar file).

2. Fix the misleading top-level error message

"VM service not running" is displayed even when the VM is running and the failure is downstream (Claude Code crashing inside the VM). This sends everyone down the wrong path (Hyper-V, services, antivirus) before they realize the VM side is fine. The error should distinguish between:

• VM service unreachable
• VM didn't boot
• VM booted but API not reachable
• Claude Code child process failed to start

3. Set CoworkVMService StartupType to Automatic on install

Installing it as Manual means it doesn't start on boot, but the app expects it to be running. If there's a reason it's Manual (delayed start to not slow boot), consider "Automatic (Delayed Start)" instead.

4. Invalidate SDK cache on app version change

The log line SDK binary v2.1.111 already installed, skipping runs on every session regardless of whether the host app has been updated. If the host app version changes, the in-VM SDK cache should be invalidated and re-downloaded. Right now the only way to force this is manually deleting %APPDATA%\Claude\claude-code-vm.

5. Fix the "Invalid JSON document '$'" shutdown error

HcsShutdownComputeSystem is being called with invalid JSON on every graceful shutdown. It recovers via force-termination, but this is producing orphaned state that accumulates across sessions. Whatever is serializing the shutdown request is producing $ instead of a valid JSON document.

Secondary bugs found along the way

• MAX_PATH violation in local-agent-mode-sessions: The nested session directory structure generates paths over 260 chars, which breaks Remove-Item in PowerShell and likely breaks File Explorer too. Users cannot clean this up without using robocopy /MIR tricks. Consider flatter path structure or enabling long paths in the app.

• Warning: failed to open service for recovery config: Access is denied logged on every service startup. The service is trying to configure its own recovery settings and being denied. Minor but noisy.

• Duplicate startup attempts: Logs repeatedly show two VM startups within one second of each other with the same instance ID, causing "VM startup already in progress, waiting..." — suggests a race condition when the app launches.

Attached logs

Please attach all three:

• %APPDATA%\Claude\logs\cowork_vm_node.log
• C:\ProgramData\Claude\Logs\cowork-service.log
• C:\ProgramData\Claude\Logs\coworkd\user-<your-SID>.log

Time spent debugging

Several hours across enabling Hyper-V, exploring SEP exceptions, multiple workspace reinstalls, and three separate log analyses before landing on the SDK cache wipe. A better error message in item #2 above would have saved probably 80% of this time.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

4.6

Claude Code Version

claude-opus-4-7[1m]

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Bug Report: Cowork workspace fails with cryptic "VM service not running" error; root cause is stale SDK cache + Manual-startup service

Summary

Claude Desktop's Cowork workspace repeatedly failed with the error Failed to start Claude's workspace — VM service not running. The service failed to start. The in-app "reinstall workspace" flow also failed. After several hours of debugging, the root cause turned out to be a combination of the CoworkVMService being set to Manual startup (so it wasn't running when the app tried to talk to it) and a stale cached Claude Code SDK inside the VM that caused /usr/local/bin/claude to exit with code 1 immediately on startup — with no captured stderr, which made diagnosis extremely difficult.

The user-facing error message is deeply misleading: it reports "VM service not running" when in fact the VM starts successfully, networks successfully, reaches the API, and mounts all virtiofs shares. The real failure is that Claude Code itself crashes inside the VM after all of that succeeds.

Environment

• OS: Windows 11 (Pro edition with Hyper-V)
• Claude Desktop: v1.3036.0.0 (previously v1.2773.0.0 — app updated during troubleshooting)
• Bundle version: 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d
• Claude Code SDK in VM: v2.1.111
• Hyper-V: enabled during troubleshooting (was not enabled by default)
• Domain-joined machine
• AV: Windows Defender + Symantec Endpoint Protection (ruled out as cause)

Reproduction path (what I actually hit)

1. Clean Windows 11 Pro machine, Hyper-V not enabled by default
2. Launched Claude Desktop, tried to open workspace
3. Got "VM service not running" error
4. Restarted machine — same error
5. Tried in-app "Reinstall workspace" — also failed with same error
6. Had to manually enable Hyper-V via PowerShell (Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All -All)
7. After Hyper-V enabled, VM would sometimes start but the app still reported "VM service not running" because CoworkVMService was installed with StartupType: Manual and wasn't running when the app queried it
8. Even after manually starting the service, opening workspace showed "Claude Code process exited with code 1"

What the logs showed

Three separate logs had to be correlated to make sense of the failure:

%APPDATA%\Claude\logs\cowork_vm_node.log

Reports VM service not running and gives up. This is the only log the user sees referenced. It contains no information about why the service isn't responding — the app just times out waiting for it.

C:\ProgramData\Claude\Logs\cowork-service.log

Shows the service actually starts cleanly, VM boots, network connects, API reachability = REACHABLE. So when the app reports "VM service not running", the service is actually running fine. The app and service are out of sync.

Also logs this repeatable shutdown error on every clean app exit:

[VM] Graceful shutdown failed, forcing termination:
HcsShutdownComputeSystem failed with HRESULT 0x0/0x8037010d:
{"Error":-1070137075,"ErrorMessage":"The virtual machine or container JSON
document is invalid.", ... "Invalid JSON document '$'"}

This force-termination recovers, but leaves junk state behind and pollutes local-agent-mode-sessions with orphaned directories across sessions.

C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log

This is the log that told us the real story. All virtiofs mounts succeed. Then:

[coworkd] SDK binary v2.1.111 already installed, skipping
[process:<uuid>] started PID <N>
[process:<uuid>] direct child exited: code=1 signal=<nil>

/usr/local/bin/claude exits in under 1 second with code 1 and no signal. No stderr is captured anywhere. This was the hardest part of debugging — there's literally no way to see why Claude Code failed because its stdout and stderr aren't being logged.

What actually fixed it

# Kill everything
Get-Process | Where-Object { $_.Name -like "*claude*" -or $_.Name -like "*cowork*" } | Stop-Process -Force
Stop-Service CoworkVMService -Force

# Wipe session VHDX
Remove-Item -Force "$env:APPDATA\Claude\vm_bundles\claudevm.bundle\sessiondata.vhdx"

# Wipe the cached Claude Code SDK inside the VM — this was the fix
Remove-Item -Recurse -Force "$env:APPDATA\Claude\claude-code-vm"

# (Tried to wipe local-agent-mode-sessions too but hit Windows MAX_PATH
# errors — see "secondary bugs" below)

# Lock service to auto-start
Set-Service CoworkVMService -StartupType Automatic
Start-Service CoworkVMService

Then launch Claude, wait 60+ seconds for fresh SDK install, start a new conversation. Workspace finally worked.

Suggested fixes (ordered by impact)

1. Capture stderr from /usr/local/bin/claude in coworkd

This is the single highest-leverage fix. A child process that exits with code 1 and has no captured output is essentially undebuggable from logs. At minimum, pipe stderr of the spawned claude binary to the coworkd log (or a sidecar file).

2. Fix the misleading top-level error message

"VM service not running" is displayed even when the VM is running and the failure is downstream (Claude Code crashing inside the VM). This sends everyone down the wrong path (Hyper-V, services, antivirus) before they realize the VM side is fine. The error should distinguish between:

• VM service unreachable
• VM didn't boot
• VM booted but API not reachable
• Claude Code child process failed to start

3. Set CoworkVMService StartupType to Automatic on install

Installing it as Manual means it doesn't start on boot, but the app expects it to be running. If there's a reason it's Manual (delayed start to not slow boot), consider "Automatic (Delayed Start)" instead.

4. Invalidate SDK cache on app version change

The log line SDK binary v2.1.111 already installed, skipping runs on every session regardless of whether the host app has been updated. If the host app version changes, the in-VM SDK cache should be invalidated and re-downloaded. Right now the only way to force this is manually deleting %APPDATA%\Claude\claude-code-vm.

5. Fix the "Invalid JSON document '$'" shutdown error

HcsShutdownComputeSystem is being called with invalid JSON on every graceful shutdown. It recovers via force-termination, but this is producing orphaned state that accumulates across sessions. Whatever is serializing the shutdown request is producing $ instead of a valid JSON document.

Secondary bugs found along the way

• MAX_PATH violation in local-agent-mode-sessions: The nested session directory structure generates paths over 260 chars, which breaks Remove-Item in PowerShell and likely breaks File Explorer too. Users cannot clean this up without using robocopy /MIR tricks. Consider flatter path structure or enabling long paths in the app.

• Warning: failed to open service for recovery config: Access is denied logged on every service startup. The service is trying to configure its own recovery settings and being denied. Minor but noisy.

• Duplicate startup attempts: Logs repeatedly show two VM startups within one second of each other with the same instance ID, causing "VM startup already in progress, waiting..." — suggests a race condition when the app launches.

Attached logs

Please attach all three:

• %APPDATA%\Claude\logs\cowork_vm_node.log
• C:\ProgramData\Claude\Logs\cowork-service.log
• C:\ProgramData\Claude\Logs\coworkd\user-<your-SID>.log

Time spent debugging

Several hours across enabling Hyper-V, exploring SEP exceptions, multiple workspace reinstalls, and three separate log analyses before landing on the SDK cache wipe. A better error message in item #2 above would have saved probably 80% of this time.