claude.ai Figma connector loaded by VSCode extension despite being disabled in web + Desktop + /mcp UI (Max plan)

Summary

The claude.ai Figma connector is still loaded by the Claude Code VSCode extension on startup even after it has been disabled in claude.ai web settings, in the Claude Desktop app, and via the extension's own /mcp UI. Each session the extension still attempts the JSON-RPC handshake to the disabled connector; the handshake fails with -32600 "Anthropic Proxy: Invalid content from server", and that failure then surfaces in the chat UI as the well-known Unhandled case: [object Object] toast (see #59120, #59188, #59047, and many more filed today).

Edit: my first cut of this issue suggested editing disabledMcpServers in ~/.claude.json as a workaround. After more testing that turned out to be a no-op for claude.ai * entries. The actually-working workaround is at the bottom of the body and involves ~/.claude/mcp-needs-auth-cache.json directly. The fact that disabling in three official UIs also doesn't write to that cache is the real bug.

Environment

• Extension: anthropic.claude-code-2.1.141-darwin-arm64
• macOS 26 (Darwin 25.5.0), arm64
• claude.ai Max plan subscriber (relevant — see Severity below)
• Model in session: Opus 4.7 (1M context)

Repro

1. In claude.ai web → Settings → Connectors → toggle off Figma.
2. In Claude Desktop app → Settings → Connectors → toggle off Figma.
3. In VSCode → Claude Code panel → /mcp → disable claude.ai Figma.
4. Restart VSCode.
5. Open the Claude Code extension log: ~/Library/Application Support/Code/logs/<session>/window1/exthost/Anthropic.claude-code/Claude VSCode.log.

Observed:

[DEBUG] MCP server "claude.ai Figma": Initializing claude.ai proxy transport for server mcpsrv_<redacted>
[DEBUG] MCP server "claude.ai Figma": Using claude.ai proxy at https://mcp-proxy.anthropic.com/v1/mcp/...
[DEBUG] MCP server "claude.ai Figma": Starting connection with timeout of 30000ms
[DEBUG] MCP server "claude.ai Figma": claude.ai proxy connection failed after 488ms: Streamable HTTP error: Error POSTing to endpoint: {"jsonrpc":"2.0","id":0,"error":{"code":-32600,"message":"Anthropic Proxy: Invalid content from server","data":null}}
[ERROR] MCP server "claude.ai Figma" Error: Streamable HTTP error: ...
[ERROR] MCP server "claude.ai Figma" Connection failed: Streamable HTTP error: ...

The extension is still loading + attempting to connect to the Figma connector despite it being disabled in three separate surfaces. The pattern repeats roughly every 30-60 minutes (each chat restart / reconnect). Each failure produces an Unhandled case: [object Object] toast that blocks chat input until manually dismissed.

Expected: any of the three disable actions should fully suppress the connector load. The extension should not attempt the JSON-RPC handshake on startup for a disabled connector.

Severity — Max plan makes it worse, not better

This bug is materially worse for Max plan subscribers, who are exactly the users who:

• Run multi-hour sessions (more reconnect cycles, each one re-fires the disabled-connector handshake)
• Use the extension as a daily driver (so the cumulative interruption count per day is high — I hit 5-6 unhandled-case toasts in a 4-hour session today, each one halts chat input until manually dismissed)
• Are most likely to have many claude.ai connectors paired in the first place (they were the first cohort to get Connectors)
• Pay a premium for the workflow tier the bug most directly degrades

Each toast forces a manual dismiss before any further chat input lands. The cost compounds the longer the session runs.

Root cause hypothesis

There are two config files that govern connector boot:

• ~/.claude.json → projects.<path>.disabledMcpServers — array of server names the user has flagged off.
• ~/.claude/mcp-needs-auth-cache.json — cache of { "<server name>": { timestamp, id } } entries, written when a server is in a "needs reauth / disconnected" state.

On boot the extension consults only the second file for claude.ai * connectors. If a server appears in the cache, boot produces a clean [DEBUG] MCP server "claude.ai X": Skipping connection (cached needs-auth) and the server stays quiet. If it doesn't, the extension dutifully tries the JSON-RPC handshake regardless of what disabledMcpServers says.

In my case, my other disconnected claude.ai * connectors sit in the cache and stay quiet. Figma does not — even though I went through the same disconnect flow with it. So the bug is (a) the disabled list in ~/.claude.json is wired to nothing for claude.ai * entries, AND (b) the disconnect flow in claude.ai web / Desktop / /mcp doesn't reliably write the needs-auth-cache entry that the extension actually consults.

Working manual workaround

Append directly to ~/.claude/mcp-needs-auth-cache.json:

{
  // existing entries…
  "claude.ai Figma": {
    "timestamp": <current unix epoch in ms>,
    "id": "<server id from one of the failing log lines, e.g. mcpsrv_<…>>"
  }
}

Reload window. Boot now produces [DEBUG] MCP server "claude.ai Figma": Skipping connection (cached needs-auth) instead of the connection attempt + toast.

(This is what disconnecting in the official UIs should produce. The fact that it doesn't is the bug.)

Related observations

a) The disabledMcpServers parser appears to ignore plugin:* entries too

Several plugin:* entries in my disabledMcpServers list are still being launched and failing audibly each session:

"disabledMcpServers": [
  // ...
  "plugin:telegram:telegram",      // disabled — but log shows it launching, fails on missing TELEGRAM_BOT_TOKEN
  "plugin:supabase:supabase",      // disabled — but log shows 29 connection attempts today, all "Unauthorized"
]

Log excerpts:

[ERROR] "MCP server \"plugin:telegram:telegram\" Server stderr: telegram channel: TELEGRAM_BOT_TOKEN required
[DEBUG] MCP server "plugin:supabase:supabase": HTTP Connection failed after 431ms: Unauthorized

So the disabled-list-is-ignored behaviour is not specific to claude.ai * — it's broader. (Cousin of #23838, which reports the same prefix issue for deniedMcpServers.)

b) Severity ties back to the unhandled-case toast bug

Many of the failed connections — Figma included — surface in the chat UI as Unhandled case: [object Object] toasts (#59120, #59188). Those toasts block chat input until manually dismissed, so this isn't just a logging nuisance — it directly interrupts active sessions multiple times per hour for Max-plan users.

Suggested fix

1. The disconnect flow in claude.ai web settings / Claude Desktop / extension /mcp UI should reliably write the corresponding mcp-needs-auth-cache.json entry (or whatever flag actually short-circuits the boot connection). Today it works for some connectors and silently doesn't for others (Figma) — there should be one mandatory write path.
2. Make disabledMcpServers actually do something, or remove it. Right now it appears to be a no-op for both claude.ai * and plugin:* entries, which makes the obvious-looking user fix a dead end.
3. Mirror of the #23838 fix: disabledMcpServers parser should match plugin:* entries as well.