Claude Code ate my C: drive. Not a slow creep of logs and caches either. One file: a 12.4 GB claudevm.bundle sitting in AppData, the sandbox VM the desktop build spins up to run tools. My system drive is a small fast SSD with the OS and not much headroom, and a single bundle that size was enough to push it into the red.

The fix is obvious in principle. Move the data to a roomier drive, leave a junction behind so the app never notices. I have done this a dozen times for IDE caches, Docker volumes, npm globals. I expected ten minutes. It turned into a real fight with Windows, because Claude Code installs as a UWP/MSIX package, and UWP packages carry a set of folders that you cannot move even when you are a full administrator. Here is what actually happened and the recipe that worked.

Where the bytes live

The desktop Claude Code build is packaged as MSIX, so it does not live in Program Files like a classic installer. It lands under your per-user packages root with a publisher-hashed name:

C:\Users\<you>\AppData\Local\Packages\Claude_<publisherhash>\

The <publisherhash> is that opaque base32-looking string MSIX generates from the publisher identity. Inside that package, the VM bundle sits a few levels down under LocalCache\Roaming\Claude\vm_bundles\, and that is where the 12.4 GB claudevm.bundle was hiding. Confirm it with Get-ChildItem sorted by length before you touch anything, so you know the bundle is genuinely the thing eating your drive and not a red herring.

The plan that should have worked

The textbook relocation on Windows is two moves:

Terminal window
Move-Item "C:\Users\<you>\AppData\Local\Packages\Claude_<publisherhash>" `
          "D:\ClaudeData\Claude_<publisherhash>"


New-Item -ItemType Junction `
         -Path   "C:\Users\<you>\AppData\Local\Packages\Claude_<publisherhash>" `
         -Target "D:\ClaudeData\Claude_<publisherhash>"

Move the whole package folder to the big drive, then drop a directory junction at the original path pointing at the new home. A junction is a reparse point: the filesystem transparently redirects every access to the target, so the app opens the exact same path it always has and never learns it moved. This is the right tool. Junctions are the correct answer for relocating a fat app cache off C:, full stop. The problem was not the junction. The problem was getting the bytes out of the way so I could create one.

Kill the app first. Any running Claude.exe holds file locks, so close it from Task Manager before you start. With it dead, I ran the Move-Item. And it blew up.

The permission wall

Move-Item : Access to the path is denied.
... sufficient access rights to perform the requested operation.

It choked on three specific folders, all under an AC\ subdirectory inside the package:

AC\INetCache
AC\INetCookies
AC\INetHistory\History.IE5

AC is “app container.” When an MSIX/UWP app runs, Windows gives it a sandboxed identity, and these AC\ folders are owned by that app-container identity, not by your user account. They hold the WinINET cache, cookies, and history the sandboxed process uses. The ownership and ACLs on them are deliberately locked down so the sandbox cannot be tampered with from outside.

Here is the part that cost me time: running PowerShell elevated does not help. I assumed “Access denied” meant “you forgot to be admin,” reopened the terminal as administrator, ran the same Move-Item, and got the identical failure on the identical three folders. Admin is not the missing ingredient. You are not the owner of those folders, and Move-Item will not relocate something you do not own, no matter how high your integrity level is. Elevation grants privilege; it does not grant ownership. For the AC\ app-container folders, ownership is the thing standing in your way.

The recipe that works

Once you stop trying to move the folders and start working around their ownership, it is four steps. Run them one at a time, read each result, do not paste them as one blob.

1. Copy the bytes with robocopy, not Move-Item. robocopy does not try to relocate the originals, it reads and writes new copies, and it is happy to mirror ACLs and skip the things Move-Item trips on:

Terminal window
robocopy "C:\Users\<you>\AppData\Local\Packages\Claude_<publisherhash>" `
         "D:\ClaudeData\Claude_<publisherhash>" /E /COPYALL /XJ

/E copies all subdirectories including empty ones, /COPYALL brings over data, attributes, timestamps, and the full security descriptor (owner, ACLs, auditing), and /XJ excludes junction points so robocopy does not wander into reparse loops. After this, the new drive has a faithful copy. The originals are still sitting on C:, app-container folders and all.

2. Seize ownership of the leftovers so you can delete them. This is the step elevation alone could not give you. Take ownership recursively, then grant yourself full control:

Terminal window
takeown /F "C:\Users\<you>\AppData\Local\Packages\Claude_<publisherhash>" /R /D Y
icacls "C:\Users\<you>\AppData\Local\Packages\Claude_<publisherhash>" /grant administrators:F /T

takeown /R /D Y walks the whole tree and makes you the owner, answering “yes” to the default prompt on directories it hits. icacls ... /grant administrators:F /T then writes a full-control ACE for the Administrators group across every file and folder. Now the AC\ folders that refused to move are yours, and Windows will let you remove them.

3. Delete the original. With ownership and ACLs in hand:

Terminal window
Remove-Item "C:\Users\<you>\AppData\Local\Packages\Claude_<publisherhash>" -Recurse -Force

If this still complains about a specific file, it is almost always a lingering lock, which means something is still running. Recheck Task Manager for a stray Claude.exe or background helper, then retry.

4. Drop the junction. The original path is gone, so recreate it as a reparse point to the new location:

Terminal window
New-Item -ItemType Junction `
         -Path   "C:\Users\<you>\AppData\Local\Packages\Claude_<publisherhash>" `
         -Target "D:\ClaudeData\Claude_<publisherhash>"

Verify with Get-Item <path> | Select LinkType, Target (LinkType should read Junction), then launch Claude Code. It opens the same package path, the OS redirects it to D:, and the 12.4 GB bundle now lives where you have room. C: drops back into the green.

The takeaway

A directory junction is the correct way to move a heavy app cache off your system drive on Windows, and that part never wavered. The trap is specific to UWP/MSIX apps, which is anything living under AppData\Local\Packages\. Those packages carry AC\ app-container folders the sandbox owns, and Move-Item will refuse to relocate them no matter your privilege level. “Run as administrator” is not the fix, because the wall is ownership, not privilege.

So do not fight Move-Item. Copy the bytes with robocopy, take ownership of the protected leftovers with takeown plus icacls, delete, then junction. Same trick applies to any MSIX-packaged app whose cache has gotten out of hand: the moment you see “Access denied” on a folder under AppData\Local\Packages\...\AC\ while elevated, stop reaching for a higher privilege and reach for takeown instead. Ownership is the door, not admin.