[BUG] Plugin-bundled HTTP MCP connector 'Install' button permanently greyed out — reproduces WITHOUT OAuth (static header auth)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported with this specific data point (static-header, non-OAuth reproduction) yet — see the related cluster below
• [x] This is a single bug report
• [x] I am using a current version of Claude Code (verified against v2.1.222, the latest as of 2026-08-05; the underlying bug has been reproducible since at least v2.1.92)

What's Wrong?

A plugin's remote MCP connector, declared with "type": "http" in the plugin's .mcp.json, shows a permanently greyed-out, unresponsive "Install" button in the plugin's Connectors panel (both Claude Desktop and Claude Code plugin settings). Clicking it does nothing — no request fires, no error, no state change.

This exact symptom has been reported repeatedly for OAuth-based remote connectors (#45219 Todoist, #44223/#36307/#26917/#11585 chain, #72241 Atlassian, #62981, #45288's feature-request asking for a fix). All of those are closed as stale/duplicate by the bot, with no maintainer response and no linked PR in this repo.

New data point this issue adds: our connector uses NO OAuth at all. It authenticates via a static header substituted from an environment variable — there is no oauth block, no Dynamic Client Registration, no browser redirect expected or possible. The button is greyed out identically anyway. This suggests the break is in the generic Install-button click handler for the entire http/sse plugin-connector class, not specifically in the OAuth/redirect-suppression code path described in #26917's debug logs ("Redirection handling is disabled, skipping redirect").

Our plugin bundles a second, sibling connector using "type": "stdio" in the same .mcp.json — that one installs and connects perfectly. Only the http-type connector is affected, isolating this cleanly to transport type rather than to any particular auth mechanism.

What Should Happen?

Clicking "Install" for an http/sse-type plugin connector should attempt to connect (and start OAuth discovery only if the server actually challenges with a 401/WWW-Authenticate, per RFC 9728). For a connector with no OAuth requirement at all, it should connect immediately with no further user action needed.

Repro Config

{
  "mcpServers": {
    "ps-remote": {
      "type": "http",
      "url": "https://<our-server>.azurewebsites.net/mcp",
      "headers": {
        "x-functions-key": "${OUR_MCP_KEY}"
      }
    },
    "ps-local": {
      "type": "stdio",
      "command": "uv",
      "args": ["run", "..."]
    }
  }
}

Bundled in a Claude Code plugin (.claude-plugin/plugin.json + this .mcp.json). Installing the plugin surfaces both ps-remote and ps-local under Connectors. ps-local connects immediately (no button). ps-remote shows a greyed-out "Install" button that never becomes clickable/responsive, so its tools are never usable through the plugin's own Connectors panel.

Related issues (all closed stale/duplicate, no maintainer response, no linked PR found in this repo as of filing)

• #45219 — Install button greyed out, OAuth-based (Todoist) — same UI symptom, OAuth server
• #75961 — most detailed: plugin-bundled OAuth servers unreachable through any surface (/mcp, claude mcp login, Desktop Connectors); documents a workaround registering the same server manually via claude mcp add --transport http --scope user ... outside the plugin, which does authenticate successfully — confirming the break is specifically in the plugin-connector install path, not in Claude Code's OAuth machinery generally
• #72241 — Atlassian connector, same symptom, still open; a commenter: "there is no way I can trigger the OAuth flow for connectors in Claude Code or Claude Cowork now"
• #62981 — directly tested a bare url-only shape (no explicit oauth block) and still got the greyed-out button — the same pattern this issue reproduces, just not previously flagged as OAuth-independent
• #45288 — feature request asking Anthropic to fix exactly this gap (auto-trigger OAuth, or an explicit auth-trigger surface for plugin connectors); never implemented
• #26917 — root-cause debug logs showing Claude Code generates the OAuth URL correctly but then explicitly suppresses the redirect step
• #53918 — a related-but-distinct issue: even a connector that gets past Install with static Bearer-token auth can stall mid-handshake ("Couldn't reach the MCP server") — suggesting HTTP/SSE plugin connectors have more than one independent rough edge right now

Why this matters enough to reopen the conversation

Every issue in this cluster has been closed by the stale-bot or duplicate-bot without a maintainer ever commenting or a fix landing, across 100+ releases and 4+ months. This report adds the specific evidence that the bug is not confined to OAuth setups — any plugin shipping a remote http/sse MCP connector, regardless of auth mechanism, currently cannot be installed through the plugin UI's own Connectors panel. The only known working path is bypassing the plugin's connector declaration entirely and re-registering the same server manually via the CLI (claude mcp add) — which defeats the purpose of a plugin bundling the connector in the first place.

🤖 Filed with assistance from Claude Code