MCP OAuth: a sign-in for the wrong workspace is refused forever #1609

What happens

A person has two workspaces, each created with a different Google account. They add the MCP URL of a server in workspace B to Claude, but they complete the OAuth sign-in with the account of workspace A.

The consent page issues a token anyway. On every call, mcp-endpoint.controller.ts (the isMember check, around line 1310) answers 403 with JSON-RPC error -32001: "this sign-in or API key belongs to a different workspace than this MCP server".

Clients do not run OAuth again after a 403. Claude keeps sending the same token, so the user cannot fix it from the client. On Cloud we saw one user refused 510 times in 13 hours, with no successful call on that server.

Proposal

Two small changes. Both touch authentication, so I want to agree on them before writing code.

1. At consent. When the resource of /authorize names one MCP server (/mcp/<serverId>) and the signed-in user is not a member of that server's workspace, do not issue the token. Show a clear page instead: "This server belongs to workspace B. You are signed in to workspace A. Sign in with another account." with a button to switch accounts. This also covers users with several memberships who pick the wrong one.
2. At the MCP endpoint. For a JWT (OAuth) caller who is not a member, answer 401 with WWW-Authenticate: Bearer error="invalid_token", resource_metadata="..." instead of 403. Clients then start OAuth again and the user can pick the right account. API keys keep the 403, because a new sign-in would not help them.

Notes

• Self-hosted: same behaviour. It matters for instances with more than one workspace.
• No Prisma change. Nothing under ee/.
• Tests: consent refused for a non-member and allowed for a member of the server's workspace; endpoint returns 401 plus the header for a non-member JWT and still 403 for an API key from another workspace.