follow up on claude code oauth scopes

[phernandez]

see: anthropics/claude-code#4540

Scope handling for MCP OAuth is now explicit and documented at https://code.claude.com/docs/en/mcp#restrict-oauth-scopes:

You can pin exactly what is requested with "oauth": { "scopes": "mcp:read mcp:write" } on the server entry (space-separated, RFC 6749 §3.3 format); this takes precedence over anything discovered.
Without it, current versions request the scope named by the server's WWW-Authenticate challenge or its protected-resource metadata, and deliberately no longer request the whole scopes_supported catalog from discovered authorization-server metadata (that caused invalid_scope rejections on several IdPs). If neither source names a scope, no scope parameter is sent — so for a setup like the one described (scopes advertised only via AS discovery), either set oauth.scopes or have the MCP server advertise its scopes in its protected-resource metadata / 401 challenge.
offline_access is appended automatically when the authorization server advertises it, so refresh works without a new sign-in.

[claude]

Claude finished @phernandez's task in 1m 21s —— View job

---

Triage

• Type: Bug — labeled bug
• Component: Cloud (MCP OAuth flow for the hosted/remote MCP endpoint) — labeled cloud
• Priority: Medium — no immediate breakage for existing sessions, but users connecting Claude Code to the basic-memory cloud MCP endpoint could silently get no scope requested at all if neither oauth.scopes is pinned client-side nor the server advertises a scope via its 401 challenge / protected-resource metadata, which can surface as invalid_scope or missing-permission failures on some IdPs.
• Complexity: Medium — mostly investigation. This repo's local MCP server (src/basic_memory/mcp/server.py) instantiates FastMCP(...) with no auth= config, so it isn't a protected resource itself and doesn't emit WWW-Authenticate or protected-resource metadata. The bm cloud login flow (src/basic_memory/cli/auth.py) uses a separate, unrelated WorkOS device-auth flow with a hardcoded scope: "openid profile email offline_access" — not the MCP OAuth resource-server flow described in the linked upstream issue. The actual OAuth-protected MCP gateway that Claude Code would connect to as a remote MCP client lives in the basic-memory-cloud service, not in this repository, so the concrete fix (advertising scopes via WWW-Authenticate / .well-known/oauth-protected-resource, or documenting oauth.scopes as a required client-side setting) likely belongs there.

No duplicate open issues found in this repo for MCP OAuth scope handling.

Suggested next step: confirm with the basic-memory-cloud MCP gateway whether it advertises scopes via the 401 challenge or protected-resource metadata; if not, either add that advertisement or document that users must set "oauth": { "scopes": "..." } in their MCP client config per https://code.claude.com/docs/en/mcp#restrict-oauth-scopes.