--- title: "Moving Claude Code Off Your C: Drive: The 12.4 GB VM Bundle and the UWP Permission Wall" canonical: https://dxdev.com/blog/move-claude-code-off-c-drive-junction-uwp-permission-wall/ datePublished: 2026-02-26 --- 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\\AppData\Local\Packages\Claude_\ ``` The `` 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: ```powershell Move-Item "C:\Users\\AppData\Local\Packages\Claude_" ` "D:\ClaudeData\Claude_" New-Item -ItemType Junction ` -Path "C:\Users\\AppData\Local\Packages\Claude_" ` -Target "D:\ClaudeData\Claude_" ``` 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: ```powershell robocopy "C:\Users\\AppData\Local\Packages\Claude_" ` "D:\ClaudeData\Claude_" /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: ```powershell takeown /F "C:\Users\\AppData\Local\Packages\Claude_" /R /D Y icacls "C:\Users\\AppData\Local\Packages\Claude_" /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: ```powershell Remove-Item "C:\Users\\AppData\Local\Packages\Claude_" -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: ```powershell New-Item -ItemType Junction ` -Path "C:\Users\\AppData\Local\Packages\Claude_" ` -Target "D:\ClaudeData\Claude_" ``` Verify with `Get-Item | 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. ## Related - [You can't repoint a junction under live file handles (why I had to stage the .claude move)](/blog/cant-repoint-a-junction-under-live-file-handles/): what happens when you try to swap a junction while the app still has handles open - [claude --resume worked in my terminal and failed in my web app: the LocalSystem homedir trap](/blog/nssm-localsystem-homedir-claude-resume-systemprofile/): another Claude data-path problem caused by Windows service identity - [Where does the daemon live? Reusing a scheduled-task tick instead of always-on infra](/blog/where-does-the-daemon-live-reuse-a-schtask-tick/): placing long-running AI tooling on Windows without a full service install - [My Agent's Chrome Was Running but Invisible: A Windows Session 0 Isolation Ghost Story](/blog/agent-chrome-invisible-windows-session-0-isolation/): Windows session isolation biting an AI agent on the same box - [My pinned app kept vanishing after every reboot, and it wasn't Windows being flaky](/blog/pinned-app-vanishes-after-reboot-self-updater-staging-folder/): MSIX self-updater behavior on Windows desktop apps