›_ Claude Code Issues
Claude Code Issues / #25579

[BUG] Claude Desktop (Windows MSIX) uses wrong userData path — config files and logs are invisible at documented location

Resolved 💬 2 comments Opened Feb 13, 2026 by wolframs Closed Feb 16, 2026

Documentation Type

Missing documentation (feature not documented)

Documentation Location

https://docs.anthropic.com/en/docs/claude-desktop/mcp-servers

Section/Topic

MCP Server Configuration — Windows config file location (%APPDATA%\Claude\claude_desktop_config.json)

Current Documentation

<html>
<body>
<!--StartFragment--><html><head></head><body><h1>[BUG] Claude Desktop (Windows MSIX) uses wrong <code>userData</code> path — config files and logs are invisible at documented location</h1>
<h2>Summary</h2>
<p>Claude Desktop on Windows is distributed as an MSIX package. MSIX virtualization silently redirects Electron's <code>app.getPath("userData")</code> from the documented <code>%APPDATA%\Claude\</code> to a package-containerized path. <strong>All official documentation points to the wrong location</strong>, making MCP configuration, debugging, and extension troubleshooting effectively impossible for Windows users.</p>
<h2>Documented path (WRONG — app cannot see files here)</h2>
<pre><code>%APPDATA%\Claude\claude_desktop_config.json
→ C:\Users\&lt;user&gt;\AppData\Roaming\Claude\claude_desktop_config.json
</code></pre>
<h2>Actual path (CORRECT — where the app reads/writes)</h2>
<pre><code>%LOCALAPPDATA%\Packages\Claude_&lt;hash&gt;\LocalCache\Roaming\Claude\claude_desktop_config.json
→ C:\Users\&lt;user&gt;\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json
</code></pre>
<p>The package hash <code>pzs8sxrjxfjjc</code> appears to be consistent across installations but may vary.</p>
<h2>Impact</h2>
<p>This affects <strong>everything</strong> that depends on <code>userData</code>:</p>

What | Documented location (wrong) | Actual location
-- | -- | --
claude_desktop_config.json | %APPDATA%\Claude\ | ...\Packages\Claude_<hash>\LocalCache\Roaming\Claude\
developer_settings.json | %APPDATA%\Claude\ | same
Claude Extensions\ folder | %APPDATA%\Claude\Claude Extensions\ | same
MCP logs (logs\mcp.log, etc.) | %APPDATA%\Claude\logs\ | same
extensions-installations.json | %APPDATA%\Claude\ | same

<p><strong>Consequences:</strong></p>
<ul>
<li>Users create <code>claude_desktop_config.json</code> with <code>mcpServers</code> at the documented path → app never reads it → MCP servers silently don't load</li>
<li>Users look for logs at the documented path → nothing there → debugging is impossible</li>
<li>Users check <code>Claude Extensions\</code> at the documented path → folder is empty → extensions appear broken/uninstalled</li>
<li><code>developer_settings.json</code> placed at the documented path has no effect</li>
</ul>
<h2>Steps to reproduce</h2>
<ol>
<li>Install Claude Desktop from the Microsoft Store (MSIX package, version 1.1.2685 or similar)</li>
<li>Create <code>%APPDATA%\Claude\claude_desktop_config.json</code> with an <code>mcpServers</code> entry, as described in official docs</li>
<li>Restart Claude Desktop</li>
<li>Observe: MCP servers do not appear / do not connect</li>
<li>Check the MSIX-virtualized path instead:
<pre><code class="language-powershell">Get-ChildItem "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json"
</code></pre></li>
<li>Observe: the app's actual config file is here (without your <code>mcpServers</code> entry)</li>
</ol>
<h2>Root cause</h2>
<p>The source code (extracted from <code>app.asar</code>, version 1.1.2685) uses Electron's standard <code>app.getPath("userData")</code>:</p>
<pre><code class="language-javascript">// From .vite/build/index.js, line 300
function $k(){return Pe.join(Te.app.getPath("userData"),"Claude Extensions")}
</code></pre>
<p>On a standard (non-MSIX) Electron install, <code>userData</code> resolves to <code>%APPDATA%\Claude\</code>. But MSIX packaging applies <a href="https://learn.microsoft.com/en-us/windows/msix/desktop/flexible-virtualization">filesystem virtualization</a>, which transparently redirects this to <code>%LOCALAPPDATA%\Packages\&lt;PackageFamilyName&gt;\LocalCache\Roaming\Claude\</code>.</p>
<p>The app works correctly internally (it reads/writes to the virtualized path just fine). The problem is purely that <strong>all user-facing documentation and community guidance references the non-virtualized path</strong>, which is unreachable from within the MSIX sandbox.</p>
<h2>Environment</h2>
<ul>
<li><strong>Claude Desktop</strong>: 1.1.2685 (MSIX package <code>Claude_1.1.2685.0_x64__pzs8sxrjxfjjc</code>)</li>
<li><strong>OS</strong>: Windows 11 (Build 26200)</li>
<li><strong>Install source</strong>: Microsoft Store / MSIX</li>
</ul>
<h2>Suggested fixes</h2>
<p><strong>Option A (Documentation fix — minimum viable):</strong>
Update all Windows documentation to reference the correct MSIX path, or provide a PowerShell one-liner to find it:</p>
<pre><code class="language-powershell"># Find the real Claude Desktop userData path
$claudePkg = Get-ChildItem "$env:LOCALAPPDATA\Packages\Claude_*" -Directory | Select-Object -First 1
Write-Host "$($claudePkg.FullName)\LocalCache\Roaming\Claude\"
</code></pre>
<p><strong>Option B (App fix — better UX):</strong>
Add a menu item or CLI command that reveals the actual config directory (e.g., "Open Config Folder" in Help menu), so users don't need to guess.</p>
<p><strong>Option C (App fix — best):</strong>
On MSIX installations, detect that <code>userData</code> is virtualized and either:</p>
<ul>
<li>Create a symlink or junction at <code>%APPDATA%\Claude\</code> pointing to the real location, or</li>
<li>Also check <code>%APPDATA%\Claude\claude_desktop_config.json</code> as a fallback config source, or</li>
<li>Log the actual <code>userData</code> path at startup in a discoverable location</li>
</ul>
<h2>Related issues</h2>
<p>This path confusion is likely the root cause (or a major contributor) for many Windows MCP issues:</p>
<ul>
<li>#4793 — MCP servers "Failed to connect" on Windows 11</li>
<li>#6682 — MCP connection fails from different drive on Windows</li>
<li>#4976 — Config file confusion between CLI and Desktop</li>
<li>#4097 — MCP server disconnects immediately</li>
<li>#5749 — Permission system broken (possibly unrelated but filed by frustrated Windows users)</li>
</ul>
<h2>Additional context</h2>
<p>MSIX filesystem virtualization is documented by Microsoft here: https://learn.microsoft.com/en-us/windows/msix/desktop/flexible-virtualization</p>
<p>The <code>%APPDATA%\Claude\</code> directory <em>does</em> get created on the real filesystem (possibly by the MSIX installer or by Windows' VFS merging), which is especially misleading — users see the folder exists and assume it's the right place, but the app's process running inside the MSIX container cannot see files placed there by the user.</p></body></html><!--EndFragment-->
</body>
</html># [BUG] Claude Desktop (Windows MSIX) uses wrong userData path — config files and logs are invisible at documented location

Summary

Claude Desktop on Windows is distributed as an MSIX package. MSIX virtualization silently redirects Electron's app.getPath("userData") from the documented %APPDATA%\Claude\ to a package-containerized path. All official documentation points to the wrong location, making MCP configuration, debugging, and extension troubleshooting effectively impossible for Windows users.

Documented path (WRONG — app cannot see files here)

%APPDATA%\Claude\claude_desktop_config.json
→ C:\Users\<user>\AppData\Roaming\Claude\claude_desktop_config.json

Actual path (CORRECT — where the app reads/writes)

%LOCALAPPDATA%\Packages\Claude_<hash>\LocalCache\Roaming\Claude\claude_desktop_config.json
→ C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json

The package hash pzs8sxrjxfjjc appears to be consistent across installations but may vary.

Impact

This affects everything that depends on userData:

| What | Documented location (wrong) | Actual location |
|---|---|---|
| claude_desktop_config.json | %APPDATA%\Claude\ | ...\Packages\Claude_<hash>\LocalCache\Roaming\Claude\ |
| developer_settings.json | %APPDATA%\Claude\ | same |
| Claude Extensions\ folder | %APPDATA%\Claude\Claude Extensions\ | same |
| MCP logs (logs\mcp.log, etc.) | %APPDATA%\Claude\logs\ | same |
| extensions-installations.json | %APPDATA%\Claude\ | same |

Consequences:

  • Users create claude_desktop_config.json with mcpServers at the documented path → app never reads it → MCP servers silently don't load
  • Users look for logs at the documented path → nothing there → debugging is impossible
  • Users check Claude Extensions\ at the documented path → folder is empty → extensions appear broken/uninstalled
  • developer_settings.json placed at the documented path has no effect

Steps to reproduce

  1. Install Claude Desktop from the Microsoft Store (MSIX package, version 1.1.2685 or similar)
  2. Create %APPDATA%\Claude\claude_desktop_config.json with an mcpServers entry, as described in official docs
  3. Restart Claude Desktop
  4. Observe: MCP servers do not appear / do not connect
  5. Check the MSIX-virtualized path instead:

``powershell
Get-ChildItem "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json"
``

  1. Observe: the app's actual config file is here (without your mcpServers entry)

Root cause

The source code (extracted from app.asar, version 1.1.2685) uses Electron's standard app.getPath("userData"):

// From .vite/build/index.js, line 300
function $k(){return Pe.join(Te.app.getPath("userData"),"Claude Extensions")}

On a standard (non-MSIX) Electron install, userData resolves to %APPDATA%\Claude\. But MSIX packaging applies [filesystem virtualization](https://learn.microsoft.com/en-us/windows/msix/desktop/flexible-virtualization), which transparently redirects this to %LOCALAPPDATA%\Packages\<PackageFamilyName>\LocalCache\Roaming\Claude\.

The app works correctly internally (it reads/writes to the virtualized path just fine). The problem is purely that all user-facing documentation and community guidance references the non-virtualized path, which is unreachable from within the MSIX sandbox.

Environment

  • Claude Desktop: 1.1.2685 (MSIX package Claude_1.1.2685.0_x64__pzs8sxrjxfjjc)
  • OS: Windows 11 (Build 26200)
  • Install source: Microsoft Store / MSIX

What's Wrong or Missing?

What | Documented location (wrong) | Actual location
-- | -- | --
claude_desktop_config.json | %APPDATA%\Claude\ | ...\Packages\Claude_<hash>\LocalCache\Roaming\Claude\
developer_settings.json | %APPDATA%\Claude\ | same
Claude Extensions\ folder | %APPDATA%\Claude\Claude Extensions\ | same
MCP logs (logs\mcp.log, etc.) | %APPDATA%\Claude\logs\ | same
extensions-installations.json | %APPDATA%\Claude\ | same

Suggested Improvement

Option A (Documentation fix — minimum viable):
Update all Windows documentation to reference the correct MSIX path, or provide a PowerShell one-liner to find it:

# Find the real Claude Desktop userData path
$claudePkg = Get-ChildItem "$env:LOCALAPPDATA\Packages\Claude_*" -Directory | Select-Object -First 1
Write-Host "$($claudePkg.FullName)\LocalCache\Roaming\Claude\"

Option B (App fix — better UX):
Add a menu item or CLI command that reveals the actual config directory (e.g., "Open Config Folder" in Help menu), so users don't need to guess.

Option C (App fix — best):
On MSIX installations, detect that userData is virtualized and either:

  • Create a symlink or junction at %APPDATA%\Claude\ pointing to the real location, or
  • Also check %APPDATA%\Claude\claude_desktop_config.json as a fallback config source, or
  • Log the actual userData path at startup in a discoverable location

Related issues

This path confusion is likely the root cause (or a major contributor) for many Windows MCP issues:

  • #4793 — MCP servers "Failed to connect" on Windows 11
  • #6682 — MCP connection fails from different drive on Windows
  • #4976 — Config file confusion between CLI and Desktop
  • #4097 — MCP server disconnects immediately
  • #5749 — Permission system broken (possibly unrelated but filed by frustrated Windows users)

Impact

High - Prevents users from using a feature

Additional Context

MSIX filesystem virtualization is documented by Microsoft here: https://learn.microsoft.com/en-us/windows/msix/desktop/flexible-virtualization

The %APPDATA%\Claude\ directory does get created on the real filesystem (possibly by the MSIX installer or by Windows' VFS merging), which is especially misleading — users see the folder exists and assume it's the right place, but the app's process running inside the MSIX container cannot see files placed there by the user.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗