Skip to content

follow up on claude code oauth scopes #1283

Open
Open
follow up on claude code oauth scopes#1283
Labels
bugSomething isn't workingcloudBasic Memory Cloud

Description

@phernandez
phernandez
opened on Aug 19, 2026

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.

Activity

  1. phernandez
    added
    bugSomething isn't working
    on Aug 19, 2026

  2. claude commented on Aug 19, 2026

    @claude
    claudebot
    on Aug 19, 2026 – with Claude
    Contributor

    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.

  3. claude
    added
    cloudBasic Memory Cloud
    on Aug 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingcloudBasic Memory Cloud

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions