[BUG] Claude workspace not starting

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 VM service fails to start after auto-update — Windows Home

Claude Desktop Version: 1.1.6679
OS: Windows 10/11 Home
Install method: Downloaded installer from claude.ai

---

Summary
Cowork worked fine prior to Claude auto-updating overnight (March 15–16, 2026). After the update, the VM service fails to start every time. The root cause identified in logs is a failed rename operation — the VM bundle downloads successfully to a Temp directory but fails to move to the destination because Claude is not creating the destination folder.

---

Key error from cowork_vm_node.log

[error] [download] VM download failed: ENOENT: no such file or directory, rename 'C:\Users\aksha\AppData\Local\Temp\wvm-9tTwRd\rootfs.vhdx' -> 'C:\Users\aksha\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'

---

Behaviour

• rootfs.vhdx downloads successfully and checksum validates
• Claude fails to rename/move the file from Temp to the bundle directory
• The bundle directory is not being created automatically by Claude
• Manually creating the directory does not resolve the issue
• Claude enters an infinite download loop, re-downloading rootfs.vhdx on every relaunch
• Error persists across full reboots, clean reinstalls, and VM bundle deletions

---

Troubleshooting already attempted

• Full reboot
• Clear cache via Help → Troubleshooting
• Manual deletion of vm_bundles directory
• Windows Defender exclusions (Defender not running — superseded by McAfee)
• McAfee real-time scanning disabled entirely — error persists, confirming AV is not the cause
• McAfee exclusions added for all VHDX and ZST file paths
• Manually created destination folder — rename still fails
• Full clean reinstall of Claude Desktop
• Enabled Windows Hypervisor Platform

---

Additional context
This appears related to the Cowork regression introduced around Claude Desktop v1.1.3189 (Feb 13–14, 2026) documented in GitHub issues #27801, #27010, and #25419. The ENOENT rename failure specifically suggests Claude is not reliably creating the vm_bundles directory on Windows Home after the update.

---

Expected behaviour
Cowork should create the vm_bundles/claudevm.bundle directory automatically and successfully move downloaded files into it, as it did prior to the update.

Logs attached via Help → Troubleshooting → Share Debug Logs

What Should Happen?

Cowork should create the vm_bundles/claudevm.bundle directory automatically and successfully move downloaded files into it, as it did prior to the update.

Error Messages/Logs

**Key error from cowork_vm_node.log**

[error] [download] VM download failed: ENOENT: no such file or directory, rename 'C:\Users\aksha\AppData\Local\Temp\wvm-9tTwRd\rootfs.vhdx' -> 'C:\Users\aksha\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'


---

Steps to Reproduce

Troubleshooting already attempted

• Full reboot
• Clear cache via Help → Troubleshooting
• Manual deletion of vm_bundles directory
• Windows Defender exclusions (Defender not running — superseded by McAfee)
• McAfee real-time scanning disabled entirely — error persists, confirming AV is not the cause
• McAfee exclusions added for all VHDX and ZST file paths
• Manually created destination folder — rename still fails
• Full clean reinstall of Claude Desktop
• Enabled Windows Hypervisor Platform

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.1.7053

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_