claude_design MCP OAuth misroutes to Google Drive connector install flow
Status Open
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 5 comments · opened Jun 30, 2026
Summary
Connecting the claude_design MCP server (https://api.anthropic.com/v1/design/mcp) misroutes OAuth into the Google Drive connector's install flow. Authentication never reaches a design consent screen; instead the browser lands on https://api.anthropic.com/mcp/gdrive/google/install?metadata=….
Root cause
The design server's protected-resource metadata advertises the correct authorization server:
GET https://api.anthropic.com/v1/design/.well-known/oauth-protected-resource
{
"resource": "https://api.anthropic.com/v1/design/mcp",
"authorization_servers": ["https://claude.ai/v1/design/mcp"],
"scopes_supported": ["user:design:read", "user:design:write"]
}But OAuth discovery resolves the authorization server to the api.anthropic.com root, and that root's authorization-server metadata is the gdrive connector's:
GET https://api.anthropic.com/.well-known/oauth-authorization-server
{
"issuer": "https://api.anthropic.com/mcp/gdrive",
"authorization_endpoint": "https://api.anthropic.com/authorize",
...
}So design auth is handed off to the Google Drive connector's authorization flow.
Steps to reproduce
- Configure an HTTP MCP server:
{"type": "http", "url": "https://api.anthropic.com/v1/design/mcp"} - Run
/mcpand authenticateclaude_design. - Browser opens
https://api.anthropic.com/mcp/gdrive/google/install?metadata=…(a Google Drive consent screen) instead of a design consent screen.
Notes
- Reproducible across fresh attempts — a new
metadatatoken is generated each time, so it is not a stale-token issue. - No Google Drive connector is enabled on the account.
- Verified client config is correct and cleared all local OAuth state (
mcp-needs-auth-cache.jsonand themcpOAuthcredential entry); the storeddiscoveryStaterecordedauthorizationServerUrl: "https://api.anthropic.com/"with an emptyaccessToken, confirming the flow dies at the authorization step.
This appears to be a server-side gateway misconfiguration rather than a client issue.
5 Comments
Found 2 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Confirming I hit this exact same issue — thanks for already digging into the root cause, it matches what I observed.
Environment:
Claude Code, npm-global install, win32-x64
Claude Team plan (organization account, org UUID resolved via claude /doctor) — not an individual Pro/Free account, so this isn't limited to personal plans
MCP server: claude-design (https://api.anthropic.com/v1/design/mcp)
Reproduction:
/mcp → select claude-design (status failed, not authenticated) → Authenticate
Generated authorize URL: https://api.anthropic.com/authorize?response_type=code&client_id=8f67676b-9be2-47a1-9a8f-13ce9903f91b&code_challenge=...&redirect_uri=http%3A%2F%2Flocalhost%3A...%2Fcallback&state=...
Opening it (default browser, and separately in a fresh private/incognito window — same result both times) lands on https://api.anthropic.com/mcp/gdrive/google/install?metadata=... → "Server Turned Down... use Google Drive in the Claude directory."
Ruled out on my end:
Not a browser cache/session issue (reproduced in a clean private window)
Not a stale-client issue (reproduced on 2.1.156 and again after updating to latest via npm install -g @anthropic-ai/claude-code@latest)
Meanwhile, claude.ai/design itself works fine under the same account (existing projects load and are usable), so the breakage is isolated to the MCP OAuth discovery path you described, not Claude Design access in general. Workaround for anyone stuck: use "Send to Claude Code" from an existing project on claude.ai/design instead of authenticating the connector via /mcp.
Happy to provide more diagnostic output if useful.
I have the same experience as @nicolashubert07-cmd
we ran into the same issue and found a workaround:
https://support.claude.com/en/articles/14604416-get-started-with-claude-design
claude mcp add --scope user --transport http claude-design https://api.anthropic.com/v1/design/mcp
Update: the officially-documented setup path still hits this bug, and the misroute now lands on a decommissioned server.
Per the Claude Design support article (https://support.claude.com/en/articles/14604416-get-started-with-claude-design), the prescribed setup is:
Tested on Claude Code 2.1.210 (newer than the 2.1.156 in earlier reports), fresh user-scope registration, stale OAuth state cleared beforehand.
claude mcp login claude-designopens:So the client still resolves the design server's authorization server to the api.anthropic.com root
/authorizeendpoint — not thehttps://claude.ai/v1/design/mcpthat the server's own protected-resource metadata advertises. This matches the root cause in the original report: the root's/.well-known/oauth-authorization-serverreturns the gdrive connector's metadata ("issuer": "https://api.anthropic.com/mcp/gdrive","authorization_endpoint": "https://api.anthropic.com/authorize"), so design auth is handed to the wrong authorization server.New detail: that authorize endpoint now renders a tombstone page instead of any consent screen:
So the misroute target (the old
/mcp/gdriveconnector) has since been decommissioned and migrated to a Google-hosted URL, and design-connector auth is now being dropped onto a dead endpoint.Summary:
claude mcp add+/design-loginworkaround from the support article does not avoid the misroute — it runs through the same broken discovery.https://api.anthropic.com/.well-known/oauth-authorization-serverstill returns the gdrive issuer, so the gateway hasn't been fixed.authorization_servers: ["https://claude.ai/v1/design/mcp"]; the client just isn't using it.Reproducible across a clean setup on the latest client. Happy to provide more diagnostic output.