[BUG] Cowork EXDEV: cross-device link not permitted — rename within same directory (Windows 11 Pro, OneDrive present)

Found 3 possible duplicate issues:

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

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 of #38457 (CldFlt/Dropbox) — CldFlt was confirmed STOPPED during testing and the error persisted.
The key difference in this report: both source and destination paths are inside the same directory (claudevm.bundle\), not across drives or different volumes. This suggests a distinct failure mode specific to the Home→Pro upgrade path combined with OneDrive presence.
Preventing auto-close as this combination has not been documented in the referenced issues.

Hello, I'd like to report the same issue. I didn't want to open a duplicate, as I see there are already a few marked as duplicates by github-actions.
After chatting with claude about it, and trying to resolve this in many ways, including some directions in powershell. The issue persist and here's the summary:

Cowork workspace setup fails repeatedly with: EXDEV: cross-device link not permitted, rename 'C:\Users\maya4\AppData\Roaming\Claude\vm_bundles\claudevm.bundle.wvm-tmp-AVAM1B\rootfs.vhdx' -> '...\claudevm.bundle\rootfs.vhdx'
Steps already tried:

Reinstalled Claude (fixed initial HRESULT 0x80073D0D error)
Cleared AppX packages via PowerShell
Enabled Hyper-V
Verified AppData is a normal directory on C: drive, not a symlink or network path
Manually pre-created the vm_bundles destination folder
Restarted PC multiple times

Error persists on every attempt.

I've been having the same issue and can't seem to resolve it. It's very frustrating, as I've been wanting to use Cowork.

Issues i keep getting on my end:
Failed to start Claude's workspace
EXDEV: cross-device link not permitted, rename 'C:\Users\Michael\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-Ks6mfv\rootfs.vhdx' -> 'C:\Users\Michael\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'

Same issue here with a clean claude desktop install.

EXDEV: cross-device link not permitted, rename 'C:\Users\dave\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-vPGulK\rootfs.vhdx' -> 'C:\Users\dave\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'
Restarting Claude or your computer sometimes resolves this. If it persists, you can reinstall the workspace.

I even tried manually copying the files from the temp folder into the actual and it made no difference.

same issue here

OK , so i found a fix for this the instructions seem to imply that just turning on the VMP is enough, it isnt you also have to turn on the full virtualisation stack (VMP + Windows Hypervisor Platform + WSL) in order for co-work to work .

Confirming this on Windows 11 — same-directory rename, MSIX build. Adding my diagnostics in case they help narrow it down.

Identical failure to OP: rename() fails with both source and destination inside the same claudevm.bundle directory on a single C: drive. The .wvm-tmp-* suffix changes each attempt; the error is otherwise constant on every launch.

EXDEV: cross-device link not permitted, rename
'C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-XXXXXX\rootfs.vhdx'
-> 'C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'

Environment

• Windows 11
• Claude Desktop MSIX build
• Single SSD, C: only
• OneDrive present

Ruled out on my end

• %TEMP%, %LOCALAPPDATA%, and %APPDATA% are all standard and under C:\Users\<user>\ — no redirection
• dir /AL on the user profile folder shows only default Windows compatibility junctions; none point off C:
• dir /AL on AppData\Roaming returns no junctions or symlinks
• Disabled CldFlt (sc.exe config CldFlt start= disabled) + reboot — error persists (matches OP)
• Full uninstall + clean reinstall — persists
• Launched Claude as administrator — persists
• Machine restart — persists

So on my system this is not cross-drive, not a junction, not a redirected profile, and not CldFlt. Consistent with MSIX filesystem virtualization treating the .wvm-tmp-* subfolder and its parent claudevm.bundle as separate filesystems, so fs.rename() fails even within one real directory. A copyFile + unlink fallback (or a cross-device-safe move) should resolve it.

Like OP, I also could not find cowork_vm_node.log — it does not appear to be created, presumably because the service exits before writing it.

Additional impact worth flagging: Cowork project/session state appears to be local-only and does not sync to the account. A clean reinstall done while troubleshooting this left my Projects panel empty (sessions emptied, no projects restored). Config backups survive in .claude\backups\ but there is no documented restore path. So this bug indirectly pushes users toward reinstalls that can cost them their Cowork projects.

+1, same issue here. Cowork fails immediately on workspace setup, before doing anything in a project.

Error (recurs every launch, temp suffix changes each time):

Failed to start Claude's workspace
EXDEV: cross-device link not permitted, rename
'C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-XXXXXX\rootfs.vhdx'
-> 'C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'

Both source and destination are in the SAME directory on C: — not a cross-drive issue.

What makes my report useful: I systematically ruled out the common culprits, and EXDEV STILL persists:

• CldFlt driver: unloaded via fltmc unload CldFlt, confirmed GONE from fltmc filters output — EXDEV still occurs
• OneDrive: signed out and sync paused — no effect
• Dual install: removed the duplicate Claude package, now single MSIX install only — no effect
• Windows storage redirect to D: — ruled out, all paths in this error are on C:
• Full clean reinstall from official ClaudeSetup.exe — no effect

This isolates the root cause to the MSIX sandbox virtualizing AppData\Roaming as a separate filesystem, making Node.js fs.rename() throw EXDEV even within the same real directory. It is NOT solvable from the user side.

Environment:

• OS: Windows 11
• Install: official ClaudeSetup.exe → MSIX package (Claude_..._x64__pzs8sxrjxfjjc, in C:\Program Files\WindowsApps)
• Virtualization: Hyper-V, Virtual Machine Platform, Windows Hypervisor Platform all enabled
• Occurs on a fresh project before any action is taken

Requested fix (same as other reports): replace fs.rename() with copy + unlink fallback on EXDEV, OR resolve the temp dir to share the same VFS mount as the destination.

I am experiencing the same / very similar issue with Claude Desktop Cowork on Windows.

Error

Claude Desktop shows this error when starting Cowork / workspace:

Failed to start Claude's workspace

EXDEV: cross-device link not permitted, rename
'C:\Users\<Chinese-username>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-XXXXXX\rootfs.vhdx'
->
'C:\Users\<Chinese-username>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'

Environment

• Claude Desktop version: v1.15200.0
• Platform shown in the feedback dialog: win32 10.0.26200
• Windows edition: Windows 11 Home Chinese
• Windows version: 25H2
• OS build: 26200.8655
• Windows username contains non-ASCII / Chinese characters
• The issue happens when starting Claude Cowork / workspace

What I expected

Claude Cowork workspace should start normally after downloading and installing the VM bundle.

What happened instead

Cowork fails every time during workspace startup.

It appears to fail when moving or renaming rootfs.vhdx from the temporary .wvm-tmp-* folder into the final claudevm.bundle folder.

In my case, the source and destination paths are both under:

AppData\Roaming\Claude\vm_bundles\claudevm.bundle

So this does not look like a normal cross-drive move. It looks similar to the reported Windows/MSIX/Cowork rootfs.vhdx rename issue where fs.rename() fails with EXDEV.

Steps already tried

I already tried:

• Restarting Claude Desktop
• Restarting Windows
• Reinstalling the workspace
• Deleting Claude vm_bundles cache
• Deleting temporary wvm-* files
• Enabling Virtual Machine Platform
• Enabling WSL Windows feature
• Relaunching Claude Desktop as administrator
• Using a simple local workspace path

The issue still happens every time.

Diagnostic logs

I submitted diagnostic logs through Claude Desktop's Cowork feedback dialog.

Reference ID:

d13abcf5-c010-4834-9327-c701f143080e

Environment:
Claude Desktop version: 1.18286.0.0 (MSIX/Windows Store installation)
Windows 11
Package: Claude_pzs8sxrjxfjjc

Error:
EXDEV: cross-device link not permitted, rename 'C:\Users\Markus\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx.zst.21237ca86d15.partial' -> 'C:\Users\Markus\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx.zst'
Full node log excerpt (cowork_vm_node.log):
2026-07-05 19:21:36 [error] [VM:start] Startup failed: YKt [VMDownloadError]: EXDEV: cross-device link not permitted, rename 'C:\Users\Markus\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx.zst.21237ca86d15.partial' -> 'C:\Users\Markus\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx.zst'
errno: -4037,
code: 'EXDEV',
syscall: 'rename'
Ruled out via testing:

AppData\Roaming is not a reparse point (fsutil reparsepoint query → error 4390, not a reparse point)
AppData is not redirected via registry (HKCU\...\User Shell Folders\AppData = default %USERPROFILE%\AppData\Roaming)
Windows Defender has no quarantine entries related to rootfs/vhdx
Sufficient disk space and write permissions on the target directory confirmed
A plain Rename-Item on a manually created .partial file inside claudevm.bundle succeeds without error, when executed immediately after file creation

Key finding via Process Monitor:
Claude.exe itself deletes .partial files inside claudevm.bundle after a short interval. Procmon captured this event:
Claude.exe (PID 19008) SetDispositionInformationEx
Path: C:\Users\Markus\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\NewTest.txt.partial
Result: SUCCESS
Flags: FILE_DISPOSITION_DELETE, FILE_DISPOSITION_POSIX_SEMANTICS, 0x10
A manually created .partial test file in the same directory was deleted by Claude.exe roughly 60 seconds after creation, without any user action or external process involvement (confirmed via Procmon, no other process touched the file).
Likely root cause: Claude appears to run an internal cleanup routine that removes .partial files in the bundle directory after a timeout. If the rootfs.vhdx.zst download takes longer than this internal timeout, the cleanup routine may delete or mark-for-deletion the .partial file concurrently with the download process's own rename() call, causing a race condition between the two operations on the same file handle. This would explain the EXDEV even though source and destination are in the same directory.
Suggested fix: Either disable/lengthen the internal .partial cleanup timeout during an active download, or ensure the download process holds an exclusive lock on the .partial file until the rename completes, preventing the cleanup routine from acting on it concurrently.

Same with me.

Running command
bash

echo ready
Output

Workspace unavailable. The isolated Linux environment failed to start (EXDEV: cross-device link not permitted, rename 'C:\Users\Asus\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx.zst.21237ca86d15.partial' -> 'C:\Users\Asus\AppData\Roaming\Claude\vm_bundle)

I have tried almost everything as mentioned by different users, OP and in the group. no resolve.

same error with me

Environment:

• Claude Desktop version: 1.19367.0.0
• OS: Windows 11 Pro — upgraded in-place from Windows 11 Home (same machine, not a clean install)
• Install method: ran Claude-Setup.exe from claude.ai/download — resulted in an MSIX package install (Claude_1.19367.0.0_x64__pzs8sxrjxfjjc), installed on D: drive, user profile/AppData on C:
• Hyper-V: Enabled
• Virtual Machine Platform / Windows Hypervisor Platform: Enabled
• VM bundles path: C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle

Key detail matching your report: source and destination of the failing rename are in the exact same directory — only the filename differs. Not a genuine cross-drive/cross-volume move.

Raw log (%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\cowork_vm_node.log):
[error] [download] VM download failed: EXDEV: cross-device link not permitted, rename 'C:\Users<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx.zst.21237ca86d15.partial' -> 'C:\Users<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx.zst'
[error] [VM:start] Startup failed: l5t [VMDownloadError]: EXDEV: cross-device link not permitted, rename '...\rootfs.vhdx.zst.21237ca86d15.partial' -> '...\rootfs.vhdx.zst'
at async Object.rename (node:internal/fs/promises:785:10)
at async Kvn (app.asar.vite\build\index.chunk-CpjGn3fz.js:799:16528)
at async Object.startVM (app.asar.vite\build\index.chunk-CpjGn3fz.js:2977:45164)
errno: -4037,
code: 'EXDEV',
syscall: 'rename'
[warn] [VM:start] Download failed, leaving VM offline (no auto-reinstall — bundle never reached disk)

Mine fails one stage earlier — on the rename of the compressed .zst download itself (.partial → final .zst), before decompression even starts, rather than on the post-decompression rootfs.vhdx rename. Same underlying fs.rename() EXDEV issue, just triggered at an earlier point in the same pipeline. Auto-retry after ~7s fails identically — fully deterministic, not intermittent.

Client-side workarounds tried (all failed, error unchanged):

• ❌ Run Claude Desktop as Administrator
• ❌ sc.exe config CldFlt start= disabled + full system reboot, confirmed CldFlt unloaded via fltMC.exe before/after — CldFlt ruled out as the cause
• ❌ Windows Settings → Apps → Claude → Advanced options → Repair (not available/greyed out for this package)
• ❌ Windows Settings → Apps → Claude → Advanced options → Reset + full system reboot — error identical afterward
• ⏳ Not tried: disabling luafv (UAC virtualization) — avoided as it's more deeply integrated in the OS and riskier to toggle

Adding another confirmed case of the same-directory EXDEV rename failure,
with diagnostics ruling out all user-side causes.

Error (every retry, across 3 full reinstalls — Cowork has never worked):

EXDEV: cross-device link not permitted, rename
'C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx.zst.21237ca86d15.partial'
-> 'C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx.zst'

Source and destination are in the same directory.

Environment: Claude Desktop [1.19367.0.0], direct .exe installer (not MSIX/Store).
Windows 11 [25H2, OS Build 26200.8737]. Everything on C:, AppData not redirected, no junctions.
OneDrive fully uninstalled, no Dropbox, no third-party antivirus.

Ruled out (each disabled + reboot, unload confirmed via fltmc filters):

• CldFlt (was still loaded with 6 instances despite OneDrive uninstalled) — error persists
• luafv (EnableVirtualization=0) — error persists
• gameflt — error persists
• Remaining filters are core Windows components (bindflt, UCPD, WdFilter, wcifs, bfs, FileCrypt)

Key evidence — manual rename in the exact failing folder succeeds from user context:

cd $env:APPDATA\Claude\vm_bundles\claudevm.bundle
"test" | Out-File test.partial
Rename-Item test.partial test.txt # succeeds

So the failure is specific to the process context Claude's VM service performs
the rename in, not the filesystem itself.

Related finding: before disabling CldFlt + luafv, new chats did not persist
across app restarts on this machine. After disabling them, chat persistence
works. Something in the filter stack was also breaking write-temp-then-rename
for the main app process — the VM service rename still fails regardless.

This is not fixable user-side. Please ship the copyFile + unlink fallback on
EXDEV proposed in #30584 / #39029.

As a paying customer: this consumed a full day and three reinstalls. If a fix
or timeline isn't forthcoming soon, I'll be canceling my subscription.

Same EXDEV error — root cause on my machine was the MSIX package split across two physical drives. Fixed. Details below in case it helps others.
Environment: Windows 11, Claude Desktop 1.20186.1.0 (MSIX, SignatureKind: Developer, installed from claude.ai/download — not the Store)
Symptom: Identical to OP — download completes, then rename fails within the same directory:
EXDEV: cross-device link not permitted, rename '...\claudevm.bundle\rootfs.vhdx.zst.21237ca86d15.partial' -> '...\claudevm.bundle\rootfs.vhdx.zst'
Looped on every retry. Reinstalling multiple times did not help.
Ruled out:

No OneDrive or Dropbox installed; fltmc filters confirmed CldFlt not loaded
Manually renaming the .partial via Explorer worked fine (so renames weren't blocked system-wide, only for the app process)
Pre-placing a completed rootfs.vhdx in the bundle didn't help — log showed rootfs.vhdx origin missing, redownloading... and it restarted the cycle
cipher /c showed all bundle files EFS-encrypted as "Application Protected" (matches #38316)

The key finding: Get-AppxPackage reported InstallLocation: C:\Program Files\WindowsApps\..., but the stack trace in cowork_vm_node.log showed the app actually executing from D:\WindowsApps\Claude_1.20186.1.0_... — the package was split across two physical drives (likely from Windows' "save new apps to D:" setting during an earlier reinstall). With MSIX per-package encryption in play, this appears to be what made the rename cross a device boundary.
Fix:

1. Uninstall Claude Desktop
2. Settings → System → Storage → Advanced storage settings → "Where new content is saved" → set "New apps will save to" = C:
3. Reinstall from claude.ai/download
4. Cowork VM setup completed on first attempt — full bundle built (rootfs.vhdx, sessiondata.vhdx, smol-bin.vhdx, vmlinuz, initrd, .origin files), no EXDEV

Suggestion for the devs: worth checking whether the EXDEV fallback (copy+delete) is still missing, and whether install-drive vs. data-drive mismatch is detectable at setup time — "check if your app installed to a secondary drive" would have saved me many hours.

Also figured this out with the help of Claude lol.