CLI: treat SENTRY_AUTH_TOKEN/SENTRY_TOKEN as another account alongside stored logins #1553

Follow-up from #1537 (review discussion).

Now that the CLI stores several accounts (#1396), SENTRY_AUTH_TOKEN / SENTRY_TOKEN could act as one more account instead of a separate, all-or-nothing mode.

How it works today (packages/cli/src/lib/db/auth.ts)

• Stored credentials win: getAuthToken / getAuthConfig read the stored active account first and only fall back to the env token when nothing stored is usable.
• With SENTRY_FORCE_ENV_TOKEN=1, the env token wins and overrides account selection entirely (selectAccountForOrg and friends skip stored accounts).
• Commands that fan out across accounts (sentry org list) never send an env token to a stored account's server (withStoredAccount drops the env token variables).
• So with both a login and an env token, one of them is ignored for every command. You can't, for example, list the env token's orgs next to your logins' orgs, or have org routing pick the env token for an org only it can reach.

Proposal

• Treat a configured env token as a virtual, read-only account (never stored or persisted), only when its server is known safely:
  • an explicit SENTRY_HOST/SENTRY_URL from the boot env (a trusted source; not .sentryclirc or a URL argument), or
  • SaaS when neither is set.
  • Otherwise keep today's behavior.
• Include it in account selection and org routing (selectAccountForOrg, server-based selection), sentry org list (ACCOUNT column, e.g. env:SENTRY_AUTH_TOKEN), and sentry auth list / status.
• Keep SENTRY_FORCE_ENV_TOKEN meaning "use only the env token".
• Never send the env token to a server other than the one it's scoped to (same trust model as token-host.ts).

Open questions

• Precedence when the env token and the active stored account both reach an org.
• Whether auth switch can select it, or whether it stays implicit.
• Whether to identify it in output with /auth/ user info when available.

via byk.

--

View Junior Session [Sentry]