›_ Claude Code Issues
Claude Code Issues / #49495

[BUG] Cowork workspace fails with cryptic "VM service not running" error; root cause is stale SDK cache + Manual-startup service

Resolved 💬 3 comments Opened Apr 16, 2026 by MRD-INT Closed Apr 20, 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?

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)

  1. 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

  1. 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)

  1. 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

  1. 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)

  1. 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

  1. 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)

  1. 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

  1. 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.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗