DesignSync scope error tells user to run /login, but only /design-login can grant design scopes

Feedback: DesignSync error message points to /login, but /login cannot grant design scopes

Summary

When the DesignSync tool lacks design-system scopes, the runtime error instructs the
user to run /login. Following that instruction exactly does not resolve the
failure — /login reports success and the very next DesignSync call fails with the
identical error. The command that actually requests the design scope is
/design-login (confirmed working, see below), which the error text never mentions.

The result is a dead-end loop: the error tells you to do X, X succeeds, the error
repeats unchanged. There is no signal that a different command exists.

Observed behavior

Environment: Claude Code 2.1.177, Linux, npm-global install.

1. Called DesignSync (method: list_projects). Result:

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

1. Ran /login as instructed, selecting the subscription account. CLI reported

Login successful.

1. Retried list_projects. Byte-identical error returned, including the same

instruction to run /login.

At this point the only remaining hypotheses were org-level scope provisioning or
account mismatch — i.e. the error message actively steered diagnosis away from the
real cause. We learned about /design-login from a third party, not from the
product.

Inconsistency between tool description and runtime error

The DesignSync tool description does mention the correct path:

Read and update the user's claude.ai/design design-system projects through their claude.ai login (or, for sessions without one, a dedicated design authorization from /design-login).

But the runtime error emitted on scope failure names only /login. The two
disagree, and the runtime error is the one the user actually sees.

Version availability

/design-login was not available in 2.1.177 (the version that emitted the error
telling the user to fix it with /login). After updating to 2.1.227 the command is
expected to be present.

If a build can emit a scope-failure error while lacking the command that fixes the
scope failure, that error should say so — e.g. "update Claude Code, then run
/design-login" — rather than naming a command that cannot grant the scope.

Suggested fix

1. Change the scope-failure error text to name /design-login, not /login.
2. If the running build predates /design-login, have the error say an update is

required.

1. Consider having /login detect a pending design-scope requirement and either

request the scope inline or point to /design-login on completion.

Confirmed root cause

/design-login is the fix. After updating to 2.1.227 and running it
("Design-system access authorized."), the same list_projects call that had failed
twice returned a normal project list immediately.

So the error message was not merely incomplete — it named a command that cannot grant
the scope, while the command that can was never surfaced. Org-level provisioning was
already in place and was never the problem, but the error text sent us investigating
exactly that for the better part of the session.

Secondary: claude update / npm prefix mismatch

Minor, environment-specific, reporting for completeness. The claude binary resolved
to ~/.npm-global/bin/claude, but npm config get prefix returned /usr. So the
documented update command:

npm install -g @anthropic-ai/claude-code@latest

failed with EACCES: mkdir '/usr/lib/node_modules/@anthropic-ai' — npm tried to
write to a root-owned path while the actual install lived under $HOME. Workaround:

npm install -g --prefix "$HOME/.npm-global" @anthropic-ai/claude-code@latest

A prefix-vs-binary-location mismatch check in claude update (or a note in the
install docs) would turn a confusing permission error into an actionable one. Naively
retrying the failing command with sudo would install a second copy at a path that
shadows or diverges from the existing one.