[BUG] Claude Desktop v1.6608 doesn't load local MCP servers from ~/.claude.json in CCD sessions

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?

User-scope MCP servers registered in ~/.claude.json under top-level mcpServers are recognized by the CLI (claude.exe mcp list reports ✓ Connected) but are silently NOT loaded into sessions started from Claude Desktop UI (CCD).

Same configuration worked correctly in Claude Desktop 1.6259.x. After updating to 1.6608.2.0, the local MCP tools (mcp__<server>__*) became unavailable in CCD sessions.

Log evidence (from %APPDATA%\Claude\logs\main.log):

[CCD] Passing 1 plugin(s) to SDK (skills: 1, remote: 0, local: 0)

The local: 0 indicates user-scope local MCPs are not being passed to the SDK, even though they are present in ~/.claude.json and pass the CLI health check.

Additionally, the /mcp slash command opens a "Connectors / Plugins" marketplace UI restricted to "Anthropic & Partners" filter — there is no UI to add or manage a custom local stdio MCP server.

Impact: users with self-hosted MCP servers (e.g. for privacy / scope-restricted OAuth) lose all functionality after update, with no in-app path to re-register.

What Should Happen?

Either:

1. Local stdio MCP servers from user-scope ~/.claude.json mcpServers should be loaded into Claude Desktop sessions (matching pre-1.6608 behavior), OR
2. The /mcp UI should provide a way to add and manage custom local MCP servers (and CCD should pick them up).

At minimum, when a user-scope MCP is configured but ignored, the UI should surface a clear notice rather than silently dropping it.

Error Messages/Logs

Steps to Reproduce

1. Register a stdio MCP server at user scope:

``bash
claude mcp add my-mcp -s user -- /path/to/python main.py
`
(or by editing ~/.claude.json mcpServers` directly).

1. Verify with the CLI:

``bash
claude mcp list
# my-mcp: ... - ✓ Connected
``

1. Open Claude Desktop, start (or warm) a new session in any CWD that has trust accepted.

1. Inspect %APPDATA%\Claude\logs\main.log and observe:

``
[CCD] Passing 1 plugin(s) to SDK (skills: 1, remote: 0, local: 0)
`
local: 0 — the MCP from ~/.claude.json` was not picked up.

1. In the session, MCP tools (mcp__my-mcp__*) are not available. Slash command /mcp shows only Anthropic & Partner connectors with no "Add custom server" option, and the filter pill is fixed (cannot switch to a "Local" or "Custom" view).

1. Same setup worked under Claude Desktop 1.6259.x.

Notes:

• The MCP binary itself starts and responds to a manual JSON-RPC initialize request via stdio in ~3.1 s, so the underlying server is healthy.
• Setting MCP_TIMEOUT=60000 (Windows user env) makes the CLI health check pass reliably, but does not change CCD behavior.
• Migrating the MCP project to an ASCII-only path also did not change CCD behavior.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Claude Desktop 1.6259.1.0 (Claude Code 2.1.x bundled)

Claude Code Version

2.1.128 (Claude Code, bundled with Claude Desktop 1.6608.2.0)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Why this matters (motivation):
Self-hosted MCP setups are sometimes deliberately scope-restricted at the OAuth level — for example, a Google Workspace MCP using calendar.readonly for existing calendars and calendar.app.created for a single dedicated "Claude Tasks" calendar. The marketplace Google Calendar connector likely has broader scopes and routes calendar data through Anthropic's infrastructure, which is a privacy/safety regression for users who explicitly chose self-hosting.

The current state — local MCP silently dropped, no UI to re-add — leaves these users with no in-app path to restore functionality after an auto-update.

Things tried (none changed CCD behavior):

• Migrated MCP project from Japanese path (C:\Claude作業\…) to ASCII path (C:\Users\<u>\claude-work\…)
• Recreated the venv at the new path (uv venv + uv pip install -e .)
• Updated ~/.claude.json mcpServers.<name>.command and cwd to the new ASCII path
• Set MCP_TIMEOUT=60000 as a Windows User env ([Environment]::SetEnvironmentVariable('MCP_TIMEOUT','60000','User'))
• Restarted Claude Desktop completely after each change

After all of the above, claude.exe mcp list reports ✓ Connected, but Claude Desktop sessions still show local: 0 in [CCD] Passing N plugin(s) to SDK log lines and the MCP tools remain unavailable in-session.

Workaround in use:
Falling back to claude-in-chrome to operate the calendar via browser automation. Functional but loses the self-hosted MCP's safety constraints, and is significantly slower per operation.

---

Note for reviewers: the dropdowns above for Platform / Operating System / Terminal were not adjustable from automated form-fill in my flow — please read this issue with the understanding that the actual environment is Windows 11, Anthropic Console (Claude Desktop login), and Git Bash / PowerShell (whichever applies; the bug is independent of the terminal).