[Feature Request] Add user:design OAuth scopes to Claude Code authentication

Still reproducible on Claude Code 2.1.172 (macOS, personal Max plan, Denmark).

Repro:

1. Fresh /login succeeds. Token scopes afterwards: user:file_upload, user:inference, user:mcp_servers, user:profile, user:sessions:claude_code — no user:design:*.
2. Any DesignSync call (e.g. list_projects) fails with:

> DesignSync needs a claude.ai login. Could not add design scopes to the token. Run /login and retry. (Request failed with status code 400)

1. Re-running /login does not change the granted scopes, so the retry loop never converges.

So the on-the-fly scope-upgrade endpoint 400s for accounts that should have Claude Design access (browser access to claude.ai/design works fine on this account). Would be great to get user:design:read/user:design:write included in the Claude Code OAuth grant or the upgrade endpoint fixed.

Possibly related: the claude_design MCP server's OAuth flow is also broken for a different reason — https://api.anthropic.com/.well-known/oauth-authorization-server currently advertises "issuer": "https://api.anthropic.com/mcp/gdrive" (the decommissioned Google Drive server), so its authorize URLs land on the "Server Turned Down" HTTP 410 page. Filing that separately.

Also reproducible for me on Claude Code 2.1.170 (macOS, Team plan Premium seat, Ukraine).

Repro:

1. Fresh /login succeeds ("Login successful"). Token scopes afterwards: user:file_upload, user:inference, user:mcp_servers, user:profile, user:sessions:claude_code — no user:design:*.
2. Any DesignSync call (e.g. list_projects) fails with:

``
DesignSync needs a claude.ai login. Could not add design scopes to the token. Run /login and retry. (Request failed with status code 400)
``

1. Re-running /login and fully restarting the CLI both make no difference — the granted scope set is identical after every login, so the suggested retry never converges.

Browser access to claude.ai/design works fine on this account (created several design projects with it the same day), so the account is eligible — the failure is on the Claude Code OAuth grant / scope-upgrade side. Would be great to get user:design:read / user:design:write added to the Claude Code OAuth grant, or the upgrade endpoint fixed.

Confirming this on Windows with a Max plan and Claude Code 2.1.251 (newer than the 2.1.162 in the report). My token carries the exact same five scopes, in the same order:

user:file_upload  user:inference  user:mcp_servers  user:profile  user:sessions:claude_code

While debugging I think I found the mechanism, so adding it here rather than opening another issue.

The protected-resource metadata is not where the client looks for it

RFC 9728 puts the document at the origin root, path-suffixed. Measured just now:

| URL | Status |
|---|---|
| api.anthropic.com/.well-known/oauth-protected-resource/v1/design/mcp | 404 |
| api.anthropic.com/.well-known/oauth-protected-resource/v1/design | 404 |
| api.anthropic.com/.well-known/oauth-protected-resource | 404 |
| api.anthropic.com/v1/design/.well-known/oauth-protected-resource | 200 |
| mcp.linear.app/.well-known/oauth-protected-resource/mcp (working server, for contrast) | 200 |

The Design document sits inside the path rather than at the origin root. The WWW-Authenticate header on a 401 does advertise the correct location:

Bearer resource_metadata="https://api.anthropic.com/v1/design/.well-known/oauth-protected-resource",
       scope="user:design:read user:design:write"

but discovery does not appear to follow it.

What that leaves in .credentials.json

Working servers store a resolved metadata URL. claude_design stores a failure:

// plugin:design:linear  — works
"discoveryState": { "authorizationServerUrl": "https://mcp.linear.app",
                    "resourceMetadataUrl": "https://mcp.linear.app/.well-known/oauth-protected-resource/mcp",
                    "oauthMetadataFound": true }

// plugin:design:asana   — works
"discoveryState": { "authorizationServerUrl": "https://app.asana.com",
                    "resourceMetadataUrl": "https://mcp.asana.com/.well-known/oauth-protected-resource/v2",
                    "oauthMetadataFound": true }

// claude_design         — fails
"discoveryState": { "authorizationServerUrl": "https://api.anthropic.com/",
                    "oauthMetadataFound": false }

No resourceMetadataUrl at all, and it falls back to the origin root as the authorization server. The client then builds https://api.anthropic.com/authorize?..., which serves the "Sign-in endpoint retired" page — the same decommissioned endpoint reported in #77620. So the browser flow can never complete, the token never gains user:design:*, and every request comes back:

{"error":"needs_design_scopes",
 "scopes":["user:design:read","user:design:write"],
 "prompt":"This token doesn't include Claude Design access. ...
           Retrying or refreshing the current sign-in won't fix this."}

The correct chain, if discovery reached it, is:
/v1/design/.well-known/oauth-protected-resource → claude.ai/v1/design/mcp → authorization_endpoint: https://claude.ai/oauth/authorize.

Deleting the cached entry does not help

I removed the claude_design entry from mcpOAuth and retried. It is rebuilt with a fresh client_id and callback port and the same oauthMetadataFound: false. This is a repeatable discovery failure, not a poisoned cache.

Two smaller things that make this hard to self-diagnose

1. The remediation text names a command that does not exist. Errors and claude mcp get claude_design say "Run /design-login". That command is not registered in 2.1.251 — typing it does nothing. /design login reaches the bundled design-canvas skill, which replies that Claude Design account commands are not handled in this preview. So the advertised fix is unreachable by either spelling.
2. Discovery is also intermittently Cloudflare-challenged. claude.ai/v1/design/mcp/.well-known/openid-configuration returned 200 on 11 of 12 requests and a cf-mitigated: challenge 403 on one, from a plain non-browser client. Minor next to the path issue, but it would make any retry flaky.

Ask

Either serve the protected-resource document at the RFC 9728 location, or have discovery honour the resource_metadata value from WWW-Authenticate. Fixing the remediation string to name a command that exists would help separately.

Happy to supply request IDs or the full discovery trace if useful.