[BUG] Built-in MCP servers (mcp-registry, claude-in-chrome) never launch on Windows — "connection requested" logged but no "Launching MCP Server", no error

Resolved 💬 1 comment Opened Jul 6, 2026 by lekanic01 Closed Jul 9, 2026

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: Claude Desktop for Windows, v1.18286.0 (reproduced also on v1.13576.4 before updating)
Install source: MSIX / Windows Store package (windowsStore=true, C:\Program Files\WindowsApps\Claude_1.18286.0.0_x64__pzs8sxrjxfjjc\...)
OS: Windows (corporate network; downloads.claude.ai was previously blocked but has been allowlisted — updater now works fine, so network is not the cause)

Summary

The two built-in MCP servers — mcp-registry and claude-in-chrome — are requested at every session start but never launch. User-installed extensions (Filesystem, pdf-viewer) launch normally in the same sessions. No error is ever logged for the failing servers (silent failure).

As a result, any tool from these servers fails. mcp-registry:list_connectors behaves inconsistently:

Right after app restart: Tool not found (server absent from tool index)
Later in the same app session: tool appears in the index again, but calling it returns Tool execution failed

This looks like the same class of issue as #27625 / #27492, still reproducing on v1.18286.0.

Log evidence (main.log)

Latest session, after updating to 1.18286.0 and a full restart:

2026-07-06 11:40:55 [info] MCP Server connection requested for: Filesystem
2026-07-06 11:40:55 [info] Launching MCP Server: Filesystem
2026-07-06 11:40:55 [info] MCP Server connection requested for: pdf-viewer
2026-07-06 11:40:55 [info] Launching MCP Server: pdf-viewer
2026-07-06 11:40:55 [info] MCP Server connection requested for: mcp-registry
2026-07-06 11:40:55 [info] MCP Server connection requested for: claude-in-chrome

Note: no Launching MCP Server: mcp-registry / claude-in-chrome lines, and grepping the entire log for error/fail entries mentioning these servers returns zero results. The same pattern repeats in every session since at least 2026-06-22 (oldest entries in the log), across versions 1.13576.4 and 1.18286.0.

Steps to reproduce

Start Claude Desktop for Windows (MSIX install) on this machine
Observe main.log: connection requested for all four servers, Launching only for the two user-installed extensions
In any chat, ask Claude to call mcp-registry:list_connectors
Result: Tool not found (fresh session) or Tool execution failed (later)

What I ruled out

Network: downloads.claude.ai was blocked by corporate proxy earlier (updater failed with 0x80190193 / HTTP 403). It is now allowlisted; the app updated successfully from 1.13576.4 to 1.18286.0 and no 403 appears in today's logs. mcp-registry behavior is unchanged before/after.
App version: reproduced on both 1.13576.4 and 1.18286.0 (auto-updated + full restart via tray quit).
User extensions: Filesystem and pdf-viewer launch and work normally in the same sessions (UtilityProcess with built-in Node).
Permission prompts: the tool-use permission dialog for list_connectors was approved ("Always allow"); execution still fails.

Expected

Built-in MCP servers launch like user-installed extensions, or at minimum log an error explaining why launch was skipped.

Actual

connection requested with no subsequent launch and no error; tools from these servers intermittently appear in the tool index but always fail to execute.

What Should Happen?

Environment

App: Claude Desktop for Windows, v1.18286.0 (reproduced also on v1.13576.4 before updating)
Install source: MSIX / Windows Store package (windowsStore=true, C:\Program Files\WindowsApps\Claude_1.18286.0.0_x64__pzs8sxrjxfjjc\...)
OS: Windows (corporate network; downloads.claude.ai was previously blocked but has been allowlisted — updater now works fine, so network is not the cause)

Summary

The two built-in MCP servers — mcp-registry and claude-in-chrome — are requested at every session start but never launch. User-installed extensions (Filesystem, pdf-viewer) launch normally in the same sessions. No error is ever logged for the failing servers (silent failure).

As a result, any tool from these servers fails. mcp-registry:list_connectors behaves inconsistently:

Right after app restart: Tool not found (server absent from tool index)
Later in the same app session: tool appears in the index again, but calling it returns Tool execution failed

This looks like the same class of issue as #27625 / #27492, still reproducing on v1.18286.0.

Log evidence (main.log)

Latest session, after updating to 1.18286.0 and a full restart:

2026-07-06 11:40:55 [info] MCP Server connection requested for: Filesystem
2026-07-06 11:40:55 [info] Launching MCP Server: Filesystem
2026-07-06 11:40:55 [info] MCP Server connection requested for: pdf-viewer
2026-07-06 11:40:55 [info] Launching MCP Server: pdf-viewer
2026-07-06 11:40:55 [info] MCP Server connection requested for: mcp-registry
2026-07-06 11:40:55 [info] MCP Server connection requested for: claude-in-chrome

Note: no Launching MCP Server: mcp-registry / claude-in-chrome lines, and grepping the entire log for error/fail entries mentioning these servers returns zero results. The same pattern repeats in every session since at least 2026-06-22 (oldest entries in the log), across versions 1.13576.4 and 1.18286.0.

Steps to reproduce

Start Claude Desktop for Windows (MSIX install) on this machine
Observe main.log: connection requested for all four servers, Launching only for the two user-installed extensions
In any chat, ask Claude to call mcp-registry:list_connectors
Result: Tool not found (fresh session) or Tool execution failed (later)

What I ruled out

Network: downloads.claude.ai was blocked by corporate proxy earlier (updater failed with 0x80190193 / HTTP 403). It is now allowlisted; the app updated successfully from 1.13576.4 to 1.18286.0 and no 403 appears in today's logs. mcp-registry behavior is unchanged before/after.
App version: reproduced on both 1.13576.4 and 1.18286.0 (auto-updated + full restart via tray quit).
User extensions: Filesystem and pdf-viewer launch and work normally in the same sessions (UtilityProcess with built-in Node).
Permission prompts: the tool-use permission dialog for list_connectors was approved ("Always allow"); execution still fails.

Expected

Built-in MCP servers launch like user-installed extensions, or at minimum log an error explaining why launch was skipped.

Actual

connection requested with no subsequent launch and no error; tools from these servers intermittently appear in the tool index but always fail to execute.

Error Messages/Logs

Steps to Reproduce

Steps to reproduce

Start Claude Desktop for Windows (MSIX install) on this machine
Observe main.log: connection requested for all four servers, Launching only for the two user-installed extensions
In any chat, ask Claude to call mcp-registry:list_connectors
Result: Tool not found (fresh session) or Tool execution failed (later)

What I ruled out

Network: downloads.claude.ai was blocked by corporate proxy earlier (updater failed with 0x80190193 / HTTP 403). It is now allowlisted; the app updated successfully from 1.13576.4 to 1.18286.0 and no 403 appears in today's logs. mcp-registry behavior is unchanged before/after.
App version: reproduced on both 1.13576.4 and 1.18286.0 (auto-updated + full restart via tray quit).
User extensions: Filesystem and pdf-viewer launch and work normally in the same sessions (UtilityProcess with built-in Node).
Permission prompts: the tool-use permission dialog for list_connectors was approved ("Always allow"); execution still fails.

Expected

Built-in MCP servers launch like user-installed extensions, or at minimum log an error explaining why launch was skipped.

Actual

connection requested with no subsequent launch and no error; tools from these servers intermittently appear in the tool index but always fail to execute.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude 1.18286.0 (259c3f)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗