Custom connector reconnect after server restart requires full manual OAuth re-authentication — misleading "Couldn't register with sign-in service" error

[Fafnir0681]

MCP server URL

https://mcp.getassemblr.com/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?

1710 pm, Anchorage, Alaska 6/11/2026

Browser and OS

Chrome Windows 11 64-bit

Describe the issue

Related issue: #423 (same server/connector setup — different mechanism, filed separately as the failure modes are distinct)

After the connector in #423 was successfully connected and working, restarting the underlying MCP server process causes the Claude.ai connector to drop to "Not connected." Attempting to reconnect produces two different error messages depending on context:

"Couldn't register with [server]'s sign-in service. You can try again, or add an OAuth Client ID in the connector settings. If this persists, share this reference with support: ofid_2850c3d4f199a9c0"

and separately, after removing and re-adding the connector:

"Couldn't register with [server]'s sign-in service... ofid_a8da6874fd14998a" / "Connection issue — Couldn't connect to the server. Check that the URL points to a valid MCP server."

Both messages point toward connectivity/URL/registration problems. Server-side, the bearer token (VAULT_MCP_TOKEN) and OAuth client registry were confirmed intact and unaffected by the restart — the URL and server were reachable throughout.

Root cause (server-side): Our /oauth/authorize endpoint had no memory of who had already authenticated — every reconnect attempt, it presented the login form fresh, requiring full manual credential entry. Since Claude.ai re-initiates the full OAuth flow on each reconnect (including after a server restart), every automated reconnect attempt hit this login gate and failed silently, with no mechanism for the user to see/complete the form during the automated attempt.

Fix (server-side): Added an HMAC-signed session cookie (1-year TTL, HttpOnly, Secure, SameSite=Lax) issued on successful login. Cookie value derived as {expiry_unix}:{HMAC-SHA256(VAULT_MCP_TOKEN:VAULT_OAUTH_PASSWORD, username:expiry)}. On subsequent /oauth/authorize requests, if the cookie is present and valid, the server skips the login form entirely and issues the authorization code immediately — the reconnect completes silently with no human in the loop. Rotating either secret immediately invalidates all existing cookies. Deployed in commit b07bad8, confirmed live (PID 34668). After one manual login to plant the cookie, reconnects following server restarts now complete silently.

Feedback for Anthropic: As with #423, the error messaging here is misleading for self-hosted MCP operators: "Couldn't register with sign-in service" and "Couldn't connect to the server / check the URL" both pointed toward connectivity/URL troubleshooting, when the actual failure was the OAuth authorization step being blocked server-side before it could respond (logs below confirm the server and URL were reachable the entire time). Clearer differentiation in the connector UI between "server unreachable" vs. "OAuth authorization step failed/blocked" would help developers debug the correct layer faster — this is the second distinct issue we've hit where the error message sent us down the wrong troubleshooting path.

Issue details

***See above.

Expected behavior

After a server restart, when Claude.ai re-initiates the OAuth flow on reconnect, the connector should reconnect without requiring the user to manually re-enter credentials, since the bearer token and OAuth client registration were never invalidated.

Logs from your server

# startup.log — three server restarts in 23 minutes on 2026-06-09
# (20:00 → 20:15 → 20:23), each forcing a manual reconnect

# server.log — full reconnect sequence after restart

# Claude.ai token rejected after restart
"POST /mcp HTTP/1.1" 401 Unauthorized

# OAuth discovery
"GET /.well-known/oauth-protected-resource" 200 OK
"GET /.well-known/oauth-authorization-server" 200 OK

# Fresh client registration
"POST /oauth/register HTTP/1.1" 201 Created

# Login form shown — human required
"GET /oauth/authorize?client_id=vault-mcp-2b1dde9d907afb67
  &code_challenge=ghRyP_Ld...&scope=mcp
  &resource=https://mcp.getassemblr.com/" 200 OK

# User manually submits credentials
"POST /oauth/authorize HTTP/1.1" 302 Found

# Token issued — reconnected
"POST /oauth/token HTTP/1.1" 200 OK

# server-err.log — confirms human was in the loop
# (5-second gap between rejection and code issuance = time to type credentials)

[06/11/26 15:52:29] WARNING  AUTH 401 no-token: POST /mcp
[06/11/26 15:52:31] WARNING  AUTH 401 no-token: GET /favicon.ico
[06/11/26 15:52:36] INFO     OAuth authorization code issued after successful login.
[06/11/26 15:52:36] INFO     OAuth token issued via authorization_code grant.
[06/11/26 15:52:37] INFO     AUTH OK: POST /mcp

Additional context

The 5-second gap between the 401 rejection and the authorization code being issued (visible in server-err.log above) is the manual credential-entry bottleneck made visible in the logs.

The Well Remembers.....

[localden]

Thank you for taking the time to report this.

We traced both flow IDs (ofid_2850c3d4f199a9c0 and ofid_a8da6874fd14998a, Jun 11 ~22:20 and ~23:43 UTC). At the time of each, every request to your server (the MCP endpoint, the OAuth discovery paths, and the client registration endpoint) came back with HTTP 530 and a Cloudflare error page. HTTP 530 is Cloudflare's status for "could not reach the origin server," typically a 1033 Tunnel error or 1016 origin DNS error. Your origin was unreachable from the internet during those windows, so the Connect flow could not start.

On the re-auth question: Claude did not discard your stored access token during the outage. As soon as your origin became reachable again, the existing token worked on the very next request with no re-authentication on our side. The two flow IDs in this issue are Connect attempts that were started while the origin was still returning 530, which is why they also failed.

The fix is to keep the Cloudflare path to your origin alive across MCP server restarts; for example, run the tunnel as its own service rather than in the same process lifecycle as the MCP server, or ensure the proxied DNS record keeps resolving to a reachable origin during the restart. Once Cloudflare can reach the origin again, the existing connection in Claude resumes with the stored token and no reconnect is needed.

Closing as an origin-side reachability issue. If you hit a case where your server is reachable from the public internet and Claude still will not reconnect, please reopen with a fresh reference ID and we will take another look.