Problem
Users coming from the old sentry-cli binary already have a working .sentryclirc config file — a token, a self-hosted URL, maybe an org and project — and it represents a relationship with Sentry they've already established. The new CLI does read this file for API calls (token → SENTRY_AUTH_TOKEN, URL → SENTRY_URL), but that happy path is invisible. The moment a user tries to formalize their session with sentry auth login, things fall apart.
Self-hosted is the sharpest edge
For self-hosted users, sentry auth login rejects URLs that arrived via .sentryclirc without an explicit --url flag (by design — it's a security boundary). But the user doesn't know the URL came from their rc file, so the refusal feels random. They have to rediscover the right incantation (sentry auth login --url <host>) through trial and error.
The "it just works" moment never arrives
Even on SaaS, a user with a token in .sentryclirc still has to go through an interactive OAuth flow to populate the new DB-backed credential store. There is no path from "I have a working .sentryclirc" to "I'm set up with the new CLI" that doesn't require looking things up.
Concrete symptoms
sentry auth login against a self-hosted instance → confusing trust-refusal error with no mention of .sentryclirc as the sourcesentry auth login on a machine with a valid token already in ~/.sentryclirc → full OAuth flow anyway, no hint that a token is available- No discovery: users don't know what the new CLI has already read from their rc file
- No migration path: no command that says "here's what I found, want me to set it up?"
Two directions worth exploring
1. Explicit: sentry cli migrate
A command that reads .sentryclirc (local walk-up + global ~/.sentryclirc), shows what it found (URL, masked token, org, project), and migrates it in one step — auth token into the DB, org/project into defaults. Opt-in, transparent, auditable.
2. Automatic / zero-friction
Detect an unauthenticated session where .sentryclirc has a valid-looking token and prompt inline — "Found a token in .sentryclirc at ~/.sentryclirc — use it? [Y/n]" — on first use of any command that needs auth. No separate command needed; the migration happens at the moment the user would have hit an auth error anyway. This is the god-tier version: users who didn't even know there was a migration to do get silently shepherded across.
These aren't mutually exclusive — explicit migrate for power users who want control, auto-detect as the default for everyone else.
Problem
Users coming from the old
sentry-clibinary already have a working.sentryclircconfig file — a token, a self-hosted URL, maybe an org and project — and it represents a relationship with Sentry they've already established. The new CLI does read this file for API calls (token →SENTRY_AUTH_TOKEN, URL →SENTRY_URL), but that happy path is invisible. The moment a user tries to formalize their session withsentry auth login, things fall apart.Self-hosted is the sharpest edge
For self-hosted users,
sentry auth loginrejects URLs that arrived via.sentryclircwithout an explicit--urlflag (by design — it's a security boundary). But the user doesn't know the URL came from their rc file, so the refusal feels random. They have to rediscover the right incantation (sentry auth login --url <host>) through trial and error.The "it just works" moment never arrives
Even on SaaS, a user with a token in
.sentryclircstill has to go through an interactive OAuth flow to populate the new DB-backed credential store. There is no path from "I have a working.sentryclirc" to "I'm set up with the new CLI" that doesn't require looking things up.Concrete symptoms
sentry auth loginagainst a self-hosted instance → confusing trust-refusal error with no mention of.sentryclircas the sourcesentry auth loginon a machine with a valid token already in~/.sentryclirc→ full OAuth flow anyway, no hint that a token is availableTwo directions worth exploring
1. Explicit:
sentry cli migrateA command that reads
.sentryclirc(local walk-up + global~/.sentryclirc), shows what it found (URL, masked token, org, project), and migrates it in one step — auth token into the DB, org/project into defaults. Opt-in, transparent, auditable.2. Automatic / zero-friction
Detect an unauthenticated session where
.sentryclirchas a valid-looking token and prompt inline — "Found a token in .sentryclirc at ~/.sentryclirc — use it? [Y/n]" — on first use of any command that needs auth. No separate command needed; the migration happens at the moment the user would have hit an auth error anyway. This is the god-tier version: users who didn't even know there was a migration to do get silently shepherded across.These aren't mutually exclusive — explicit migrate for power users who want control, auto-detect as the default for everyone else.