Connecting to an MCP server from Claude Desktop fails if user is not logged in to Claude.ai in the browser

[keyton-weissinger]

Issue

(Edit from @crondinini-ant for other users)

When clicking "Connect" on an MCP server in Claude Dekstop, this takes you to claude.ai in the browser.
We identified a bug where this does not work if you are NOT logged in to Claude.ai prior to this.
It also does not work if you are logged in a different account.
We are working on fix, but workaround is to make sure to be logged in to the same account in the browser BEFORE clicking "Connect" in Claude Desktop.

---

Original Reported Issue

MCP server URL

https://app.copient.ai/mcp

Where does the issue occur?

When pressing the Connect button

Transport used

streamable-http

Client registration type

Dynamic Client Registration (DCR)

SSE only: Does your server return the expected status code for POST requests?

Not applicable (my server does not use SSE)

When did you last reproduce this?

2026-02-02 11:00 AM EST

Browser and OS

Chrome on macOS 15.x (Sequoia)

Describe the issue

After adding https://app.copient.ai/mcp as a custom connector in Claude Desktop settings:

1. Discovery succeeds — the button changes from spinner to "Connect", meaning Claude successfully fetched /.well-known/oauth-protected-resource, /.well-known/oauth-authorization-server, and completed DCR registration via POST /mcp/oauth/register.
2. Clicking "Connect" opens the browser to claude.ai/login?returnTo=/api/organizations/{org}/mcp/start-auth/{connector-id}?redirect_url=claude://claude.ai/settings/connectors?&open_in_browser=1
3. The flow stalls at the Claude.ai login/redirect page with a spinner. The authorization flow never reaches our server's /mcp/oauth/authorize endpoint.

The flow DID complete successfully once for a different user session where the browser was already logged into Claude.ai. After that successful connection, attempting to reconnect (after removing the connector) no longer works.

Issue details

Server access logs confirm Claude's infrastructure successfully:

• GET /.well-known/oauth-authorization-server → 200
• GET /.well-known/oauth-protected-resource → 200
• POST /mcp/oauth/register → 201

But then:

• GET /mcp/oauth/authorize → never called
• POST /mcp/oauth/token → never called

Claude's auth proxy appears to get stuck between receiving the DCR registration response and redirecting the user to our authorization endpoint.

When the flow did work once, the authorize URL was:

https://app.copient.ai/mcp/oauth/authorize?response_type=code&client_id=...&redirect_uri=https://claude.ai/api/mcp/auth_callback&code_challenge=...&code_challenge_method=S256&state=...&scope=read:progress+read:assignments+read:analysis+read:conversations+read:meetings+read:team_progress+read:team_analytics+read:clients+read:cross_client_analytics&resource=https://app.copient.ai/mcp

Expected behavior

After clicking "Connect":

1. Claude.ai auth proxy should redirect user to our /mcp/oauth/authorize endpoint
2. User logs into Copient, approves consent
3. Redirect back to Claude.ai with auth code
4. Claude.ai exchanges code for token via POST /mcp/oauth/token
5. Connection established

Logs from your server

# Only these requests appear from Claude's infrastructure:
GET /.well-known/oauth-authorization-server 200
GET /.well-known/oauth-protected-resource 200
POST /mcp/oauth/register 201

# The following NEVER appear:
# GET /mcp/oauth/authorize (user redirect)
# POST /mcp/oauth/token (code exchange)

Additional context

OAuth metadata (verified live at https://app.copient.ai/.well-known/oauth-authorization-server):

{
  "issuer": "https://app.copient.ai",
  "authorization_endpoint": "https://app.copient.ai/mcp/oauth/authorize",
  "token_endpoint": "https://app.copient.ai/mcp/oauth/token",
  "registration_endpoint": "https://app.copient.ai/mcp/oauth/register",
  "token_endpoint_auth_methods_supported": ["none"],
  "code_challenge_methods_supported": ["S256"],
  "grant_types_supported": ["authorization_code"],
  "response_types_supported": ["code"]
}

This is the same pattern reported by multiple developers in #5 — particularly the report from @paulditerwich showing that Claude.ai receives the auth callback with ?code=... but never calls the /token endpoint, and the reports from @francisbrero and @Hulupeep showing similar flows.

The server works correctly when tested end-to-end via curl and with manual OAuth flows. The issue appears to be in Claude's auth proxy between DCR completion and the authorization redirect.

[crondinini-ant]

@keyton-weissinger Thank you for the report. I was able to replicate this now while being logged out of Claude.ai.

From what I understand, the workaround that works here is to be logged in to Claude.ai prior to clicking Connect in Claude Desktop. Could you confirm if that's the case? Does it work for you if you log into Claude.ai before clicking Connect from Claude Desktop?

[keyton-weissinger]

@crondinini-ant

Yes, being logged into claude.ai before clicking Connect does fix the original connection issue (no more spinner/stuck page).

However, there's a follow-up problem: the connector appears to reuse a previous authorization from an earlier session where I connected as a different user. The consent screen on our server is never shown - Claude skips the OAuth flow entirely and immediately shows "Configure." When I then use the connector, it operates as the wrong Copient user (from that earlier session).

Is there a way to force a fresh OAuth flow / clear cached tokens in Claude Desktop? Our server's authorize endpoint always requires explicit consent, so this caching appears to be on Claude's side.

[crondinini-ant]

@keyton-weissinger I don't think we hold oauth state for a long time. If there's an issue there, I would say the easiest workaround here is to connect to the incorrect user, and then click "Disconnect".

I will create an issue to investigate this other behavior you have mentioned.

[jzwick-narmi]

I just want to confirm that I am having the exact same issue, where DCR succeeds and the authorize call is never attempted. I haven't been able to get the workaround mentioned in this thread to work for me, however.

[crondinini-ant]

@jzwick-narmi If this is for another server, please open a new Auth Connection Issue.

[keyton-weissinger]

@crondinini-ant Just checking on this ticket. Is this still in progress? Any ETA? And thank you as always!

[crondinini-ant]

@keyton-weissinger The pending issue was related to the cached user, right? I was not able to replicate your issue in regards to that. However, I put forward a general fix in the auth flow in regards to caching which maybe solved your issue.
Are you still able to replicate the issue? If so, could you give me some more details so I can put this in our backlog to check?

[crondinini-ant]

If you are referring to the original issue where you can't connect to a server unless you're logged in in the browser, we are working on fix. Specifically @jerome3o-anthropic is.