### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement On Windows, the Claude Code desktop app (Store/MSIX package) stores all user data in `%APPDATA%\Claude\`. There is no setting, env var, or CLI flag to relocate this to another drive. The app is installed with the `unv

Adding another use case for this: I'd like Claude Desktop's data (vm_bundles, sessions, etc.) off C: for two reasons: - Storage cost - my C: drive is a smaller/pricier SSD, and secondary storage is much cheaper per GB. Having 10+ GB of VM bundle data forced onto C: is a real cost for me. - Reinstall/backup safety - if I need to wipe my system drive, I want my Claude data to live untouched on a separate drive rather than being lost or needing to be re-downloaded from scratch. A CLAUDE_DATA_DIR

[FEATURE] CLAUDE_DATA_DIR env var or config key to relocate %APPDATA%\Claude\ on Windows

Status Open

Maintainer reply None cached

Workaround ✓ Mentioned in thread ↓

Activity 16 comments · opened May 11, 2026

Preflight Checklist

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

Problem Statement

On Windows, the Claude Code desktop app (Store/MSIX package) stores all user data in %APPDATA%\Claude\. There is no setting, env var, or CLI flag to relocate this to another drive.

The app is installed with the unvirtualizedResources capability, so data writes to real %APPDATA% — not a Store VFS sandbox. This means reinstalling to another drive only moves the 518 MB Electron binary; the 15+ GB of user data stays on C: regardless.

Measured sizes on an active install:

| Path | Size | Growth |
|---|---|---|
| vm_bundles\rootfs.vhdx | 10 GB | ~1 GB per active session day |
| vm_bundles\rootfs.vhdx.zst | 2.2 GB | Static |
| vm_bundles\sessiondata.vhdx | 1.3 GB | Grows with sessions |
| local-agent-mode-sessions\ | 472 MB | Grows with sessions |
| %APPDATA%\Claude\ total | ~15.4 GB | Growing |

rootfs.vhdx is a dynamically-expanding VHDX. On an active development machine it can fill a typical system SSD within weeks.

Proposed Solution

A CLAUDE_DATA_DIR environment variable (or equivalent config key in claude_desktop_config.json) that relocates the entire user data directory:

// claude_desktop_config.json
{
  "dataDir": "D:\\ClaudeData\\Claude"
}

or via environment variable:

CLAUDE_DATA_DIR=D:\ClaudeData\Claude

All subdirectories (vm_bundles\, local-agent-mode-sessions\, claude-code\, etc.) resolve relative to this root. On first launch with the new setting, Claude Code should either migrate data automatically or print clear instructions to move the directory manually.

Alternative Solutions

Exhaustively checked — none work:

CLAUDE_* env vars — none control data location
%APPDATA%\Claude\config.json — UI preferences only (scale, theme, window position)
claude_desktop_config.json — behaviour preferences only
~/.claude/settings.json — hooks and permissions only
App manifest — no userData path override declared
Move-AppxPackage to D: — only moves the 518 MB Electron binary, data stays on C:
Registry keys (like Outlook's ForceOSTPath) — none exist for Claude Code

Current workaround: NTFS directory junction (C:\Users\...\AppData\Roaming\Claude → D:\ClaudeData\Claude). Works but is unsupported, fragile across Windows Updates, and inaccessible to non-technical users.

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

Scenario: Active developer on a 512 GB system SSD (Alienware M15 / similar), running Claude Code daily for geospatial AI development.

Fresh install: %APPDATA%\Claude\ = ~13 GB
After two weeks of active use: rootfs.vhdx grows ~1 GB per session day as the Linux VM accumulates pip/npm packages
With a secondary 521 GB SSD sitting 80% empty, there is no way to redirect this growth without an unsupported NTFS junction hack
With CLAUDE_DATA_DIR=D:\ClaudeData\Claude in config: all VM data, sessions, and cache land on the secondary SSD automatically — C: stays healthy indefinitely

Additional Context

Prior art for this pattern:

VS Code: --user-data-dir CLI flag + code-portable-data/ support
Chromium: --user-data-dir flag
XDG Base Directory spec: XDG_DATA_HOME / XDG_CONFIG_HOME
Microsoft Outlook: ForceOSTPath registry value (REG_EXPAND_SZ) — exact analogue

Related issues:

#25762 — env var for ~/.claude/ config dir (same theme, different path)

Platform: Windows 11, Claude Code desktop (Store/MSIX) v1.6608.2.0, Alienware M15, 410 GB C: SSD

View original on GitHub ↗

16 Comments

AiRE-Geo · 5 months ago

important feature, needed urgently

github-actions[bot] · 5 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

AiRE-Geo · 5 months ago

Thanks for the triage. I reviewed all three flagged issues and this is distinct from each:

#56089 targets %LocalAppData%\...\claudevm.bundle\ (the Cowork VM path). This issue is about %AppData%\Claude\ — the desktop app Electron data directory — a different path containing not just the VM bundle but also local-agent-mode-sessions\, caches, and all persistent app state (~15 GB total, growing ~1 GB/session).

#31284 requests a configurable home directory path for Linux/macOS. This is Windows-specific, concerning the MSIX Store app's %AppData% directory which cannot be relocated by any native mechanism (verified exhaustively: no CLI flag, env var, registry key, or config file controls this path).

#25762 requests an env var for the CLI's ~/.claude/ config dir. This issue is about the desktop app's %AppData%\Claude\ (the Electron userdata folder) — a separate 15 GB data store unaffected by any ~/.claude/ relocation.

The common thread is "Claude writes to a hardcoded path I can't move" but the affected paths, mechanisms, and solutions differ per platform and app mode. Keeping open for the Windows desktop app %AppData%\Claude\ case specifically.

lucasdwi · 4 months ago

+1. Windows 10, 107 GB C: drive at 90% full. %AppData%\Claude\ is 12.6 GB, with vm_bundles\claudevm.bundle\ alone at 12.3 GB (9 GB live rootfs.vhdx + 2.2 GB rootfs.vhdx.zst template, plus initrd/vmlinuz pairs). On smaller system drives this is unworkable.

Confirmed via prior investigation (and consistent with #42119) that NTFS junctions and directory symlinks fail — Node's fs.rename() in the bundle extraction resolves real paths before calling the OS, bypassing reparse points. No native Windows mechanism can relocate this path.

Even just relocating vm_bundles\ (via a CLAUDE_DATA_DIR env var or a field in %AppData%\Claude\config.json read at launch) would solve ~80% of the disk pressure for Windows users on small system drives.

kdober · 4 months ago

I also need an urgent solution for this. C drive is limited and been able to mode this data to my D (data) drive is a must!

lehoaian · 4 months ago

+1, this issue block me, 150GB of C: in working laptop

kofeboy-bebop · 4 months ago

same situation here; c: is small and will stay small.

gretferat · 4 months ago

I have a similar issue. Installed less than a week ago, today C: drive already has 11GB less space available than immediately after install, now at 19% free and counting down, whilst second drive is sitting at 77% free, and the ideal place for Claude to live.

Editing to add detail:

My setup is three SSDs: C: for OS only, Z: for software, X: for storage, with Windows' "new apps save to" set to Z:.

On that configuration, Cowork's workspace failed to provision entirely with a repeating EXDEV: cross-device link not permitted error on the rootfs.vhdx rename, even though both the source temp folder and the destination were in the same directory under C:\Users\<me>\AppData\Roaming\Claude\vm_bundles\. The log showed the app binary was running from Z:\WindowsApps\Claude_...\app.asar while its data lived on C:, so the MSIX sandbox treated a same-folder rename as crossing a device boundary.

The only thing that fixed it (and gave me a workable Cowork) was forcing the app itself back onto C: by setting default install drive to C:, uninstalling, reinstalling. Per the original post, that moves only the Electron binary, as the bulky vm_bundles data was always going to stay on C: regardless, so I've now got a dynamically-expanding VHDX pinned to my OS drive, which is exactly what I built a three-drive layout to avoid.

A CLAUDE_DATA_DIR / config key to relocate the whole user-data directory would have solved both of my problems in one go (the EXDEV failure on multi-drive setups, and the long-term growth of rootfs.vhdx on the system SSD).

So very strong +1 as the former issue I have solved, but the later still remains until this feature request is implemented.

chinmayrane · 4 months ago

+1 on having an ENV VAR that can switch out the vm bundles to SSD and not cause older MS Laptops to not work.

michal78 · 3 months ago

Adding another use case for this: I'd like Claude Desktop's data (vm_bundles, sessions, etc.) off C: for two reasons:

Storage cost - my C: drive is a smaller/pricier SSD, and secondary storage is much cheaper per GB. Having 10+ GB of VM bundle data forced onto C: is a real cost for me.
Reinstall/backup safety - if I need to wipe my system drive, I want my Claude data to live untouched on a separate drive rather than being lost or needing to be re-downloaded from scratch.

A CLAUDE_DATA_DIR config option (or similar) as proposed here would solve both. Junctions are too fragile as a workaround since they can break on updates.

dpsullivan · 2 months ago

+1, this is a genuinely baffling choice that is even more baffling it wasn't caught internally. Lean C for OS critical stuff is a very common setup, and not letting users specifically control where files and data live is just irresponsible application development. Makes the application completely unusable for me and most of my team.

Thoe657 · 1 month ago

Adding a working data point from Windows, in case it helps scope this.

CLI is already solved. CLAUDE_CONFIG_DIR relocates the entire ~/.claude tree including credentials, so two accounts coexist cleanly today — separate settings, skills, plugins, sessions and logins. It just isn't documented as the multi-account mechanism, so people don't find it.

Desktop has no equivalent, and on MSIX builds the data path is undocumented. On Claude desktop 1.40609.0 (Store/MSIX install), user data lives at:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude

%APPDATA%\Claude — the path most third-party guides cite — does not exist on these builds, which sends people down the wrong path when debugging MCP config.

The finding that might matter: a directory junction placed at that location, pointing out of the package container to a normal folder, is followed correctly by the app. Profile switching works today by swapping that link:

%LOCALAPPDATA%\Packages\...\LocalCache\Roaming\Claude   ->  junction
%LOCALAPPDATA%\Claude-profiles\personal                 ->  real data
%LOCALAPPDATA%\Claude-profiles\work                     ->  real data

Verified with a full round trip: switch to profile B, sign in, close, switch back to A, and A's session and history are intact. Keeping profile data outside the container means a package reset destroys the link rather than the data.

That suggests the app doesn't hard-depend on its data being inside the sandbox, so a CLAUDE_DATA_DIR env var — or a native profile picker — looks feasible without deeper changes.

One rough edge worth separating out: plugin caches are per-profile, but enabledPlugins and extraKnownMarketplaces live in settings.json. Copying a settings.json between profiles makes the new profile auto-install plugins it has no cache for, and plugins with hooks then fail in ways that block prompts.

Script and full write-up: https://github.com/Thoe657/claude-multiple-profiles

SirioAstarot · 1 month ago

I have Claude Desktop on my PC and notice it keeps getting bigger—it’s already taking up 10 GB, including the data cache. That doesn't bother me; what is essential for me is that the data cache be located at:
%APPDATA%\Local\Packages\Claude_pzs8sxrjxfjjc

If I have problems with Windows and need to format and reinstall it, I will lose all my Claude data—chats, artifacts, files, and documents.

To address this, I would like you to add an option to change the cache location—for example, to a separate SSD where I store all my open-weight models and other AI-related data—to keep my data safe.

Example:
%APPDATA%\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache --> D:\Claude\LocalCache

I have a 8 TB NVMe SSD to handle all the model and Claude cache data with practically no limits.

weeblr · 26 days ago

Hi,

I also need this, for portability. The usual fix of using a junction to point at another folder does not wrok with claude unfortunately, for reasons outlined in #91409

Rheenabyte · 16 days ago

+1, but I just wanted to add another reason why this fix is needed beyond just running out of C: drive space (though that affects me, too).

My workstation is intentionally split up across different drives for performance. Windows is on a standard SSD, but I offload high-throughput, file-intensive tasks like virtual machines and scratch workspaces to a dedicated, ultra-fast secondary NVMe drive.

Because rootfs.vhdx is a live, active virtual disk, forcing it onto the system drive creates unnecessary bottlenecking and completely bypasses the faster storage available on the secondary drive.

Since Windows HCS blocks mounting VHDX files through mklink directory junctions, there is no clean way to work around this without breaking the app or risking system stability by moving the entire %USERPROFILE%.

A native configuration key in claude_desktop_config.json to change the path would completely solve this for multi-drive setups like mine. It's not too different of a use case, but I figured I'd share since I can't imagine I'm the only one doing it this way.

eladbash · 15 days ago

Hit this a lot on Windows: the Store/MSIX install can sit elsewhere, but %APPDATA%\Claude\ (esp. vm_bundles\rootfs.vhdx + session VHDX) still grows on C: with no supported relocate — junction is the usual workaround.

Useful split while waiting on CLAUDE_DATA_DIR / config relocate:

Must-keep / treat carefully: live rootfs.vhdx / sessiondata.vhdx if Claude is running; anything you still need from local-agent-mode-sessions\.
Often reclaimable with eyes open: stale compressed/static VHDX copies if Claude isn’t using them, old session dirs you don’t need, orphaned agent worktrees/transcripts/local model caches elsewhere on the machine (separate from relocating the data dir).
Risk labels help — don’t blind-delete VHDX or live session state.

I maintain void (local disk reclaim for build artifacts + AI agent data/worktrees/models; Safe/Caution/Danger; nothing deleted without confirmation; Guard for free-space warnings). It can surface agent junk and model caches; it does not relocate Claude’s %APPDATA%\Claude root — that still needs Anthropic’s env/config (or a junction). Happy to dig into which paths on your machine look Safe vs Danger if useful.