[BUG] Reconnecting an existing remote MCP connector in Desktop does nothing after a successful OAuth round trip — only remove-and-re-add works

Environment

• Claude Desktop (macOS)
• Remote HTTP MCP server with OAuth (Streamable HTTP transport)

Summary

Clicking "Reconnect" on an existing MCP connector in Desktop triggers the OAuth flow, which completes successfully — the browser reaches the callback and redirects back to Desktop. But the connector doesn't come back up: no tools appear, no visible state change in the UI. Server-side logs confirm the full handshake succeeded (register → 201, auth/callback → 302, /token → 200, initialize → 200, notifications/initialized → 202, tools/list → 200) — so the token was issued and the server responded correctly. Desktop just doesn't act on it.

Removing the connector entirely and re-adding it (fresh OAuth flow, not "reconnect") fixes it immediately.

Steps to reproduce

1. Have a working remote MCP connector in Desktop that requires OAuth re-auth (e.g. after token expiry).
2. Click "Reconnect" (not remove).
3. Complete the OAuth flow in the browser — it redirects back to Desktop with success.
4. Observe: connector does not become usable; no tools available in a new conversation.
5. Remove the connector, add it again from scratch, redo OAuth.
6. Observe: connector works immediately.

Expected

Reconnect should leave the connector in the same working state as a fresh add, given the server confirms a successful token issuance and handshake.

Actual

Reconnect silently no-ops despite a verified-successful server-side OAuth completion. Only full removal + re-add recovers the connection.

Related

• #71297 — similar "OAuth completes, connector shows active, but nothing works" symptom on a different connector; that report says disconnect/reconnect did not help, which may indicate this is one of possibly several distinct bugs in the reconnect path rather than a single root cause.
• #77127 — Desktop's /mcp gallery has no distinct "needs reauthentication" state, which made it hard to tell reconnect had silently failed rather than just being slow.

Additional evidence available on request

Server-side request logs for the failed round trips, showing full 200-status handshake completion with no errors on the server side.