setup-token intermittently issues CLI OAuth tokens missing user:sessions:claude_code, blocking Routines/RemoteTrigger — account-wide, mechanism-independent

claude setup-token mints a long-lived CLI OAuth token. On my account, this
has repeatedly produced tokens missing the user:sessions:claude_code
scope, which /v1/code/* (Routines management, the RemoteTrigger tool)
requires. The resulting token authenticates fine for plain inference but
401s oauth_scope_insufficient on any routines-related call.

Evidence, in order of investigation:

1. Listed the account's live OAuth tokens via the tokens API: 228 live

tokens, only 54 ever carried user:sessions:claude_code. The six most
recent (one rotation's worth) carried only user:ccr_inference
user:file_upload or bare user:inference.

1. Ruled out account/org-level causes: the Routines admin toggle is on,

connector permissions don't apply to the CLI, plan tier isn't gating it.

1. Re-minted multiple times over several days — most attempts still produce

a scope-deficient token. One mint via a private/incognito browser window
appeared to pass our own verification, but that verification itself had
a bug (see #4) — so incognito is not a confirmed fix.

1. Reproduced completely independent of any of our own tooling: a plain

claude session with zero custom scripting or env injection, freshly
opened outside our usual setup, showed authMethod: "oauth_token" and
got the identical 401 oauth_scope_insufficient calling RemoteTrigger.

1. Most notable finding: the same token, used two different ways seconds

apart, gave different results. A one-shot claude -p call with the
token passed a strict check (confirmed via the actual JSON result
object, is_error: false). Seconds later, a separate live interactive
session using the same freshly-minted token (fetched via the identical
code path) got 401 oauth_scope_insufficient calling the same tool.
Same credential, same account, different outcome depending on call
shape (one-shot vs. session-based).

Ask: is setup-token's granted scope set supposed to be deterministic?
What determines it — and could there be a propagation delay or
inconsistency between how a freshly-granted scope is evaluated for a
one-shot API call versus a persistent session? A pointer to what's going
on, or a workaround, would be appreciated — this blocks all CLI-driven
Routines management on the account.