[BUG] Claude Desktop (Windows): an enabled .mcpb extension's tools never reach a regular Chat; the identical server via claude_desktop_config.json works

Summary

An installed, enabled .mcpb desktop extension launches correctly and answers initialize + tools/list with all its tools, but those tools are never delivered to the model in a regular Chat (not Cowork) — the model reports it has no such tools and no tools/call ever reaches the server. Registering the exact same server in claude_desktop_config.json instead makes the tools work in the same chat. The extension's tools worked exactly once (immediately after the first install) and never again, surviving every reset below.

Environment

• Claude Desktop: 1.14271.0 (Windows MSIX build, Claude_1.14271.0.0_x64)
• OS: Windows 11 Pro (26200)
• Session type: regular Chat (not Cowork, not a Code/agent session)
• MCP server: local Node stdio server, @modelcontextprotocol/sdk 1.29.0, protocol 2025-11-25, 5 read-only tools. Runs on Desktop's built-in Node via UtilityProcess.
• Org desktop-extension allowlist disabled, blocklist empty, can_install: true, no signature-required policy, no managed/MDM settings.

Extension manifest (key fields)

• manifest_version: 0.4; server.type: node; entry_point: dist/index.js; tools_generated: true.
• Unsigned, installed locally (signature_info.status: unsigned, source: local). Install warns "unsigned extension"; install still allowed (can_install: true).
• user_config requires the user to enter two Personal Access Tokens (one Jira, one GitLab — both sensitive: true) plus a persona string. These are injected as env vars (JIRA_PERSONAL_TOKEN, GITLAB_PERSONAL_ACCESS_TOKEN, base URLs, APP_PERSONA) into the server process. (Both PATs were configured and saved; the GitLab token was verified working by the server's own check tool. Internal base URLs omitted here.)
• 5 tools: 2 read-only "system check" tools (Jira/GitLab reachability) + 3 doc search/read/list tools over a bundled snapshot.

Minimal A/B repro (same server, two registration methods)

A — as a .mcpb extension → BROKEN:

1. Package the Node stdio server as .mcpb; install + enable; enter the 2 PATs + persona in the extension's config UI.
2. Desktop launches it: Launching MCP Server … Using UtilityProcess … built-in node compatible → [UtilityProcess stderr] … started on stdio.
3. Server log shows every spawn completing initialize → tools/list returning all 5 tools.
4. In a regular Chat, ask the model to use a tool (e.g. "use list_docs"). The model replies it has no such tool. No tools/call ever reaches the server.

B — same server via claude_desktop_config.json → WORKS:

{ "mcpServers": { "my-server": {
  "command": "C:\\Program Files\\nodejs\\node.exe",
  "args": ["C:\\Users\\<you>\\path\\to\\dist\\index.js"],
  "env": { "...": "..." } } } }

Restart; same regular Chat prompt → the model calls the tool and tools/call reaches the server ("method":"tools/call", "name":"list_docs"). Reliable.

Expected vs. actual

• Expected: an installed + enabled .mcpb extension's tools are available to the model in chat, like a claude_desktop_config.json server.
• Actual: the .mcpb extension's tools are never delivered to the model (server connects, tools/list returns, no tools/call); only the claude_desktop_config.json registration of the identical server surfaces them.

It worked exactly once — then these did NOT recover it

The tools worked in one regular Chat right after the first install (multiple successful tools/calls). After that, none of the following restored them — each was tried and verified via the server log (server keeps spawning + listing tools, but receives no tools/call):

• Uninstall + reinstall the .mcpb (several times).
• Rebuild with a fresh extension identity (different name and author, so a new local.mcpb.* id) — also failed identically (rules out per-identity cloud cache).
• Full state cleanup: removed bridge-state.json, archived/cleared the server logs, confirmed no stale processes.
• Signed out of the Claude account and signed back in (rebuilds the account/SDK bridge session).
• Full Windows reboot.
• Re-entered/saved the 2 PATs after reinstall each time.

Evidence (sanitized log excerpts)

• logs/main.log: Launching MCP Server … Using UtilityProcess … built-in node compatible → [UtilityProcess stderr] … started on stdio.
• logs/mcp-server-<name>.log (as .mcpb): initialize → tools/list (all 5 tools) → no tools/call, every session.
• logs/mcp-server-<name>.log (via config): initialize → tools/list → tools/call name:list_docs — succeeds.
• logs/main.log: [transport:sdk] attaching SDK bridge session cse_… (apiBaseUrl=https://api.anthropic.com).

Ruled out

• Org governance: allowlist disabled, blocklist empty, can_install: true, no signature-required policy, no managed settings.
• AV / system blocking: the server process launches and runs on every spawn.
• Per-identity cloud cache: a freshly renamed extension identity also failed identically.
• Server defect: driving the built server directly over stdio shows protocol-only stdout (no stray bytes), valid tool schemas, and a working tools/call. The server is correct in isolation.

Related

#14807 (tools stopped working — server connected, no tools; closed not-planned), #32552 (LocalMcpServerManager never reconnects after a settings/restart), #20377 / #23424 (local MCP not exposed to Cowork), #11146 (native vs containerized session MCP access), #31864 (legacy-config vs extension conflict, Windows).