### 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 11 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 ↗

11 Comments

AiRE-Geo · 3 months ago

important feature, needed urgently

github-actions[bot] · 3 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 · 3 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 · 3 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 · 3 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 · 2 months ago

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

kofeboy-bebop · 2 months ago

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

gretferat · 2 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 · 2 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 · 1 month 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 · 1 month 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.