[BUG] Windows MSIX: "Edit Config" opens wrong claude_desktop_config.json — MCP servers silently fail to load
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:
- 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.
- 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
- Install Claude Desktop on Windows from claude.ai/download (results in MSIX installation)
- Open Claude Desktop → Settings → Developer → click "Edit Config"
- 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"]
}
}
}
- Save the file and restart Claude Desktop (or use Developer → Reload MCP Configuration)
- 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:
- Make "Edit Config" open the correct file — before calling
shell.openPath(), resolve the actual virtualized path the app reads from (e.g., usingprocess.env.LOCALAPPDATA + '\Packages\...'or WindowsGetPackagePathAPIs) so the editor opens the same file the app uses - 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 - Add logging/diagnostics — surface a warning in Developer settings when the config file has no
mcpServerskey or when MCP server startup fails. Generate logs even when no MCP servers are configured, so users have something to debug with - 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:
- 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.
- 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:
- Make "Edit Config" open the correct file — before calling
shell.openPath(), resolve the actual virtualized path the app reads from (e.g., usingprocess.env.LOCALAPPDATA + '\Packages\...'or WindowsGetPackagePathAPIs) so the editor opens the same file the app uses - 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 - Add logging/diagnostics — surface a warning in Developer settings when the config file has no
mcpServerskey or when MCP server startup fails. Generate logs even when no MCP servers are configured, so users have something to debug with - 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
- Install Claude Desktop on Windows from claude.ai/download (results in MSIX installation)
- Open Claude Desktop → Settings → Developer → click "Edit Config"
- 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"]
}
}
}
- Save the file and restart Claude Desktop (or use Developer → Reload MCP Configuration)
- 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_
19 Comments
Found 2 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is the same reason files won't render (like powerpoints), and you can't download files directly in the client - huge issue
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.
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.
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.
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.
I was able to get it to work. I considered creating a symlink, but instead I uninstalled, manually created
%APPDATA%\Claudeand 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.
and they charge 90 euros for a bs that you need to fix by yourself ? what a joke
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!
This worked, phew.
No, they need to resolve the path correctly by using the right api.
GetPackagePathinstead ofShGetKnownFolderPathor 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...@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 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.
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.
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!!!!
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:
%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json%APPDATA%\Claude\claude_desktop_config.jsonmcpServersinto the file Claude actually reads instead of replacing existing preferences.%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.
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:
%APPDATA%\Claude%LOCALAPPDATA%\Claude-3pclaude_desktop_config.json.After that, everything worked correctly.
<br/>
Troubleshooting
If you can't see "Local MCP servers" in Claude Desktop on 3P:
After enabling Developer Mode, the Local MCP servers section should appear.
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:
AppData\Roaming\Claude\claude_desktop_config.jsonand saw one version of the file (with onlybacklog-nulabentry)backlogentry still present)fsutil file queryFileIDconfirmed different physical file IDs for the same path:0x0000000000000000002800000004c3b60x000000000000000000c800000004d3bfRoot cause confirmed
Claude Code (also installed as MSIX via WinGet:
Anthropic.ClaudeCode_Microsoft.Winget.Source_8wekyb3d8bbwe) accesses the real file at:The user's PowerShell (running outside MSIX context) reads the old virtualized copy at:
Impact
Workaround (for now)
Access the real config file directly:
Suggested fix
Environment: Windows 11 Pro 10.0.26200, Claude Code installed via WinGet (MSIX)