Cowork installation fails at 80% on Windows - EXDEV cross-device link error

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/42119
2. https://github.com/anthropics/claude-code/issues/40505
3. https://github.com/anthropics/claude-code/issues/39029

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

"This is not a duplicate — I am adding an additional report to confirm this issue is still occurring as of April 2026 on a fully updated Windows system. Please keep open."

I have now identified the exact root cause of my issue by reviewing related reports #27897, #30584, #34605, #36642 and #38457.
The installer downloads rootfs.vhdx to the Windows Temp folder and then attempts to move it using fs.rename() to AppData\Roaming\Claude\vm_bundles. The MSIX sandbox treats these as separate devices even though both are on C:, so Windows blocks the rename with EXDEV. The app then deletes the downloaded file and loops indefinitely — which is why it always fails at exactly 80%.
This has been reported repeatedly since February 2026 and the fix is well understood: replace fs.rename() with fs.copyFile() + fs.unlink() as a fallback when EXDEV is encountered.
There is no user-side workaround. I have tried redirecting workspace files, pausing Google Drive, and various other suggestions from support. None can work because the issue is in the app's file handling code, not in my system configuration.
I have been unable to use Cowork since purchasing it on 2nd April 2026. I would appreciate confirmation that a fix is in progress and an estimated timeframe.

@apengelly22-prog What version of Claude Desktop are you on? The EXDEV issue should be fixed in 1.569.0, if it's not please drop your logs below

<img width="984" height="324" alt="Image" src="https://github.com/user-attachments/assets/5247eaa5-4e40-4c7a-aac1-eb1f257fad3c" />

<img width="498" height="782" alt="Image" src="https://github.com/user-attachments/assets/a6f09701-2192-47de-8366-141799f50195" />

<img width="1039" height="423" alt="Image" src="https://github.com/user-attachments/assets/bdbb3125-c3a7-4fb2-8900-680882921439" />

Thank you for responding. I am on version 1.569.0 but still getting the EXDEV error. The paths are now both on C: rather than crossing drives, so something has changed, but it is still failing:
'C:\Users\User\AppData\Roaming\Claude\vm_bundles\claudevm.bundle.wvm-tmp-rn8Rqw\rootfs.vhdx' -> 'C:\Users\User\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'
I have tried reinstalling the workspace twice. Still failing.

I had the same EXDEV error at exactly 80%. In my case the root cause was the Windows "Where new content is saved" setting pointing to a different drive.

Check this: Settings > System > Storage > Advanced storage settings > Where new content is saved. If "New apps will save to" is set to anything other than C:\, change it to C:\.

You can verify if this is your issue by running in PowerShell:

Get-ChildItem "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc" | Format-Table Name, Attributes, Target

If you see symlinks (ReparsePoint) pointing to another drive like F:\ or G:\, that's the cause.

Also, since you have Google Drive installed, the CldFlt driver might be intercepting the rename operation. Try pausing Google Drive completely and also check if disabling CldFlt helps (though that will also disable Google Drive sync).

Full diagnostic tool here: https://github.com/LozadAPP/claude-cowork-windows-fix

How do i fix this error please?

<img width="1189" height="601" alt="Image" src="https://github.com/user-attachments/assets/2cca18f0-1f55-4969-aa6f-e40020ab4fe4" />

That's the issue right there! All your symlinks point to F:\WpSystem\ instead of C:\. Same problem I had but with D:\.

First, backup your config before doing anything:

New-Item -Path "$env:USERPROFILE\Desktop\Claude_Backup" -ItemType Directory -Force
Copy-Item "$env:APPDATA\Claude\claude_desktop_config.json" "$env:USERPROFILE\Desktop\Claude_Backup\" -ErrorAction SilentlyContinue

This saves your MCP servers and preferences. You can restore it after reinstalling.

Now the fix:

1. Go to Settings > System > Storage > Advanced storage settings > Where new content is saved
2. Change "New apps will save to" from F:\ to C:\
3. Clean uninstall:

Get-AppxPackage -Name "Claude" | Remove-AppxPackage
Remove-Item "$env:APPDATA\Claude" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "$env:LOCALAPPDATA\Claude" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "C:\ProgramData\Claude" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "F:\WpSystem\*\AppData\Local\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Force -ErrorAction SilentlyContinue

1. Reboot
2. Reinstall Claude Desktop as Administrator
3. Restore your config:

Copy-Item "$env:USERPROFILE\Desktop\Claude_Backup\claude_desktop_config.json" "$env:APPDATA\Claude\" -ErrorAction SilentlyContinue

Full guide and diagnostic tool: https://github.com/LozadAPP/claude-cowork-windows-fix

RESOLVED — SVM Mode disabled in BIOS was the root cause
I am happy to report that Cowork is now working perfectly after 5 days of troubleshooting!
For anyone else experiencing this issue, here is the complete chain of fixes that resolved it for me:
Step 1 — The EXDEV error
My Windows setting "Where new content is saved" (Settings > System > Storage > Advanced storage settings) was set to F: instead of C:. This caused MSIX to create symlinks pointing to F:, which caused the EXDEV cross-device error. Changing this to C:, doing a complete clean uninstall and reinstalling Claude Desktop resolved the EXDEV error.
Step 2 — Virtualization not available
After resolving EXDEV, Cowork showed a new error: "Virtualization is not available." Although VirtualMachinePlatform and HypervisorPlatform were enabled in Windows, SVM Mode (AMD CPU Virtualization) was disabled in the BIOS/UEFI firmware. Enabling SVM Mode under Advanced > CPU Configuration in the BIOS and rebooting resolved this completely.
Cowork is now running beautifully.
Thank you sincerely to everyone who responded and helped, particularly MarshallOfSound and the creator of the diagnostic tool. Your help was invaluable. I hope this helps other Windows users with similar setups. 🎉

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.