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

[byu111]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

Claude Cowork's VM bundle (rootfs.vhdx, sessiondata.vhdx, etc.) is stored in a hardcoded location under %LocalAppData%\...\claudevm.bundle\

The bundle is already ~12 GB after initial setup, and sessiondata.vhdx grows over time as the VM accumulates state. On systems where C: is with limited capacity, this footprint is significant and unavoidable — there is currently no way to relocate it to a secondary drive. NTFS junctions (mklink /J) fail. There is no reliable user-side workaround.

For me, it's quite unconvenient. I have to move other files to D: to continue use Cowork.

• OS: Windows 11
• Latest Claude Desktop

Proposed Solution

Add a setting in Claude Desktop (Settings → Cowork) that lets users specify a custom storage location for the VM. When changed, the app should either migrate the existing bundle to the new location or download it fresh there on next startup.

Alternative Solutions

No response

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

No response

Additional Context

No response

[error404-personnotfound]

+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.

[chinmayrane]

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.

[claude-wolfgang]

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

[fritzmlukas-netizen]

+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.

[xhuyvn]

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.

[Reithan]

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