[FEATURE] Allow configuring VM bundle (vhdx) storage location

+1 — this is blocking me on a very common Windows hardware layout.

Setup: C: = 128 GB SSD, D: = 1 TB HDD (separate physical disks, so extending C: from D: isn't possible). The bundle's hardcoded location on the system drive doesn't fit, and there's no supported way to move it.

What I hit trying to work around it:

• Relocating vm_bundles / the Claude AppData folder to D: via mklink /J produces EXDEV: cross-device link not permitted on the rootfs.vhdx rename.
• Pointing TEMP/TMP off C: produces the same EXDEV.
• When a symlink does get past EXDEV, the VM then fails to start ("VM service not running" / an HCS mount error), apparently because the Host Compute Service doesn't resolve reparse points when mounting the VHD.

Requests:

1. A user setting to choose the VM bundle storage location.
2. Replace the atomic rename() with copyFile + unlink so cross-device / MSIX-boundary moves succeed even if the default location stays fixed.

Happy to share logs. This currently makes Cowork unusable for small-SSD + large-HDD users, which is a large share of Windows machines.

Will this ever be prioritized and fixed? Folks with older MS Surface Laptop + SSD really can't use Co Work due to this issue. Symlinks (Junction Links) should be allowed.

This is an issue for me too. Please take a look at this

+1 on this. Windows 10, HP laptop with a 117 GB C: drive that's ~90% full from the OS and normal apps. I have 377 GB free on a secondary drive (E:) but Cowork can't use it — the VM bundle is hardcoded to C:.
I tried the mklink /J junction workaround to move the bundle to E:. The result wasn't a clean failure: the workspace did launch, but came up degraded — it threw compression-related errors and silently lost specific capabilities (opening Word documents, merging PDFs no longer worked) while other things still functioned. So junctions don't just fail outright; they leave the VM in a partially-broken state, which is harder to notice than a hard error.
Right now I either run Cowork from a full C: with no headroom, or relocate it and lose features. A Settings → Cowork option to point the VM bundle at another drive would completely solve this. Would use it immediately.

I got this problem too, on window 11. my laptop is full ~ 95%, I cannot extend it, or change disk because window license. I want move claud vm to D drive. I was found this repo may help solve the problem: https://github.com/Hiroto-Kozuki/claude-cowork-migration/tree/main
But it still error, the create link is not work anymore.

Please! Forcing install locations to system drive is not on my list of things to keep fighting with in 2026.

Adding another use case for configurable VM bundle location.

My setup: C: is a small system drive with ~10 GB free; in addition, there is a large secondary drive with plenty of space. Cowork needs ~25 GB, so it won't start.

The existing workarounds don't help me:

Freeing up C: is possible in principle, but it would consume the entire headroom I need for installing any other substantial software. Trading my system drive's remaining capacity for one application's VM image isn't a reasonable ask.

Symlinks and junctions fail (EXDEV on rename, then HCS reparse-point errors when attaching the VHD).
Redirecting %USERPROFILE% to the secondary drive is possible, but relocating the entire user profile to fix one application is wildly disproportionate and risks breaking unrelated software.

A single setting for the VM bundle path would solve this cleanly. Docker Desktop and WSL both allow this, and it's a common need on machines with a small SSD plus a large data drive.