[FEATURE] Claude can reconnect to a broken MCP in a manner similar to how it performs other actions
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
I have an MCP (Atlassian) that frequently loses its connection. It's easy enough to reconnect but it would be easier and more natural if Claude could do it in his usual inimitable style. I asked him to write it up and as always, he did a fine job:
Problem
When MCP connections (e.g., Atlassian) drop due to authentication timeout, Claude currently:
- Detects the failure
- Tells the user "Could you reconnect with /mcp?"
- Waits for user to manually type /mcp, navigate menus, and reconnect
This breaks conversational flow and is inconsistent with how Claude handles other operations requiring
permission.
Current Behavior
Claude: [tries to fetch wiki page]
Error: Authentication failed
Claude: "The connection dropped. Could you type /mcp to reconnect?"
User: [types /mcp, selects service, chooses reconnect]
User: "ok, try again"
Claude: [retries operation]
This happens 5-10+ times per session with unstable MCP connections.
Proposed Behavior
Claude should be able to request reconnection directly, similar to other permission prompts:
Claude: [tries to fetch wiki page]
Error: Authentication failed
Claude: "The Atlassian MCP connection failed. Should I:
1) Reconnect and retry
2) Reconnect and don't ask again this session
3) Skip this operation"
User: [selects option 1]
Claude: [triggers reconnection, retries operation]
Benefits
- Consistency - Claude already asks permission for file operations, commits, destructive actions, etc. MCP
reconnection should follow the same pattern
- Reduced friction - One click vs. typing command + navigating menus
- Better flow - Claude can bundle reconnection with retry logic automatically
- Session continuity - Option 2 ("don't ask again") lets power users avoid repeated prompts
Implementation Notes
- Should only apply within an active session (not across sessions - that would be a security concern)
- User authorization is still required, just with a better UX
- Could be limited to same-session reconnections for services already authorized
Related Issues
The underlying issue is MCP connection stability (frequent auth timeouts), but better reconnection UX would
significantly improve the experience while that's being addressed.
Proposed Solution
See above.
Alternative Solutions
_No response_
Priority
Critical - Blocking my work
Feature Category
CLI commands and flags
Use Case Example
_No response_
Additional Context
_No response_
25 Comments
bump
+1 for this feature. I'm developing an MCP server and experiencing the same issue. When I restart the Docker container running my MCP server, Claude Code loses the connection and requires manual reconnection via /mcp.
The current SSE transport stores sessions in memory, so any server restart invalidates all existing session IDs. Claude Code then fails with "Could not find session" but doesn't offer to reconnect automatically. Auto-reconnect would significantly improve the developer experience, especially during active development when server restarts are frequent.
Voting for this one. I use headless mode only. No chat, just comprehensive context, MCPs and permission setup. I’m getting low quality results for my prompts because turned out the MCP servers require reconnections from time to time. Would be great if Claude could take care of reconnecting and never spend tokens if MCPs aren’t connected.
+1 on this
+1
up +1
+1
+1
+1
This is so obvious feature I would say. In my case, MCP shipped inside another standalone C++ app, and MCP runs as the subproccess of this app. In order to see changes in my app during development I need to restart app. Claude code still keep connection with old MCP sessesion, no way to even manualy, say claude to restart MCP connection, only restart claude code. Which makes no sense, I would need to do that once every 2, 3 minutes then. AI pipeline stops being automonus
I don't have any exact version number but my anecdata is that this seems to have become much more of a problem recently? MCP servers that were stable are now constantly requiring me to reconnect manually. It isn't confined to one server and our non-Claude Code clients don't seem to have any issues.
+1
+1 for this.
+1
I find it wild that this hasn't been investigated yet. This is a real pain point for teams working with Atlassian, which lets face it, is an absolutely huge set of users.
+1
+1
And another +1
+1
+1
+1
+1
+1
+1
+1 on this. I'd also add two behaviors that I think are important and not fully covered here:
1. Auto-restart without prompting for non-auth failures
When an MCP server process crashes or the connection drops (but no re-authentication is needed), the client should auto-restart and retry without asking. A one-line status message ("Restarted Radar MCP, retrying…") is sufficient. The permission prompt makes sense for auth flows that open a browser, but a simple process restart shouldn't require user interaction.
2. Never silently work around a failed MCP
In my experience, Claude doesn't always stop and ask — it often tries to continue the task without the MCP's context, producing incomplete or incorrect results. I then have to notice (by reading the transcript), cancel Claude's work, reconnect manually, and re-ask. The client should enforce that a failed MCP tool call pauses the conversation rather than letting the model work around it.
Together with the reconnection UX proposed in this issue, the behavior tiers would be:
| Scenario | Action |
|----------|--------|
| Server process crashed, no auth needed | Auto-restart, retry, inform user (no prompt) |
| Server returning auth errors | Pause, prompt user to re-auth inline (as proposed above), retry after |
| Server config missing/invalid | Pause, surface error, ask user to fix config |
The "don't ask again this session" option from the original proposal would pair well with tier 2.