Image upload fails with EXDEV (cross-device rename) when user profile AppData is redirected to another volume (Windows)

Environment

• OS: Windows 11 Home, 10.0.26200
• Claude Desktop, reinstalled recently from the official website installer
• User profile's AppData\Roaming is redirected via a reparse point to a WpSystem\<SID>\... folder. In my case the reparse target string resolves to C:\WpSystem\..., but that path doesn't exist under normal access — the real data lives at D:\WpSystem\<SID>\... on a different drive letter. stat -f on both paths returns the same filesystem ID, so it's the same underlying volume, just reachable through two different drive-letter mount points.

Steps to reproduce

1. Have a Windows profile where AppData is redirected this way (common with storage migration tools / enterprise imaging / "move new content to another drive" configs).
2. Open Claude Desktop, start a chat.
3. Paste or attach an image.

Actual behavior

The image upload consistently fails with:

EXDEV: cross-device link not permitted, rename 'D:\WpSystem\S-1-5-21-...\...\pending-uploads\<uuid>-<ts>_image.png' -> 'C:\Users\<user>\AppData\Roaming\Claude\local-agent-mode-sessions\<session>\...\uploads\<uuid>-<ts>_image.png'

The failed file is left behind in pending-uploads every time, so they accumulate with every failed attempt.

Separately (possibly related), after not opening the app for about a month due to a lapsed subscription, the app failed to start entirely with:

Failed to start Claude's workspace
failed to set session disk path: session disk not found: ...\vm_bundles\claudevm.bundle\sessiondata.vhdx

Reinstalling the app fixed the startup issue, but the image-upload EXDEV error persists after reinstall (as expected, since it's rooted in the OS-level profile redirection, not the app installation).

Suspected root cause

The app's config (config.json) contains a lastSeenRequireCoworkFullVmSandbox key, suggesting file operations for uploads may go through a VM/sandbox layer ("Cowork Full VM Sandbox"). It looks like the code path handling the upload does a plain rename/move from the pending-uploads temp location to the final destination, and does not fall back to copy+delete when the OS (or the sandbox's virtualized mount) reports the source and destination as different devices — which happens when the user's profile folders are split across drive letters/volumes this way.

Suggested fix

When moving uploaded files, catch EXDEV and fall back to copy-then-delete instead of surfacing the raw error to the user.

Impact

Every image paste/attach fails 100% of the time on this setup, with no workaround inside the app itself.