Summary

gog intermittently returns a 403 insufficient scopes (Request had insufficient authentication scopes) on a call that then succeeds on an immediate retry with the same stored refresh token, no re-auth and no consent change. The error wording strongly implies a stale login / missing scope, which leads operators to re-authenticate — but re-auth changes nothing, because the scope was never actually missing.

Observed

• Build: 0.31.1 (Homebrew), keyring backend keychain, single OAuth account.
• Two different services hit it in one session:
  • gog calendar create <cal> --summary … --with-meet → 403 insufficient scopes. Retried minutes later, same token, → success (Meet conference created).
  • gog contacts search <q> → 403 insufficient authentication scopes. Retried later, same token, → results returned.
• Sibling operations on the same service worked throughout (e.g. bare calendar create without --with-meet, and contacts list), so the token plainly held the scopes.
• Debug logs around the failing calls show per-call scoped-token minting:

  level=DEBUG msg="creating client options with custom scopes" serviceLabel=calendar …
  level=DEBUG msg="client options with custom scopes created successfully" …
  

Hypothesis

The per-service custom-scope access-token mint occasionally yields a token that the API rejects as under-scoped on first use, and a fresh mint on retry resolves it (a mint/propagation race). The 403 is transient, not a genuine scope gap.

Question / request

Should the per-service token-mint path retry once internally on a 403 insufficient scopes (or refresh-then-retry) before surfacing it? At minimum, could the surfaced error distinguish "token genuinely lacks scope X" from "transient mint failure" so callers don't reflexively re-authenticate?

Happy to capture fuller debug output if useful.