[BUG] Cowork VHDX rename fails with EXDEV on systems with CldFlt (Windows Cloud Files filter driver) active — Dropbox conflict

I'm aware this is the Claude Code repository. Filing here as there is no dedicated Claude Desktop issue tracker and Cowork issues have consistently been tracked here by the community and Anthropic engineers. See related issues #27801, #25663, #24918, #27010.

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 is completely non-functional on Windows systems where the CldFlt
(Windows Cloud Files API filter driver) is active. This affects all users
with Dropbox installed.

Claude's VM bundle setup downloads rootfs.vhdx to the TEMP directory, then
attempts a rename() syscall to move it to its final destination at
AppData\Roaming\Claude\vm_bundles\claudevm.bundle\. CldFlt intercepts this
rename() at the filesystem level and returns EXDEV (cross-device link not
permitted), even though both paths are physically on the same volume (C:\).

Root cause confirmed: disabling CldFlt resolves the error instantly.
Re-enabling CldFlt reproduces it instantly. However, disabling CldFlt breaks
Dropbox entirely, making this a mutually exclusive conflict with no user-side
workaround.

Environment:

• OS: Windows 11 Pro
• Claude Desktop: 1.1.8359.0
• CPU: AMD Ryzen 5600X / GPU: RTX 2080 Ti
• Dropbox: 246.3.3448 (sync folder on separate drive X:\)
• CldFlt: confirmed active via fltMC.exe → CldFlt 3 180451 0
• Hyper-V: enabled, vmms and vmcompute both Running
• WSL2: not installed

cowork-service.log

2026/03/24 17:45:36 [HCS] vmcompute.dll loaded successfully
2026/03/24 17:45:36 [HCS] computecore.dll loaded successfully
2026/03/24 17:45:36 [HCS] Procs initialized, HCS ready
2026/03/24 17:45:36 [HCN] Initialized HCN API from computenetwork.dll
2026/03/24 17:45:36 [HCN] EnumerateNetworks result: []
2026/03/24 17:45:36 Service error: signature verification initialization
failed: failed to get service executable path: The system cannot find
the path specified.

Workarounds attempted — all failed:

• Redirecting TEMP to C:\ClaudeTemp (outside user profile) — EXDEV persists as destination remains under C:\Users\
• Junction point at AppData\Roaming\Claude\vm_bundles → C:\ClaudeVMBundles — Node.js EXDEV logic still triggers across junction boundary
• Junction point for entire AppData\Roaming\Claude → C:\ClaudeData — breaks MSIX package identity, service fails with signature verification error
• Disabling CldFlt — resolves EXDEV but breaks Dropbox (CloudFilesApi initialization fails)
• Adding Windows Defender exclusions for Claude paths — no effect
• Full uninstall, AppData wipe, fresh reinstall — EXDEV reproduces on every attempt

What Should Happen?

Cowork workspace setup should complete successfully and the VM should start
normally. The VHDX bundle placement should not fail on systems where the
Windows Cloud Files API filter driver (CldFlt) is active.

Recommended fix: replace the rename() operation with an explicit copy() +
delete() sequence for VHDX bundle placement. This will succeed regardless
of cloud filter driver interception. Alternatively, register the Claude
bundle path as excluded from cloud filter scope using the Windows
Cloud Files API.

This affects all Claude Desktop users on Windows with Dropbox, OneDrive
Files On-Demand, or any other application that installs CldFlt.

Error Messages/Logs

Failed to start Claude's workspace
EXDEV: cross-device link not permitted, rename 
'C:\Users\SKRON\AppData\Local\Temp\wvm-XXXXXX\rootfs.vhdx' -> 
'C:\Users\SKRON\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.

Steps to Reproduce

1. Install Dropbox on Windows 11 Pro (any version)
2. Confirm CldFlt is active: run fltMC.exe in PowerShell — CldFlt should appear in the list
3. Install Claude Desktop (tested on 1.1.8359.0)
4. Open Claude Desktop and navigate to the Cowork tab
5. Click to set up the Cowork workspace
6. Observe: download begins, reaches ~60%, then fails with:

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

To confirm CldFlt is the cause:

1. Run in Admin PowerShell: sc.exe config CldFlt start= disabled
2. Reboot
3. Retry Cowork setup — it proceeds past the rename step
4. Re-enable CldFlt: sc.exe config CldFlt start= auto
5. Reboot and retry — EXDEV error returns immediately

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude Desktop 1.1.8359.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Related issues: #27801, #25663, #24918, #27010

Note: this is not a Claude Code CLI issue — this is Claude Desktop / Cowork.
Filing here as Cowork issues have been tracked in this repository.

The conflict is mutually exclusive: CldFlt must be active for Dropbox to
function, but CldFlt prevents Claude's VHDX rename from succeeding. There
is no user-side workaround. This requires a code-level fix in Claude's
VM bundle placement logic.

Note, as stated above I'm aware this is the Claude Code repository. Filing here as there is no dedicated Claude Desktop issue tracker and Cowork issues have consistently been tracked here by the community and Anthropic engineers. See related issues #27801, #25663, #24918, #27010.