Remote MCP (Figma): post-OAuth reconnect hangs 30s and fails, requires full restart
Summary
After completing the OAuth flow for a remote HTTP MCP server (https://mcp.figma.com/mcp), Claude Code stores the token successfully but the in-process post-auth reconnect hangs for the full 30 s connection timeout and fails with:
Got new credentials, but reconnecting to figma failed. Restart Claude Code to retry.
The same endpoint is reachable in <1 s from curl on the same machine at the same moment, so this is not a network or server issue — the MCP client's reconnect-after-auth path is broken.
Environment
- Claude Code: 2.1.126 (also reproduced on 2.1.123)
- OS: macOS 26.4 (build 25E246), Apple Silicon
- Shell: zsh, Apple_Terminal (also reproduces in VS Code integrated terminal)
- MCP server:
figma— remote HTTP transport,https://mcp.figma.com/mcp - Network: tested on home Wi-Fi and on phone hotspot — same result
- No
HTTP_PROXY/HTTPS_PROXYset
Reproduction
claude mcp add --transport http figma https://mcp.figma.com/mcpclaude --debug/mcp→ selectfigma→ Authenticate- Browser opens, user approves in Figma, browser shows success.
- Terminal eventually shows:
Got new credentials, but reconnecting to figma failed. Restart Claude Code to retry. /mcpshows figma as Failed/Disconnected.- Quit Claude Code (
/quit) and restart — the persisted token is picked up cleanly and figma connects on first try with no further auth.
So the token is valid; only the in-process reconnect is broken.
Expected behavior
After OAuth completes, the MCP client should re-establish the HTTP transport using the new token and transition the server to Connected — without requiring the user to quit and relaunch Claude Code.
Actual behavior
The reconnect attempt opens an HTTPS request that never completes the MCP handshake within the 30 s timeout. The same TLS endpoint responds correctly in <1 s to a plain curl.
Evidence
Network is healthy
$ time curl -v --max-time 10 https://mcp.figma.com/mcp
< HTTP/2 405
< content-type: application/json; charset=utf-8
{"jsonrpc":"2.0","error":{"code":-32000,"message":"Method not allowed."},"id":null}
curl -v --max-time 10 https://mcp.figma.com/mcp 0.01s user 0.01s system 2% cpu 0.933 total
(HTTP/2 405 is the correct response for GET on this endpoint.)
Debug log — full sequence from ~/.claude/debug/<id>.txt
OAuth flow succeeds and token is obtained:
08:49:00.583 MCP server "figma": Fetched OAuth metadata with scope: mcp:connect
08:49:00.583 MCP server "figma": Generated new OAuth state
08:49:02.265 MCP server "figma": Authorization URL: https://www.figma.com/oauth/mcp?...
08:49:02.266 MCP server "figma": Opening authorization URL: ...
08:49:18.794 MCP server "figma": MCP OAuth server cleaned up
08:49:21.088 MCP server "figma": Token expires in: 7776000
08:49:21.112 MCP server "figma": Token expires_in: 7775999.977
Immediately after, post-auth reconnect hangs and times out:
08:49:51.131 MCP server "figma": Connection timeout triggered after 30018ms (limit: 30000ms)
08:49:51.133 MCP server "figma": HTTP Connection failed after 30020ms: MCP server "figma" connection timed out after 30000ms (code: none, errno: none)
08:49:51.133 [ERROR] MCP server "figma" TelemetrySafeError: MCP server "figma" connection timed out after 30000ms
08:49:51.134 MCP server "figma": Connection failed after 30020ms
08:49:51.134 [ERROR] MCP server "figma" Connection failed: MCP server "figma" connection timed out after 30000ms
08:49:51.135 MCP server "figma": Reconnection failed after authentication
After quitting and relaunching, Figma connects without re-auth → confirms the stored token is valid and only the in-process reconnect path is broken.
Related secondary issue (probably same root cause)
The initial connection on session start sometimes also hits the same 30 s timeout — even with a valid stored token — and only recovers after the user manually re-auths or restarts. Same Connection timeout triggered after 30000ms signature. Suggests the HTTP transport's first request after a state transition (cold start, post-OAuth) doesn't complete the MCP handshake reliably, while subsequent requests in the same process work fine.
Suggested fix direction
- Tear down and re-create the HTTP transport object after OAuth completes, instead of attempting to reuse the connection that failed pre-auth with a 401. The current "reconnect with new token" path appears to be reusing stale transport state.
- Surface the underlying handshake failure in the user-facing message instead of the generic "Restart Claude Code to retry" — at minimum, log the response status / first bytes from the failing request so users can self-diagnose.
Workaround for other users
Until fixed, treat re-auth as a two-process flow:
- When prompted to authenticate, complete the browser flow.
- When you see "Got new credentials, but reconnecting failed" — immediately quit Claude Code.
- Relaunch — token is picked up cleanly on cold start.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗