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

[0xc4b4l]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• 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.

2. 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)

2. Open Claude Desktop → Settings → Developer → click "Edit Config"

3. Add any MCP server configuration to the file that opens, for example:

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

4. Save the file and restart Claude Desktop (or use Developer → Reload MCP Configuration)

5. 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.

2. 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)

2. Open Claude Desktop → Settings → Developer → click "Edit Config"

3. Add any MCP server configuration to the file that opens, for example:

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

4. Save the file and restart Claude Desktop (or use Developer → Reload MCP Configuration)

5. 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

[github-actions]

Found 2 possible duplicate issues:

1. [BUG] Claude Desktop (Windows MSIX) uses wrong userData path — config files and logs are invisible at documented location #25579
2. Local MCP servers silently ignored when Claude Desktop installed from Microsoft Store #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]

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

[peternoyes]

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]

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.