[BUG] Windows MSIX: "Edit Config" opens wrong claude_desktop_config.json — MCP servers silently fail to load

Open 💬 19 comments Opened Feb 16, 2026 by 0xc4b4l

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Summary

On Windows, Claude Desktop installed via the official installer (claude.ai/download) uses MSIX packaging. The app's "Edit Config" button in Developer settings opens a config file at %APPDATA%\Claude\claude_desktop_config.json, but the app actually reads from a different location inside the MSIX virtualized filesystem. This causes MCP server configurations to be silently ignored with no error messages, no logs, and no indication that anything is wrong.

Environment

  • OS: Windows 11 Pro (latest version, Build 26100)
  • Claude Desktop version: 1.1.3189.0 (MSIX package: Claude_pzs8sxrjxfjjc)
  • Installation method: Downloaded from claude.ai/download (standard installer)
  • Hyper-V: Enabled
  • Intel Virtualization (VT-x): Enabled
  • Node.js: v24.13.1 (installed via vfox version manager)
  • npm/npx: v11.8.0

Installation Details

The app installs as an MSIX package at:

C:\Program Files\WindowsApps\Claude_1.1.3189.0_x64__pzs8sxrjxfjjc\app\Claude.exe

Note: A second package also exists at Anthropic.ClaudeDesktop_h6f0761 which may be related to the confusion.

Root Cause

This is an Electron + MSIX filesystem virtualization issue.

MSIX apps on Windows run inside a lightweight container with a virtualized filesystem. When the Claude Desktop app (running inside the MSIX container) accesses %APPDATA%\Claude\, Windows silently redirects that read/write to the virtualized path:

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

However, the "Edit Config" button likely uses an Electron API like shell.openPath() or shell.openExternal() to launch the user's text editor. This API call resolves to the real, non-virtualized %APPDATA%\Claude\ path — bypassing the MSIX redirection.

The result: the app reads from the virtualized path, but tells the user to edit a completely different file at the real path. These are two separate files on disk that are never synchronized.

Bug Description

The Problem

There are two claude_desktop_config.json files on the system:

  1. The file "Edit Config" opens (the wrong one):

``
C:\Users\<username>\AppData\Roaming\Claude\claude_desktop_config.json
``

→ This is the standard %APPDATA%\Claude\ path referenced in all official documentation.

  1. The file the app actually reads (the correct one):

``
C:\Users\<username>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json
``

→ This is the MSIX virtualized filesystem path.

When a user adds MCP server configuration to file #1 (as instructed by the UI and documentation), the app reads file #2 and finds no MCP servers configured. The MCP servers never start.

What Makes This Hard to Debug

  • No error messages are displayed in the app
  • No logs folder is created at %APPDATA%\Claude\logs\ (because the app isn't reading from there)
  • The logs folder exists in the virtualized path but users don't know to look there
  • Developer settings show no indication that the config was not loaded
  • "Edit Config" button confidently opens the wrong file, leading users to believe they're editing the right config
  • All official documentation references %APPDATA%\Claude\ as the config location

Steps to Reproduce

  1. Install Claude Desktop on Windows from claude.ai/download (results in MSIX installation)
  1. Open Claude Desktop → Settings → Developer → click "Edit Config"
  1. Add any MCP server configuration to the file that opens, for example:

``json
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "C:\\Users\\username\\Desktop"]
}
}
}
``

  1. Save the file and restart Claude Desktop (or use Developer → Reload MCP Configuration)
  1. Observe: No MCP server icon appears, no tools are listed, no logs are generated

Expected Behavior

  • "Edit Config" should open the config file that the app actually reads
  • OR the app should read from the standard %APPDATA%\Claude\ path
  • OR at minimum, the app should display a warning/log when no MCP servers are found despite a config file existing in the standard location
  • Documentation should reference the correct path for MSIX installations

Actual Behavior

  • "Edit Config" opens a file the app does not read
  • MCP servers silently fail to load
  • No errors, no warnings, no logs at the expected location
  • Users can spend hours troubleshooting (verifying JSON syntax, testing Node.js, checking paths) without finding the issue

Workaround

Edit the config file at the MSIX virtualized path directly:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json

Note: This file already contains app preferences (e.g., coworkScheduledTasksEnabled, sidebarMode), so MCP config must be merged into the existing JSON structure:

{
  "preferences": {
    "coworkScheduledTasksEnabled": false,
    "sidebarMode": "chat"
  },
  "mcpServers": {
    "your-server": {
      "command": "...",
      "args": ["..."]
    }
  }
}

Alternatively, create a symbolic link from the virtualized path to the standard path (requires admin privileges).

Impact

This affects all Windows users who install Claude Desktop via the official installer (which now defaults to MSIX packaging). Any user following the official MCP setup documentation will hit this issue. The silent failure with no error messages makes it extremely difficult to diagnose without deep knowledge of Windows MSIX filesystem virtualization.

Suggested Fix

One or more of the following:

  1. Make "Edit Config" open the correct file — before calling shell.openPath(), resolve the actual virtualized path the app reads from (e.g., using process.env.LOCALAPPDATA + '\Packages\...' or Windows GetPackagePath APIs) so the editor opens the same file the app uses
  2. Read from the non-virtualized path explicitly — bypass MSIX redirection by using the real %APPDATA%\Claude\ path with full filesystem APIs, ensuring the app and "Edit Config" both use the same file
  3. Add logging/diagnostics — surface a warning in Developer settings when the config file has no mcpServers key or when MCP server startup fails. Generate logs even when no MCP servers are configured, so users have something to debug with
  4. Update documentation — mention the MSIX virtualized path for Windows users and note that "Edit Config" may open the wrong file on MSIX installations

What Should Happen?

Bug Description

The Problem

There are two claude_desktop_config.json files on the system:

  1. The file "Edit Config" opens (the wrong one):

``
C:\Users\<username>\AppData\Roaming\Claude\claude_desktop_config.json
``

→ This is the standard %APPDATA%\Claude\ path referenced in all official documentation.

  1. The file the app actually reads (the correct one):

``
C:\Users\<username>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json
``

→ This is the MSIX virtualized filesystem path.

When a user adds MCP server configuration to file #1 (as instructed by the UI and documentation), the app reads file #2 and finds no MCP servers configured. The MCP servers never start.

What Makes This Hard to Debug

  • No error messages are displayed in the app
  • No logs folder is created at %APPDATA%\Claude\logs\ (because the app isn't reading from there)
  • The logs folder exists in the virtualized path but users don't know to look there
  • Developer settings show no indication that the config was not loaded
  • "Edit Config" button confidently opens the wrong file, leading users to believe they're editing the right config
  • All official documentation references %APPDATA%\Claude\ as the config location

Actual Behavior

  • "Edit Config" opens a file the app does not read
  • MCP servers silently fail to load
  • No errors, no warnings, no logs at the expected location
  • Users can spend hours troubleshooting (verifying JSON syntax, testing Node.js, checking paths) without finding the issue

Workaround

Edit the config file at the MSIX virtualized path directly:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json

Note: This file already contains app preferences (e.g., coworkScheduledTasksEnabled, sidebarMode), so MCP config must be merged into the existing JSON structure:

{
  "preferences": {
    "coworkScheduledTasksEnabled": false,
    "sidebarMode": "chat"
  },
  "mcpServers": {
    "your-server": {
      "command": "...",
      "args": ["..."]
    }
  }
}

Alternatively, create a symbolic link from the virtualized path to the standard path (requires admin privileges).

Impact

This affects all Windows users who install Claude Desktop via the official installer (which now defaults to MSIX packaging). Any user following the official MCP setup documentation will hit this issue. The silent failure with no error messages makes it extremely difficult to diagnose without deep knowledge of Windows MSIX filesystem virtualization.

Suggested Fix

One or more of the following:

  1. Make "Edit Config" open the correct file — before calling shell.openPath(), resolve the actual virtualized path the app reads from (e.g., using process.env.LOCALAPPDATA + '\Packages\...' or Windows GetPackagePath APIs) so the editor opens the same file the app uses
  2. Read from the non-virtualized path explicitly — bypass MSIX redirection by using the real %APPDATA%\Claude\ path with full filesystem APIs, ensuring the app and "Edit Config" both use the same file
  3. Add logging/diagnostics — surface a warning in Developer settings when the config file has no mcpServers key or when MCP server startup fails. Generate logs even when no MCP servers are configured, so users have something to debug with
  4. Update documentation — mention the MSIX virtualized path for Windows users and note that "Edit Config" may open the wrong file on MSIX installations

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce

  1. Install Claude Desktop on Windows from claude.ai/download (results in MSIX installation)
  1. Open Claude Desktop → Settings → Developer → click "Edit Config"
  1. Add any MCP server configuration to the file that opens, for example:

``json
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "C:\\Users\\username\\Desktop"]
}
}
}
``

  1. Save the file and restart Claude Desktop (or use Developer → Reload MCP Configuration)
  1. Observe: No MCP server icon appears, no tools are listed, no logs are generated

Expected Behavior

  • "Edit Config" should open the config file that the app actually reads
  • OR the app should read from the standard %APPDATA%\Claude\ path
  • OR at minimum, the app should display a warning/log when no MCP servers are found despite a config file existing in the standard location
  • Documentation should reference the correct path for MSIX installations

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Desktop

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_

View original on GitHub ↗

19 Comments

github-actions[bot] · 5 months ago

Found 2 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/25579
  2. https://github.com/anthropics/claude-code/issues/25600

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

jphillips59-wq · 4 months ago

This is the same reason files won't render (like powerpoints), and you can't download files directly in the client - huge issue

peternoyes · 4 months ago

The fix for this needs to be that Claude reads the stable documented config path of C:\Users\%APPDATA%\Claude. This fix isn't directly related to the switch to MSIX.

It is working in Claude 1.1.2998 (1f1d4d) 2026-02-12T20:50:41.000Z which is an MSIX build.
It is broken in Claude
1.1.3647** (8f7c53) 2026-02-19T15:02:19.000Z

UPDATE: It looks like the above may not be the case. It depends if the computer previously had a non-MSIX version of Claude. This issue appears to only affect fresh installs of Claude based on my latest testing.

It would be unreasonable to expect users to manage config paths that exist in a privileged virtualized filesystem that changes every version.

Also: Please do not close this bug. Yes, this is not Claude Code, but there is no other public repository for Claude Desktop where we can raise issues like this. This particular issue is a showstopper for an upcoming product release of ours and I am trying any and all channels to get in touch with Anthropic to get this addressed.

Seym0n · 4 months ago

Already noted this issue here: https://www.reddit.com/r/ClaudeAI/comments/1r1wflq/claude_mcp_windows_app/

What's working are MCPB (former DXT) extensions, but that means sacrifing all the established community mcps that depend on the config json file unfortunately.

tosandip · 4 months ago

I ran into the exact same issue and was struggling this past weekend because cannot find logs for local mcp servers I am trying to run

Now knowing the exact file it is looking it, updated that JSON file and things started working.

mikempw · 4 months ago

Plagued by this error. No amount of modification to the .json file works. It's not in the users\appdata as suggested. Can we get a quick build on this? Shouldn't be difficult to fix folder paths.

kimmydotzip · 4 months ago

I was able to get it to work. I considered creating a symlink, but instead I uninstalled, manually created %APPDATA%\Claude and reinstalled. It treated that as an existing install and used that folder instead of the virtual file system in %LOCALAPPDATA%\Packages\. Seems to be running without issues now.

nico-ezbi · 4 months ago
I was able to get it to work. I considered creating a symlink, but instead I uninstalled, manually created %APPDATA%\Claude and reinstalled. It treated that as an existing install and used that folder instead of the virtual file system in %LOCALAPPDATA%\Packages\. Seems to be running without issues now.

This worked for me.

iloveShaders · 4 months ago

and they charge 90 euros for a bs that you need to fix by yourself ? what a joke

jokorntheuer · 4 months ago

holy crap!!! just tried to find the cause with claude desktop app by myself. i thought i get crazy!! please fix this!! this bug is severe for users!

jogeshpi03 · 4 months ago
I was able to get it to work. I considered creating a symlink, but instead I uninstalled, manually created %APPDATA%\Claude and reinstalled. It treated that as an existing install and used that folder instead of the virtual file system in %LOCALAPPDATA%\Packages\. Seems to be running without issues now.

This worked, phew.

jessica0f0116 · 4 months ago
The fix for this needs to be that Claude reads the stable documented config path of C:\Users%APPDATA%\Claude. This fix isn't directly related to the switch to MSIX. It is working in Claude 1.1.2998 (1f1d4d) 2026-02-12T20:50:41.000Z which is an MSIX build. It is broken in Claude 1.1.3647** (8f7c53) 2026-02-19T15:02:19.000Z UPDATE: It looks like the above may not be the case. It depends if the computer previously had a non-MSIX version of Claude. This issue appears to only affect fresh installs of Claude based on my latest testing. It would be unreasonable to expect users to manage config paths that exist in a privileged virtualized filesystem that changes every version. Also: Please do not close this bug. Yes, this is not Claude Code, but there is no other public repository for Claude Desktop where we can raise issues like this. This particular issue is a showstopper for an upcoming product release of ours and I am trying any and all channels to get in touch with Anthropic to get this addressed.

No, they need to resolve the path correctly by using the right api. GetPackagePath instead of ShGetKnownFolderPath or whatever it's using. Or changing how they read from the environment. MSIX do not use the roaming profile path as mentioned by the person who opened this issue, and they also mentioned the correct resolution...

peternoyes · 4 months ago

@jessica0f0116

The correct solution is to use ShGetKnownFolderPath with the flag KF_FLAG_NO_PACKAGE_REDIRECTION so that it no longer uses the virtualized path.

The current behavior is a mess:

  • The 'Edit Config' button seemingly uses KF_FLAG_NO_PACKAGE_REDIRECTION because it points to the real APP_DATA folder.
  • Installation of Claude Desktop that previously had the old style of the app are grandfathered in somehow and are using the real APP_DATA folder
  • Brand new installations of Claude Desktop on a fresh machine read from the virtualized path, seemingly without KF_FLAG_NO_PACKAGE_REDIRECTION.

The behaviors are inconsistent across the application. They should go back to the documented config file location that is not virtualized.

jessica0f0116 · 4 months ago
@jessica0f0116 The correct solution is to use ShGetKnownFolderPath with the flag KF_FLAG_NO_PACKAGE_REDIRECTION so that it no longer uses the virtualized path. The current behavior is a mess: The 'Edit Config' button seemingly uses KF_FLAG_NO_PACKAGE_REDIRECTION because it points to the real APP_DATA folder. Installation of Claude Desktop that previously had the old style of the app are grandfathered in somehow and are using the real APP_DATA folder * Brand new installations of Claude Desktop on a fresh machine read from the virtualized path, seemingly without KF_FLAG_NO_PACKAGE_REDIRECTION. The behaviors are inconsistent across the application. They should go back to the documented config file location that is not virtualized.

No, indeed. Should stick to virtualization. Even if notepad.exe or whatever is opening non-virtualized path, Claude app still uses virtualized path (under %LOCALAPPDATA%). If they want to disable fs write virtualization the "correct" way to do so would be to modify the application manifest (but not recommended). I'm sure they will get around to fixing it one day though.

mikempw · 4 months ago

Maybe someone can help. On my windows machine, I created both the appdata/roaming/claude folder. Also at the same time created appdata/claude folder just in case. Now, Claude installs fine, but the MCP json settings, if anything is added, Claude immediately fails to launch. MacOS is fine.

kaokula · 4 months ago

Terrible mistakes, I can't believe a world no.1 AI coding model has such stupid issue. And we pay god damn monthly subs on it!!!!

kayalopez · 1 month ago

For anyone landing here from "valid JSON, no MCP icon/tools": the lowest-risk first step is to confirm which config file Claude Desktop is actually reading before rewriting server config.

Quick path checklist:

  • MSIX / Store-style install path to check:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json

  • Standard Windows path that "Edit Config" may open:

%APPDATA%\Claude\claude_desktop_config.json

  • If both exist, back up both files and merge mcpServers into the file Claude actually reads instead of replacing existing preferences.
  • After restart, check the virtualized logs path too, not only %APPDATA%\Claude\logs.

I also put this into a small client-side checklist page here:
https://ai-launch-risk-check-public.vercel.app/claude-mcp-config-path.html

It does not ask for config contents or make network requests from the page; it is just a path/symptom checklist so people do not paste private config or credentials into public issue threads.

sekedus · 1 month ago

Same issue here.

The confusing part is that the official MCP docs say the config is under %APPDATA%\Claude.

However, on my Windows installation, Claude Desktop → Settings → Developer → Edit Config points to %LOCALAPPDATA%\Claude-3p.

This seems to be because I’m running Claude Desktop in 3P (third-party) mode, which uses a different config path.

My workaround was:

  1. Uninstall Claude Desktop (if installed).
  2. Manually create the config folder if it doesn't exist:
  • Claude Desktop Standard: %APPDATA%\Claude
  • Claude Desktop 3P: %LOCALAPPDATA%\Claude-3p
  1. Reinstall Claude Desktop (MSIX) – the installer will use the folder you created.
  2. Open Settings → Developer → Edit Config and add your MCP servers to claude_desktop_config.json.
  3. Restart Claude Desktop.

After that, everything worked correctly.

<br/>

Troubleshooting

If you can't see "Local MCP servers" in Claude Desktop on 3P:

  1. Update Claude Desktop and restart it.
  2. Enable Developer Mode via Help → Troubleshooting → Enable Developer Mode.
  3. Restart Claude Desktop again.

After enabling Developer Mode, the Local MCP servers section should appear.

jmdc-yyasuda · 12 days ago

Additional real-world impact: Claude Code reads different file than user's PowerShell

Reporting a concrete case where this MSIX VFS issue caused significant confusion during a Claude Code session.

What happened

A user spent nearly a full day troubleshooting a Backlog MCP server 401 error. During the session:

  1. Claude Code's file tools read AppData\Roaming\Claude\claude_desktop_config.json and saw one version of the file (with only backlog-nulab entry)
  2. The user opened the same path in PowerShell and saw a completely different version (with an old backlog entry still present)
  3. fsutil file queryFileID confirmed different physical file IDs for the same path:
  • Claude Code process: 0x0000000000000000002800000004c3b6
  • User's PowerShell: 0x000000000000000000c800000004d3bf

Root cause confirmed

Claude Code (also installed as MSIX via WinGet: Anthropic.ClaudeCode_Microsoft.Winget.Source_8wekyb3d8bbwe) accesses the real file at:

C:\Users\<username>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json

The user's PowerShell (running outside MSIX context) reads the old virtualized copy at:

C:\Users\<username>\AppData\Roaming\Claude\claude_desktop_config.json

Impact

  • When Claude Code edits the config file, changes are invisible to the user in PowerShell/Explorer
  • When the user edits the config file directly, Claude Code cannot see the changes
  • This creates a fundamental disconnect between the AI assistant and the user — both believe they are looking at the same file, but they are not
  • Hours of debugging are wasted chasing a phantom discrepancy

Workaround (for now)

Access the real config file directly:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json

Suggested fix

  • Claude Code's file tools should detect and warn when accessing paths affected by MSIX VFS redirection
  • Documentation should explicitly state the real config path for MSIX installations

Environment: Windows 11 Pro 10.0.26200, Claude Code installed via WinGet (MSIX)