[BUG] Claude Desktop auto-update creates silent MCP extension conflict — tools show as enabled but are non-functional (Windows, v1.1.5368)

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?

Environment

App Version: 1.1.5368 (upgraded from 1.1.4498)
Platform: Windows 10 (win32 x64)
OS Version: 10.0.26200
CPU: AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx
RAM: ~14GB
Node: 24.13.0

What's Wrong?
After Claude Desktop auto-updated from v1.1.4498 to v1.1.5368, all local MCP tools became invisible and non-functional in Chat mode. The connectors UI shows extensions as enabled (blue toggle on), but no hammer/tools icon appears and Claude cannot access any local MCP servers. Moreover, Claude cant even recognise that its chatting in the desktop app, and insists the conversation, and therefore the mcp fearures assotiated with any requests are unavailable because it thinks its in a browser chat.
The root cause is a silent conflict between the legacy manual mcpServers configuration in claude_desktop_config.json and the new desktop extension management system introduced in recent updates.
This affects every user who set up MCP servers using the previously documented method (hand-editing the JSON config file) and then received an auto-update that introduced the extension-based management system. There is no warning, no error message in the UI, and no visual indication that the app is in a degraded state.
Steps to Reproduce

Have Claude Desktop running with manually configured MCP servers in claude_desktop_config.json (the method documented throughout 2025):

json{
"mcpServers": {
"filesystem": {
"command": "cmd",
"args": ["/c", "npx", "-y", "@modelcontextprotocol/server-filesystem", "D:\\path\\to\\directory"]
}
}
}

Allow auto-update to v1.1.5368 (or any version with the new extension system)
The update automatically installs extension-based versions of servers (e.g., Filesystem via the registry)
Open a new chat in the Chat tab
Observe: no hammer/tools icon, Claude cannot use any MCP tools
Check Connectors panel: shows extensions as toggled on (misleading)

Expected Behavior
MCP tools should either:

Migrate cleanly from the old config format to the new extension system, OR
Surface a clear warning that manual config entries conflict with installed extensions, OR
At minimum, the old config entries should continue to work as they did before the update

Actual Behavior
Both the extension-based server and the legacy config server attempt to launch simultaneously. The extension-based one succeeds, the legacy one is rejected, and the resulting conflict prevents the tool routing layer from exposing any tools to the chat UI. The user sees zero indication of what went wrong.
Log Evidence
Duplicate server conflict on every startup:
The main log (%APPDATA%\Claude\logs\main) shows this pattern repeating on every launch:
[info] MCP Server connection requested for: Filesystem ← extension version
[info] Launching MCP Server: Filesystem
[info] MCP Server connection requested for: filesystem ← legacy config version
[info] Launching MCP Server: filesystem
[info] Checking if UtilityProcess should be used for extension filesystem
[warn] UtilityProcess Check: Extension filesystem not found in installed extensions
Immediately followed by:
[info] desktop_mcp_unexpected_close | extension_name: 'filesystem', mcp_cmd: 'npx'
This crash-reject cycle was observed at 06:17, 06:22, 07:10, 13:52, 13:53, 14:04, and 14:11 on the same day.
MCP server handshake is healthy:
The mcp-server-filesystem log shows a perfect handshake — initialize → notifications/initialized → tools/list → full tool response. The server is functional. The routing layer is the failure point.
[info] Message from client: {"method":"tools/list","params":{},"jsonrpc":"2.0","id":1}
[info] Message from server: {"result":{"tools":[{"name":"read_file",...}]},"jsonrpc":"2.0","id":1}
Secure MCP Filesystem Server running on stdio
Cascading failures:
The conflict triggers additional instability:

Repeated desktop_mcp_unexpected_close events for the legacy filesystem entry on every startup
Webview crash at 14:04: Main webview is unresponsive, will kill and reload — which force-restarts all MCP servers and re-triggers the conflict
Chrome native host EBUSY: resource busy or locked errors from incomplete process cleanup between restarts
MSIX migration warning on every launch: Filesystem not virtualized — likely Squirrel upgrade

Connectors UI is misleading:
The + → Connectors panel shows all MCP servers as toggled on with blue indicators. There is no visual indicator that the app is in a degraded state, no error banner, and no notification that tools are unavailable. The only way to discover the problem is to examine the logs.
Workaround
Option A — Config edit:
Remove the mcpServers block from claude_desktop_config.json, leaving only the preferences section. The extension-based servers will then operate without conflict. Restart the app completely.
Option B — Clean install (recommended):

Back up %APPDATA%\Claude\
Kill all Claude processes
Delete contents of %APPDATA%\Claude\
Uninstall Claude Desktop
Fresh install from https://claude.com/download
Install extensions through Settings → Extensions UI only
Do NOT manually add mcpServers entries to the config file

Impact
This bug silently breaks the primary value proposition of Claude Desktop over claude.ai — local MCP tool access. It affects the exact user base most invested in the platform (power users who set up MCP servers early using the documented method). The lack of any UI indication means users can spend hours or days troubleshooting before discovering the root cause.
The auto-update mechanism means users cannot prevent this from happening, and there is no option to pin a specific version or disable updates.
Related Issues

#11146 — Web session mode lacks MCP access, no visual indicator of mode
#27492 — Cowork MCP registry connection failures after auto-update to v1.1.3189+
#20377 — Local MCP tools not exposed to Cowork
#28304 — Windows desktop crashes on startup (v1.1.4173)
#22299 — MCP tool calls dropped after first round-trip (Windows regression)
#28211 — v1.1.4088 crashes on launch with 2+ MCP servers configured (macOS)

What Should Happen?

MCP tools should work after an auto-update, same as they did before. At minimum, one of:

Auto-migrate manual mcpServers entries to the new extension system and remove the legacy config entries
Detect the conflict (both a manual entry and an installed extension for the same server) and surface a clear warning in the UI
Prioritize one system over the other instead of launching both and letting the conflict silently break tool routing
Display an error indicator in the chat UI when MCP tools are registered but not routable

Error Messages/Logs

DUPLICATE SERVER CONFLICT (repeats every startup):

2026-03-06 13:52:20 [info] MCP Server connection requested for: Filesystem
2026-03-06 13:52:20 [info] Launching MCP Server: Filesystem
2026-03-06 13:52:20 [info] MCP Server connection requested for: filesystem
2026-03-06 13:52:20 [info] Launching MCP Server: filesystem
2026-03-06 13:52:20 [info] Checking if UtilityProcess should be used for extension filesystem
2026-03-06 13:52:20 [warn] UtilityProcess Check: Extension filesystem not found in installed extensions

LEGACY SERVER CRASH:

2026-03-06 06:22:20 desktop_mcp_unexpected_close | extension_name: 'filesystem', mcp_cmd: 'npx'
2026-03-06 13:52:15 desktop_mcp_unexpected_close | extension_name: 'filesystem', mcp_cmd: 'cmd'

HEALTHY HANDSHAKE (proving server works, routing is broken):

2026-03-06T21:11:55.473Z Message from client: {"method":"tools/list","params":{},"jsonrpc":"2.0","id":1}
2026-03-06T21:11:55.487Z Message from server: {"result":{"tools":[{"name":"read_file",...}]},"jsonrpc":"2.0","id":1}

WEBVIEW CRASH:

2026-03-06 14:04:27 Main webview is unresponsive, will kill and reload
2026-03-06 14:04:28 Sentry caught: 'Main webview became unresponsive'

Steps to Reproduce

Start with Claude Desktop pre-v1.1.3189 with manually configured MCP servers in claude_desktop_config.json (the documented setup method used throughout 2025)
Allow auto-update to any version with the new extension management system (v1.1.3189+, tested through v1.1.5368)
The update automatically installs extension-based Filesystem via the registry
The old filesystem entry remains in the config JSON
Launch the app and start a new chat in the Chat tab
Observe: no hammer/tools icon appears, Claude cannot use any MCP tools
Open + menu → Connectors: shows all extensions toggled on (misleading — they appear connected but aren't routable)
Check logs at %APPDATA%\Claude\logs\main: confirm the "Extension filesystem not found in installed extensions" warning and desktop_mcp_unexpected_close events on every startup

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.1.4498

Claude Code Version

Claude Desktop v1.1.5368 (CCD 2.1.63)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_