[Bug] User-level MCPB install silently never completes (org-level succeeds)

[Sam-Heyman]

Environment

• OS: Windows 11 (reproduced on multiple machines)
• Claude Desktop: current
• MCPB manifest version: 0.3
• Server type: node, entry point via mcp-remote remote proxy

What happens

Installing an .mcpb file via Claude Desktop Org Settings → Add → Custom → Desktop:

1. Org-level install prompt appears and completes successfully (Settings → Organization → Connectors → Add → Custom → Desktop)
2. User-level install shows a progress bar that never advances (Settings → Connectors → Customize → (+) → Browse Connectors → our org's connector → (+) → Install)
3. No error is shown - you can dismiss it with X
4. The extension is never installed, no matter how long you wait

What I've ruled out

• Reproduced on multiple machines with different users - not environment-specific
• Full uninstall + reinstall of Claude Desktop (including all user data) does not fix it
• MCP server connects and functions properly via manual workaround - not an issue with the .mcpb file itself

Workaround

Manually adding the server to %APPDATA%\Claude\claude_desktop_config.json:

"mcpServers": {
  "my-server": {
    "command": "npx",
    "args": ["mcp-remote@0.1.38", "https://<endpoint>/mcp"]
  }
}

[PromenadePierce]

Reproduced on macOS 26.5.1 (25F80), Claude Desktop 1.21459.0 — with a diagnostic that narrows down where the pipeline stalls.

Symptom variant: the .mcpb preview dialog renders fully (description, tool list, "All requirements met"), but the Install button renders as a blank, disabled pill — no label, no click action. Same result installing the identical bundle from our org's connector library via Connectors → Browse → Install. Our bundle is also type: node wrapping mcp-remote, same as OP.

Where it stalls (from ~/Library/Logs/Claude/main.log): opening a local .mcpb logs the handler line and then nothing — critically, no can_install request is ever issued for the new bundle:

2026-07-14 18:13:59 [info] Handling DXT/MCPB file: ~/dashboards/mcpb/promenade-analytics-v02.mcpb
(no further extension-related log lines follow)

Meanwhile the periodic can_install re-checks for already-stored extensions run fine and are allowed:

2026-07-14 18:08:57 [info] Checking 1 extensions via can_install API using stored metadata
2026-07-14 18:08:57 [info] Sending can_install request to https://claude.ai/api/organizations/<org-id>/dxt/can_install with 1 extensions: { ... 'ant.dir.ant.anthropic.filesystem' ... }
2026-07-14 18:08:58 [info] can_install check completed: [ { extensionId: 'ant.dir.ant.anthropic.filesystem', canInstall: true, reason: undefined } ]

So the flow dies between rendering the preview and issuing the authorization check for the new bundle, which would leave the Install button stuck in its pre-check disabled state — consistent with the indefinite progress bar OP sees on Windows.

Ruled out on our side:

• OAuth/network behavior of the server — a 1.2 KB zero-dependency null-test bundle (one ping tool, no network, plain stdio JSON-RPC) reproduces the blank button identically.
• Manifest spec version — manifest_version 0.2 and 0.3 behave identically (both pass mcpb validate, CLI 2.1.2).
• Org policy — logs show Organization allowlist enabled: false, and can_install returns canInstall: true for other unsigned extensions.
• Bundle validity / server health — the same server runs correctly when driven directly over stdio with an MCP SDK client.

Happy to provide fuller logs or run instrumented builds if useful.