Datadog MCP (EU1): OAuth reports success in browser but no token is stored; authorize URL built for US1 host

Summary

Authenticating the Datadog remote MCP server against an EU1 org (datadoghq.eu) never produces a stored token. Datadog's page reports "authentication successful", but Claude Code saves no access or refresh token, and the server stays at "Needs authentication". Repeating /mcp > Authenticate and restarting does not help.

Environment

• Claude Code 2.1.286, macOS (Darwin 25.6.0)
• Server added with: claude mcp add --transport http datadog https://mcp.datadoghq.eu/api/unstable/mcp-server/mcp
• Datadog org on EU1 (app.datadoghq.eu)

Steps to reproduce

1. Add the EU1 Datadog MCP URL above (HTTP transport).
2. Run /mcp, select datadog, Authenticate.
3. Authorize in the browser (logged in to app.datadoghq.eu). The redirect to http://localhost:<port>/callback?...&site=https%3A%2F%2Fapp.datadoghq.eu&domain=datadoghq.eu... shows a success page.
4. Check the server status.

Expected

A token is exchanged and stored; datadog shows as connected and its tools load.

Actual

• claude mcp list still reports ! Needs authentication.
• The macOS keychain entry Claude Code-credentials has a mcpOAuth record for the EU server URL with no access token and no refresh token (checked boolean presence only). Other OAuth servers (Asana, Miro, Notion, Sentry) have tokens.
• The files in ~/Library/Caches/claude-cli-nodejs/<project>/mcp-logs-datadog/ (5 files, covering several attempts) log the authorization URL being built and opened, but never record a callback being received or a token exchange (no exchange success or failure line at all).

Observations that may be relevant

• Even with the server URL set to mcp.datadoghq.eu, the logged authorization URL is https://app.datadoghq.com/oauth2/v1/authorize?...&resource=https%3A%2F%2Fmcp.datadoghq.com%2F... (US1 host and resource), while discovery state logged authServer: https://mcp.datadoghq.eu/v1/mcp. The callback from Datadog then carries site=https://app.datadoghq.eu. This mismatch between the site used to build the authorize URL and the org's actual site may be causing the failure, but I have not confirmed that.
• Client registration is deferred ("No client info found; deferring client registration to authentication time"). The earlier US1 attempts reused a registered port ("reusing registered port"); it is unclear whether stale US1 client info or ports are reused for the EU server.
• Submitting the callback URL via the complete_authentication tool failed with "No OAuth flow is in progress", because the tool's in-memory flow state was from a different attempt. So the manual-paste fallback was not usable either.

Related

• #97282 (MCP OAuth discovery chain not following RFC 9728) may be related to the authorize URL being built on the wrong host, but it describes a different symptom.
• #100238 (preflight ignores stored OAuth token) is a different problem here, since no token is stored at all.