[Bug] Claude Desktop (Windows) OAuth token lacks user:design:read/write scopes — /design-sync (DesignSync tool) cannot be authorized; no in-app grant path

Summary

On Claude Desktop (Windows), the embedded Claude Code OAuth token is issued without the design-system scopes user:design:read and user:design:write. As a result the built-in DesignSync tool — which the /design-sync skill depends on — fails its authorization check on every invocation (including read-only list_projects), and /design-sync cannot be used from the desktop app at all.

The tool's only scope-elevation path is /design-login, which requires an interactive terminal that the desktop app does not provide, so there is no in-app route to grant the scopes. Signing out and back in re-issues a token with the same (design-less) scope set.

Note: the Claude Design webview experience authenticates and renders normally (projects load and serve), so this is not "design is broken" — it is specifically the agent/tool OAuth token missing the design scopes, plus the absence of any desktop surface to add them.

This is very likely the same root cause as #69324 (the injected claude_design MCP at https://api.anthropic.com/v1/design/mcp returning HTTP 401): a token lacking user:design:* is rejected by anything design-scoped — there it surfaces as the MCP handshake 401 (macOS CLI), here as the DesignSync tool refusing to run (Windows Desktop).

Environment

• Platform: Windows
• Claude Desktop version: 1.15962.0 (039543) 2026-06-25
• Embedded Claude Code: 2.1.187
• Plan: Max

Steps to reproduce

1. In Claude Desktop, run /design-sync (or otherwise trigger any DesignSync tool call, e.g. list_projects).
2. Observe the tool fails with an authorization error.
3. Inspect the OAuth scopes in C:\Users\<user>\.claude\.credentials.json → claudeAiOauth.scopes.

Expected

The token includes user:design:read (and user:design:write for sync-back), or the desktop app surfaces an in-app consent to add them on first DesignSync use, so /design-sync can authenticate without an interactive /design-login.

Actual

• DesignSync returns, on every call:

> DesignSync needs design-system authorization, but /design-login requires an interactive terminal and is not available in this environment.

• Token scopes after sign-in contain no design scope. Observed scope sets (from the desktop OAuth lookups in %APPDATA%\Claude\logs\main.log):
• user:inference user:file_upload user:profile user:sessions:claude_code
• (a separate org token) user:inference user:office
• read-only DesignSync(list_projects) — which needs user:design:read — fails immediately.
• The desktop app exposes no interactive terminal, so /design-login cannot be run; sign-out / sign-in does not change the scope set.

Root cause / diagnosis

• The required scopes are confirmed from the embedded /design-login flow strings in claude.exe 2.1.187:

> "Added user:design:read and user:design:write to your claude.ai login…"
> "…include design-system access (user:design:read, user:design:write). This lets /design-sync read…"

• The desktop OAuth client does not request user:design:read / user:design:write during its auth flow, and provides no interactive surface to run the /design-login grant — so the scopes can never be added from the desktop app.

Suggested fix

Any of:

• Have the desktop OAuth flow request user:design:read (and user:design:write) for Max accounts, or
• Surface an in-app consent dialog to add the design scopes on first DesignSync//design-sync use (the tool's spec already describes "may prompt to add design-system access to the claude.ai login" — that prompt does not appear in the desktop app), or
• Provide a non-terminal authorization path equivalent to /design-login in the desktop UI.

Related

• #69496 — "[Feature Request] Add user:design OAuth scopes to Claude Code authentication": same DesignSync failure and same missing user:design:read / user:design:write scopes on macOS CLI. Notably, there even a real-terminal /login refresh succeeds but the design scopes are still not granted ("refresh succeeded but design scopes not granted") — evidence the OAuth flow itself isn't requesting/granting them, independent of the desktop-app terminal limitation.
• #69324 — injected claude_design MCP 401s; likely the same missing-user:design:*-scope root cause, manifesting on a different surface/platform.