claude-code - 💡(How to fix) Fix [BUG] v2.1.118 Reconnect action does not reach mcpServers entries added by direct ~/.claude.json edit [1 comments, 2 participants]

Re-filing #53298, which was auto-closed as a duplicate of #44652 by the dupe-bot. Those are different bugs — see "Why this is not #44652" below. I cannot reopen #53298 myself (the API rejects state changes on bot-closed issues, and the web UI has no Reopen button for me as the original author either).

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report
• I am using the latest version of Claude Code

What's Wrong?

The v2.1.118 changelog notes a fix for "HTTP/SSE MCP servers with custom headers being stuck in 'needs authentication' after a transient 401" by exposing a Reconnect action. That fix only reaches MCP servers registered through Claude Desktop's Connectors UI (Settings → Connectors). MCP servers added by directly editing the top-level mcpServers block in ~/.claude.json — the documented configuration path for many remote HTTP servers — are not surfaced in the Connectors UI at all. They therefore have no Reconnect surface, and once they enter the stuck "needs authentication" state, there is no in-app way to recover them. The only workaround I've found is to rename the server keys to force fresh registration.

What Should Happen?

After updating to a build with the v2.1.118 fix, there should be an in-product way to trigger Reconnect on stuck servers without renaming JSON keys. Any of these would solve it:

1. Manually-edited mcpServers entries should appear in the Connectors UI alongside UI-added connectors, with the same Reconnect action.
2. The chat-line /mcp slash command should be available in Claude Desktop's Code chat, exposing the same Reconnect menu the CLI has.
3. A claude mcp reconnect <name> (or claude mcp reset <name>) CLI subcommand should exist for headless recovery.

Error Messages/Logs

api error: GET https://api.digitalocean.com/v2/account: 401 (request "...") Unable to authenticate you

After the stuck state hits, every tool call returns this upstream 401. The MCP server is then marked unavailable for the rest of the session and its tools disappear from the available toolset.

Steps to Reproduce

Original repro (March–April 2026):

1. Configure a remote HTTP MCP server by directly editing ~/.claude.json:

   "mcpServers": {
     "digitalocean-accounts": {
       "type": "http",
       "url": "https://accounts.mcp.digitalocean.com/mcp",
       "headers": {
         "Authorization": "Bearer <your_api_token>"
       }
     }
   }

2. Use the server normally for several days (works fine).
3. The upstream MCP server experiences a transient 401 during a deployment. (DigitalOcean deployed mcp-digitalocean v1.0.49 at 2026-04-24 07:01 UTC in my case.)
4. From this point onward, every tool call to that server returns the upstream 401 above.
5. Quit Claude Desktop (Cmd+Q), relaunch — server still stuck.
6. Update Claude Desktop to a build containing SDK v2.1.118 or later — server still stuck.
7. Settings → Connectors does not list the server. No Reconnect button to find.
8. /mcp returns "/mcp isn't available in this environment" in Claude Desktop, so the CLI's /mcp Reconnect surface is unreachable from Desktop.
9. Direct curl -H "Authorization: Bearer <same-token>" https://accounts.mcp.digitalocean.com/mcp with an identical tools/call payload returns 200 OK and the correct data — confirming the token, URL, and upstream are all healthy. The fault is entirely in Claude Code's cached "needs authentication" state for the server name.
10. Workaround: rename the server key in ~/.claude.json (e.g., digitalocean-accounts → do-accounts). After quit/relaunch, the new key registers fresh and works immediately.

Fresh repro (2026-04-29):

To verify the bug is still present after #53298 was closed, I renamed one of the working do-* keys back to its original digitalocean-* name and restarted Claude Code:

1. Pre-test state: 5 working do-* MCP entries (do-accounts, do-droplets, do-spaces, do-databases, do-networking) — same DO MCP servers, just renamed away from the stuck digitalocean-* keys.
2. Renamed do-accounts → digitalocean-accounts in ~/.claude.json via jq. No other changes — the bearer token and URL are identical.
3. Fully quit Claude Desktop (Cmd+Q), relaunched, started a fresh session.
4. Result:
   • First tool call returned 401 immediately.
   • The MCP server disconnected for the rest of the session — all mcp__digitalocean-accounts__* tools were marked unavailable.
   • No Reconnect / Re-authenticate UI surfaced anywhere — Settings → Connectors still doesn't list the entry, /mcp is still unavailable in Desktop's Code chat.
5. Renamed back; everything works again as do-accounts.

This confirms the cached stuck "needs authentication" state for the original key persists across restarts and across the v2.1.118 update. Renaming back to the original name lands right back in that cached state with no recovery affordance.

Why this is not #44652

The dupe-bot routed #53298 to #44652. They are different bugs:

A fix to #44652 would not help here (different code path, different auth model). A fix here would not help #44652 (this issue's MCP servers don't use OAuth at all). The two share only the substring "MCP" and "401/403" — that's the entire overlap.

Claude Model

Not model-specific.

Is this a regression?

Yes — partially. The v2.1.118 changelog claims a fix for "HTTP/SSE MCP servers with custom headers being stuck in 'needs authentication' after a transient 401", but that fix only covers UI-added connectors. Direct-config mcpServers entries still have no recovery surface, so the user-visible bug is the same as before v2.1.118.

Last Working Version

N/A — direct-config mcpServers entries have always had this issue; v2.1.118 introduced the partial Reconnect fix that highlighted the gap.

Claude Code Version

Claude Desktop 1.5354.0, SDK v2.1.119 (Apple Silicon, macOS).

Platform

Anthropic API.

Operating System

macOS (Apple Silicon).

Terminal/Shell

Claude Desktop "Code" chat (not CLI).

Additional Information

• Direct curl to the same MCP endpoint with the same bearer header returns 200 OK — auth and upstream are healthy.
• Searching ~/Library/Application Support/Claude/Local Storage/leveldb for the original key names turns up MCP-prefixed entries, suggesting the runtime cache is in Electron's LevelDB. Renaming bypasses the cache by creating a new cache key.
• Original ticket: #53298 (closed-as-duplicate by automated dupe-bot, no human review).
• Today's repro is also documented at https://github.com/anthropics/claude-code/issues/53298#issuecomment-4345113806.
• Related, different facets of the same MCP recovery surface gap: #51736, #52200.