One file filled our system drive: a 12.4 GB claudevm.bundle in AppData, the sandbox VM the desktop build of Claude Code spins up to run tools. Our C: drive is a small fast SSD with the OS and not much headroom, and that single bundle pushed it into the red.

The fix looked routine. Move the data to a roomier drive, leave a junction behind so the app never notices. We have done this a dozen times for IDE caches, Docker volumes and npm globals. We expected ten minutes. It turned into a fight with Windows, because Claude Code installs as a UWP/MSIX package, and those packages carry folders you cannot move even as a full administrator.

Where the bytes live

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

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

The <publisherhash> is the opaque base32-looking string MSIX generates from the publisher identity. 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. Run Get-ChildItem sorted by length before you touch anything, so you know the bundle is the culprit.

The move that failed

The textbook relocation is two steps:

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. A junction is a reparse point: the filesystem redirects every access to the target, so the app opens the same path it always has. The junction was never the problem. Getting the bytes out of the way so we could create one was.

We killed the app first, since a running Claude.exe holds file locks. Then we ran the Move-Item, and it blew up:

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

It choked on three 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 folders are owned by that identity, not by your user account. They hold the WinINET cache, cookies and history the sandboxed process uses, and their ownership and ACLs are locked down on purpose.

The wrong turn: elevating

We read “Access denied” as “you forgot to be admin.” So we reopened the terminal as administrator, ran the same Move-Item, and got the identical failure on the identical three folders. That cost us a round trip and told us nothing new. Elevation grants privilege, not ownership, and Move-Item will not relocate something you do not own at any integrity level. For the AC\ folders, ownership was the thing in the way.

The recipe that worked

Four steps. Run them one at a time and read each result.

1. Copy with robocopy instead of moving. robocopy reads and writes new copies rather than relocating the originals, so it does not trip on the ownership problem:

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). /XJ excludes junction points so robocopy does not wander into reparse loops. Afterward D: holds a faithful copy, and the originals, app-container folders and all, are still on C:.

2. Take ownership of the leftovers. This is what elevation alone could not do:

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, makes you the owner, and answers “yes” to the default prompt on directories it hits. icacls ... /grant administrators:F /T writes a full-control ACE for the Administrators group across every file and folder. Now the AC\ folders that refused to move are yours to remove.

3. Delete the original.

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. Check 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 there is room. C: is back in the green.

What to remember

Anything under AppData\Local\Packages\ that belongs to a UWP/MSIX app can hold AC\ folders the sandbox owns, and Move-Item refuses them even when elevated. Copy with robocopy, take ownership of the leftovers with takeown plus icacls, delete, then junction. If a tool reports “Access denied” under one of those AC\ folders while you are already an administrator, fix ownership instead of reaching for a higher privilege.