Cowork: "VM service not running" persists after reinstall + restart, reproduces server-side simultaneously

Status Closed — duplicate
Maintainer reply None cached
Activity 1 comment · opened Jul 30, 2026 · closed Aug 25, 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?

Cowork fails to start with "Failed to start Claude's workspace. VM service not running. The service failed to start." This began mid-session and has persisted across: restarting the Claude Desktop app, restarting the computer entirely, and using the in-app "reinstall the workspace" option — identical error after each.

Notably, during the same window, an active Cowork chat session's own backend sandbox tool independently failed with the identical error message, suggesting this may not be purely a local machine/virtualization config issue.

What Should Happen?

Cowork's workspace/VM should start normally, allowing the sandboxed environment to be used for file and shell operations.

Error Messages/Logs

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.

Steps to Reproduce

  1. Open Cowork mode in Claude Desktop on Windows.
  2. Trigger any action requiring the sandbox (e.g. ask Claude to run a shell command or read/write files).
  3. Error appears: "Failed to start Claude's workspace / VM service not running."
  4. Restart Claude Desktop — error persists.
  5. Restart the computer — error persists.
  6. Use in-app "reinstall the workspace" — error persists identically.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

N/A — using Cowork desktop app

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Also investigated whether a locally-installed third-party MCP tool (an unrelated local Python-based bridge server for cross-agent context sharing between Codex and Claude) could be responsible. Reviewed its source directly — file I/O only, no networking/subprocess calls, nothing touching VM bundles or Hyper-V. Ruled out as a cause.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗