claude-code - 💡(How to fix) Fix MCP OAuth: 'Server not found' when re-adding remote MCP server after deploy [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#45533Fetched 2026-04-09 08:03:11
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
0
Timeline (top)
commented ×1labeled ×1

After redeploying a remote MCP server (ECS Fargate), existing Claude.ai MCP sessions are invalidated (in-memory sessions lost). When attempting to re-authenticate via Claude.ai settings, the OAuth flow fails with "Server not found" — the error comes from Claude.ai's own API before reaching the MCP server.

The MCP server itself is working correctly — other users can connect through Claude.ai, and the mcp-remote stdio bridge works perfectly. The issue is specific to re-adding/re-authenticating a previously registered server.

Error Message

After redeploying a remote MCP server (ECS Fargate), existing Claude.ai MCP sessions are invalidated (in-memory sessions lost). When attempting to re-authenticate via Claude.ai settings, the OAuth flow fails with "Server not found" — the error comes from Claude.ai's own API before reaching the MCP server. 7. Response: {"type":"error","error":{"type":"not_found_error","message":"Server not found","details":{"error_visibility":"user_facing"}}}

Error details

  • Error ref: ofid_68715e5bb05af235
  • Browser URL: claude.ai/settings/mcp/auth_error → "An unknown error occurred during authentication"

Root Cause

After redeploying a remote MCP server (ECS Fargate), existing Claude.ai MCP sessions are invalidated (in-memory sessions lost). When attempting to re-authenticate via Claude.ai settings, the OAuth flow fails with "Server not found" — the error comes from Claude.ai's own API before reaching the MCP server.

The MCP server itself is working correctly — other users can connect through Claude.ai, and the mcp-remote stdio bridge works perfectly. The issue is specific to re-adding/re-authenticating a previously registered server.

Fix Action

Workaround

Using mcp-remote as a stdio bridge bypasses Claude.ai's OAuth proxy entirely:

{
  "mcpServers": {
    "my-server": {
      "type": "stdio",
      "command": "npx",
      "args": ["mcp-remote", "https://my-mcp-server.example.com/"]
    }
  }
}

Code Example

{
  "mcpServers": {
    "my-server": {
      "type": "stdio",
      "command": "npx",
      "args": ["mcp-remote", "https://my-mcp-server.example.com/"]
    }
  }
}
RAW_BUFFERClick to expand / collapse

Summary

After redeploying a remote MCP server (ECS Fargate), existing Claude.ai MCP sessions are invalidated (in-memory sessions lost). When attempting to re-authenticate via Claude.ai settings, the OAuth flow fails with "Server not found" — the error comes from Claude.ai's own API before reaching the MCP server.

The MCP server itself is working correctly — other users can connect through Claude.ai, and the mcp-remote stdio bridge works perfectly. The issue is specific to re-adding/re-authenticating a previously registered server.

Steps to reproduce

  1. Add a remote MCP server with OAuth to Claude.ai (e.g. https://mcp.invertironline.com/)
  2. Deploy a new version of the server (ECS task restart → in-memory sessions lost)
  3. Existing connection breaks with "Session not found"
  4. Remove the MCP server from Claude.ai settings
  5. Re-add the same URL
  6. Click Authenticate → browser opens to claude.ai/api/organizations/<org>/mcp/start-auth/mcpsrv_<id>?product_surface=cli
  7. Response: {"type":"error","error":{"type":"not_found_error","message":"Server not found","details":{"error_visibility":"user_facing"}}}

Repeated 10+ times with the same result. Tried different server names, incognito window, etc.

Error details

  • Error ref: ofid_68715e5bb05af235
  • Request ID: req_011CZsGZa8BoTJqh4894ggq4
  • Server URL: https://mcp.invertironline.com/
  • Browser URL: claude.ai/settings/mcp/auth_error → "An unknown error occurred during authentication"

What works

  • The MCP server responds correctly to all OAuth endpoints (/.well-known/oauth-protected-resource, /.well-known/oauth-authorization-server, /register, /authorize, /token)
  • Other Claude.ai users can connect to the same server through the Claude.ai proxy
  • mcp-remote (stdio bridge) handles OAuth locally and works perfectly as a workaround
  • E2E tests pass (full OAuth flow + MCP tool calls)

Workaround

Using mcp-remote as a stdio bridge bypasses Claude.ai's OAuth proxy entirely:

{
  "mcpServers": {
    "my-server": {
      "type": "stdio",
      "command": "npx",
      "args": ["mcp-remote", "https://my-mcp-server.example.com/"]
    }
  }
}

Environment

  • Claude Code CLI v2.1.96
  • macOS Darwin 25.3.0
  • MCP server: FastMCP on ECS Fargate, OAuth 2.1 with PKCE

🤖 Generated with Claude Code

extent analysis

TL;DR

The most likely fix is to implement a mechanism to handle expired or invalidated sessions after redeploying the MCP server, potentially by updating the OAuth flow to account for session losses.

Guidance

  • Investigate Claude.ai's OAuth API documentation to see if there are any specific requirements or recommendations for handling session invalidation after server redeployment.
  • Verify that the MCP server's OAuth endpoints are correctly configured and responding as expected, particularly after redeployment.
  • Consider implementing a workaround similar to the mcp-remote stdio bridge, which bypasses Claude.ai's OAuth proxy, to mitigate the issue until a permanent fix is found.
  • Review the E2E tests to ensure they cover the scenario of redeploying the MCP server and re-authenticating via Claude.ai settings.

Example

No code example is provided as the issue does not imply a specific code change, but rather a potential issue with the OAuth flow or session handling.

Notes

The issue seems to be specific to the interaction between Claude.ai's OAuth proxy and the MCP server, and may require coordination with Claude.ai's support or documentation to resolve.

Recommendation

Apply workaround: Using mcp-remote as a stdio bridge, as described in the issue, appears to bypass the problem with Claude.ai's OAuth proxy, allowing users to connect to the MCP server. This workaround can be used until a more permanent solution is found and implemented.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING