›_ Claude Code Issues
Claude Code Issues / #52358

[BUG] Multiple custom MCP connectors stopped working simultaneously with "Couldn't reach the MCP server" error

Status Fixed / completed
Reported on v2.1.118
Maintainer reply ✓ Yes — localden
Activity 5 comments · opened Apr 23, 2026 · closed May 20, 2026
💡 Likely answer: A maintainer (localden, collaborator) responded on this thread — see the highlighted reply below.

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Multiple custom MCP connectors stopped working simultaneously with
"Couldn't reach the MCP server" error.

Reference IDs:

  • ofid_74a318c6cc709003
  • ofid_f99211da79df5a2e

Affected servers (both independently reachable and functional when tested directly):

Server-side diagnostics:

  • kb-mcp DB shows 6 successful hourly token refreshes yesterday, then stopped cold.

Refresh tokens still valid for 30 days.

  • Both endpoints return proper 401 when tested via curl; servers are healthy.

Pattern suggests client-side OAuth refresh/re-auth is not firing.

Claude Code version: [run claude --version]
Platform: macOS [version]

What Should Happen?

Multiple custom MCP connectors stopped working simultaneously with
"Couldn't reach the MCP server" error.

Reference IDs:

  • ofid_74a318c6cc709003
  • ofid_f99211da79df5a2e

Affected servers (both independently reachable and functional when tested directly):

Server-side diagnostics:

  • kb-mcp DB shows 6 successful hourly token refreshes yesterday, then stopped cold.

Refresh tokens still valid for 30 days.

  • Both endpoints return proper 401 when tested via curl; servers are healthy.

Pattern suggests client-side OAuth refresh/re-auth is not firing.

Claude Code version: [run claude --version]
Platform: macOS [version]

Error Messages/Logs

Multiple custom MCP connectors stopped working simultaneously with 
"Couldn't reach the MCP server" error.

Reference IDs:
- ofid_74a318c6cc709003
- ofid_f99211da79df5a2e

Affected servers (both independently reachable and functional when tested directly):
- https://kb-mcp.koknife.com/mcp — OAuth2 PKCE, supports refresh_token grant
- https://portfolio.koknife.com/mcp — OAuth2 PKCE, authorization_code only

Server-side diagnostics:
- kb-mcp DB shows 6 successful hourly token refreshes yesterday, then stopped cold. 
  Refresh tokens still valid for 30 days.
- Both endpoints return proper 401 when tested via curl; servers are healthy.

Pattern suggests client-side OAuth refresh/re-auth is not firing.

Claude Code version: [run `claude --version`]
Platform: macOS [version]

Steps to Reproduce

  1. Set up a self-hosted MCP server with OAuth2 PKCE authorization (e.g.,

FastMCP or @modelcontextprotocol/sdk with OAuth middleware) behind HTTPS.

  1. Add it as a custom connector in Claude Code via Settings → Integrations,

complete the OAuth authorize flow, and confirm tools appear and work.

  1. Leave the connector idle for longer than the server's access-token TTL

(e.g., >1 hour if TTL is 3600s). Do not interact with Claude Code during
this window.

  1. Return to Claude Code and attempt to use a tool from that connector.

Expected: Claude Code either silently refreshes the access token using
the stored refresh token, or (if the server doesn't support refresh_token)
prompts the user to re-authorize.

Actual: Request fails with toast "Couldn't reach the MCP server. You can
check the server URL and verify the server is running. If this persists,
share this reference with support: 'ofid_...'". No retry, no refresh
attempt observed server-side, no re-auth prompt. Connector appears
permanently stuck until manually removed and re-added.

Reproduces across two independently-implemented servers (different
languages, different transports, different DBs) — one supporting
refresh_token grant, one not — which rules out a single server-side bug.

Server-side verification: curl against the /mcp endpoint with a valid
bearer token succeeds. The servers themselves are reachable and healthy.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Code 2.1.118

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

5 Comments

dselman · 5 months ago

Seeing the same pattern on a self-hosted MCP server (https://api.beau.bot/mcp, OAuth 2.1 PKCE with Auth0 delegation).
Reference: ofid_e7937ea2397f5185. Started ~11:37 UTC today, 26 minutes after this issue was filed — strongly suggests a
shared upstream cause.

Edge HTTP logs confirm the client-side auth flow is dead on arrival:

  • POST /mcp from clientUa: Claude-User, edgeRegion: us-east4-eqdc4a → 401 with a spec-compliant WWW-Authenticate: Bearer

realm="mcp", resource_metadata="https://api.beau.bot/.well-known/oauth-protected-resource" header (per MCP 2025-06-18 §4.3
and RFC 9728).

  • Zero subsequent hits on /.well-known/oauth-protected-resource.
  • Zero hits on /.well-known/oauth-authorization-server (3/26 fallback).
  • Zero hits on /oauth/authorize or /oauth/token.
  • Client silently re-sends the unauthenticated POST a few times and surfaces "Couldn't reach the MCP server" — a misleading

error given every request reaches the server.

Claude Code CLI against the same server continues to work — it completes discovery and OAuth correctly. The bug appears
specific to the Claude.ai / Cowork MCP client path.

dselman · 5 months ago

Follow-up — captured richer data from a fresh Cowork "add connector" attempt. The 401s come from three distinct
clients, not one:

| User-Agent | Method | Edge region | Role (inferred) |
|---|---|---|---|
| Go-http-client/2.0 | HEAD | us-east4, us-west2 | Reachability probe (multi-region) |
| Mozilla/5.0 ... Chrome/147.0.0.0 ... | GET | us-east4 | URL "preview"/validation (spoofed browser UA) |
| Claude-User | POST | us-east4 | Actual MCP client |

Sequence on my server during one connector-add attempt:

``
HEAD /mcp → 401 (Go-http-client, us-east4)
GET /mcp → 401 (Chrome-UA, us-east4)
HEAD /mcp → 401 (Go-http-client, us-west2)
GET /mcp → 401 (Chrome-UA, us-east4)
... ~4 min gap ...
POST /mcp → 401 (Claude-User)
POST /mcp → 401 (Claude-User)
``

Still zero hits on /.well-known/* or /oauth/* from any of the three.

This strongly suggests the "Couldn't reach the MCP server" verdict is rendered by the HEAD/GET validator before the
real MCP client ever evaluates the WWW-Authenticate header. The validator appears to assume 2xx == reachable, anything
else == unreachable, with no awareness that an MCP endpoint returning 401 + WWW-Authenticate is the correct shape for
an unauthenticated spec-compliant server.

Suggested fix at the validator level: treat 401 with a WWW-Authenticate: Bearer header as a successful reachability
outcome (server exists, auth is required). Equivalently, skip the pre-validation HEAD/GET and let the real MCP client
handle it — the MCP client has the context to parse WWW-Authenticate and start the OAuth flow.

Side note on the spoofed Chrome user-agent: probably worth declaring the probe honestly (e.g.
Anthropic-ConnectorValidator/1.0). Server operators can't distinguish a real browser fetch from Anthropic infrastructure
right now, which is awkward for rate-limiting, logging, and WAF rules.

dselman · 5 months ago

It is working again...

localden collaborator · 4 months ago

Thanks for the report. We tracked this down to a server-side change in late April that caused some MCP server connections to be blocked at the network layer. That change was reverted shortly after. If you are still seeing all your custom connectors fail on a current version, please open a new issue with the request ID from the error and we will take another look.

github-actions[bot] · 3 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: Authentication & login failures, MCP server connection issues

Browse all Claude Code issue topics →