Cowork fails to start workspace on Windows 11 Pro — “Request timed out: configure”

[dwalmsley]

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?

Title
Cowork fails to start workspace on Windows 11 Pro — “Request timed out: configure”

What’s wrong?
On Windows 11 Pro, Cowork consistently fails to start the workspace.
The Cowork tab shows a startup spinner and then the error:

Failed to start Claude's workspace: Request timed out: configure

Regular Chat mode works; only Cowork is affected.

My environment

OS: Windows 11 Pro (from PowerShell: (Get-WmiObject -Class Win32_OperatingSystem).Caption)

Virtualization: Enabled in BIOS (Intel VT‑x / AMD SVM)

Windows features (all Enabled):

Microsoft-Hyper-V-All

VirtualMachinePlatform

Microsoft-Windows-Subsystem-Linux

WSL:

Default distribution: Ubuntu

Default version: 2 (wsl --status)

Claude Desktop: [put your version from the app’s About dialog]

CoworkVMService:

StartType: Automatic

Status: Running (after Start-Service -Name CoworkVMService)

Steps to reproduce

Launch Claude Desktop on Windows 11 Pro.

Wait for the app to fully load.

Switch to the Cowork tab.

Start any workspace/task.

Wait for “Configuring” / similar state.

After ~60 seconds, observe:
Failed to start Claude's workspace: Request timed out: configure

What I’ve already tried (unsuccessful)

Fully quit Claude, rebooted Windows.

Manually started the VM service:

Start-Service -Name CoworkVMService → service status is Running.

Verified Windows virtualization stack:

Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All → State: Enabled

Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform → State: Enabled

Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux → State: Enabled

wsl --status → Default distro Ubuntu, version 2.

Reset Cowork VM state (deleted claude-code-vm / vm_bundles under %APPDATA%\Claude, then rebooted).

Clean reinstall of Claude Desktop (uninstalled, deleted %APPDATA%\Claude and %LOCALAPPDATA%\Claude, rebooted, reinstalled).

Despite all of this, Cowork still fails with the same “request timed out: configure” message, even though CoworkVMService is running and Windows virtualization/WSL2 are fully enabled.

Relevant log excerpt
(from PowerShell:)

powershell
Get-Content "$env:APPDATA\Claude\logs\cowork_vm_node.log" -Tail 200 |
Select-String -Pattern 'error','failed','timeout','timed out','exception','VM','workspace','configure' -SimpleMatch

Get-Content : Cannot find path 'C:\Users\david\AppData\Roaming\Claude\logs\cowork_vm_node.log' because it does not
exist.
At line:1 char:1

• Get-Content "$env:APPDATA\Claude\logs\cowork_vm_node.log" -Tail 200 |

•   + CategoryInfo          : ObjectNotFound: (C:\Users\david\...ork_vm_node.log:String) [Get-Content], ItemNotFoundEx
   ception
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetContentCommand
  
  

Why I think this is a bug

Other GitHub issues show similar patterns where the VM service and Windows virtualization stack are healthy, but Cowork still times out connecting/initializing the workspace on Windows 11.
github
+2

In my case, all required Windows features (Hyper‑V, VirtualMachinePlatform, WSL) are enabled and CoworkVMService is running, so it appears to be a Cowork‑side VM connection or initialization bug rather than a missing prerequisite.

If you need more logs (Event Viewer entries, full cowork_vm_node.log, or Desktop app logs), I can provide them.

What Should Happen?

When I open the Cowork tab and start a workspace, Claude should successfully start the Cowork VM, connect to it, and show a ready workspace within a few seconds instead of timing out.

I should see a usable Cowork environment (file tree/terminal/editor, depending on the task) with no error messages about “Failed to start Claude’s workspace” or “Request timed out: configure,” and I should be able to run tasks and interact with the workspace normally.

Error Messages/Logs

Get-Content : Cannot find path 'C:\Users\david\AppData\Roaming\Claude\logs\cowork_vm_node.log' because it does not
exist.
At line:1 char:1
+ Get-Content "$env:APPDATA\Claude\logs\cowork_vm_node.log" -Tail 200 |
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (C:\Users\david\...ork_vm_node.log:String) [Get-Content], ItemNotFoundEx
   ception
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetContentCommand

Steps to Reproduce

Launch Claude Desktop on Windows 11 Pro.

Sign in (if prompted) and wait for the main chat screen to load.

Click on the Cowork tab.

Create a new workspace or start any Cowork task.

Wait while it shows “Starting/Configuring workspace” (or similar).

After about 30–60 seconds, observe that the workspace fails to start and shows the error:
Failed to start Claude's workspace: Request timed out: configure.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

Version 1.3109.0 (35cbf6)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

No response

[github-actions]

Found 3 possible duplicate issues:

1. Cowork fails on ARM64 (Snapdragon X) despite passing readiness check #50674
2. Cowork VM service fails to start on Windows 11 Pro after Claude Desktop update #49435
3. [Bug] Cowork returns exit code 127 with "CoworkVM service not running" after update #49474

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

[0xbrainkid]

This is another infrastructure-layer Cowork failure where the top-level symptom ("Request timed out: configure") is too generic to support real recovery.

The useful detail here is that regular Chat works and Cowork alone fails. That narrows the problem to the workspace/VM/environment configuration path rather than general app auth or basic connectivity.

From the user perspective, though, the current error gives no help about which configuration phase timed out:

• VM startup
• workspace mount/setup
• service handshake
• capability check
• networked provisioning step

That is why these Cowork timeout issues feel so sticky. Users can often confirm the obvious prerequisites (Windows edition, virtualization enabled, etc.), but the product still hides the actual failing step behind a single "configure" timeout.

If Cowork is going to depend on a complex startup chain, the app needs to expose that chain more transparently so users can see where it broke instead of treating every timeout as the same blob.

[daviddalao]

I'm experiencing the same issue on Windows 11 Pro (build 26200, x64).

The Cowork readiness check passes with all green:

• Windows version: Windows 11 Pro (internal build 10.0.26200) ✅
• Architecture: x64 ✅
• Virtual Machine Platform: services present (vmcompute, HNS, vfpext) ✅
• Windows edition: Professional ✅
• Disk space: 189.4 GB free ✅
• Memory: 31.6 GB total ✅

Hyper-V is enabled (State: Enabled), CoworkVMService is not registered, and the logs folder at %APPDATA%\Claude\logs\ does not exist — meaning the VM never starts at all.

Cowork tab is visible and I can switch to it, but the workspace stays in "starting" state indefinitely. Regular Chat mode works fine.

What I've tried:

• Clean reinstall of Claude Desktop (deleted %APPDATA%\Claude and %LOCALAPPDATA%\Claude)
• Enabled Hyper-V via PowerShell (Enable-WindowsOptionalFeature)
• Verified CoworkVMService — not registered after fresh install
• Storage location confirmed as C:\ (not D:)

This appears to be the same VM initialization bug. Please advise or fix.

[LonelyRookie]

I've also encountered the same problem. How can I solve it？I've wasted too much of my time solving this problem

[Justingraph]

I ran into the same issue where Claude Desktop failed to start the Linux workspace with:

VHDX file not found: ...\rootfs.vhdx

In my case, the VM bundle was actually installed under:

%LOCALAPPDATA%\Claude-3p\vm_bundles\claudevm.bundle

but the app was trying to load it from:

%LOCALAPPDATA%\Packages\Claude_*\LocalCache\Roaming\Claude-3p\vm_bundles\claudevm.bundle

Copying the files works as a temporary fix, but the correct solution is to create NTFS hard links for the required files (rootfs.vhdx, vmlinuz, initrd, smol-bin.vhdx) into the expected Package path.

After creating hard links and restarting the CoworkVM service, the Linux workspace started normally.

It seems the issue is caused by a mismatch between the VM install path and the runtime lookup path.

[daviddalao]

Update on my situation — the VM bundle download is never triggered at all.

After further investigation:

What I found:

• %LOCALAPPDATA%\Claude-3p\vm_bundles\claudevm.bundle\ exists but contains only a single empty marker file: .auto_reinstall_attempted
• The vm_bundles folder under the Packages path (%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude-3p\vm_bundles\) is completely empty
• No logs are generated anywhere (%APPDATA%\Claude\logs\ does not exist, and ...\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ is empty)
• Network connectivity is confirmed fine (Test-NetConnection to storage.googleapis.com:443 succeeds)
• Monitored the vm_bundles folder for several minutes after launching Claude Desktop and switching to Cowork tab — no download was ever attempted

What I think is happening:
The .auto_reinstall_attempted marker file suggests Claude Desktop detected a corrupted/incomplete bundle, attempted an auto-reinstall once, failed silently, and then gave up permanently — never retrying the download.

This means there is no way for users to recover without a manual intervention.

Request:
Could you please provide a direct download link for the VM bundle (rootfs.vhdx, vmlinuz, initrd, smol-bin.vhdx) so users can place the files manually? Or add a "Re-download VM" button in the UI to force a fresh download?

Environment: Windows 11 Pro, build 26200, x64, all Cowork readiness checks pass.

[Justingraph]

In your case, that really looks like Claude Desktop detected an incomplete/corrupted VM bundle, attempted the reinstall/bootstrap once, failed silently, and then stopped retrying permanently.

I ran into a related Cowork VM issue myself, and from what I could tell there currently isn’t any official recovery flow exposed to users once the VM bootstrap gets stuck in this state. Regarding the request for a direct VM bundle download link: I personally don’t have one either, and I’m not even sure it would fully solve your specific case.

[github-actions]

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