Distillation

🔴 (16:06) User showed packages/cli/src/lib/db/schema.ts migration code: for currentVersion < 14, it creates EXPECTED_TABLES.repo_cache; for < 15, it creates EXPECTED_TABLES.issue_org_cache; for < 16, it runs addColumnIfMissing(db, "auth", "host", "TEXT"); for < 17, it runs addColumnIfMissing(db, "org_regions", "source_origin", "TEXT"); afterward, versions below CURRENT_SCHEMA_VERSION are updated via UPDATE schema_version SET version = ?.

🔴 (16:06) User showed a search with exactly 16 matches concerning stored OAuth and environment-token precedence. Relevant tests include packages/cli/test/commands/auth/logout.test.ts line 149 ("OAuth source with env var set: clears stored OAuth (env var still present)"); packages/cli/test/lib/security/sntrys-claim-mismatch.test.ts lines 179, 207, and 240; packages/cli/test/lib/auth-hint.test.ts line 118; packages/cli/test/lib/db/auth.test.ts lines 130, 137, 178, and 186; packages/cli/test/lib/db/auth.property.test.ts lines 88 and 196; and packages/cli/test/lib/db/auth.host.test.ts lines 77 and 114.

🔴 (16:06) User stated the forced env token never uses a region cached for stored OAuth; this security behavior is covered by packages/cli/test/lib/security/sntrys-claim-mismatch.test.ts line 240.

🔴 (16:06) User showed credential-precedence security tests in packages/cli/test/lib/security/sntrys-claim-mismatch.test.ts: stored OAuth host takes precedence over an inactive env-token claim, while a forced env-token claim takes precedence over stored OAuth.

🔴 (16:06) User showed packages/cli/test/lib/db/auth.host.test.ts host-scoping tests: setAuthToken("tok-1", ..., { host: "https://sentry.acme.com" }) persists that explicit host; "https://SENTRY.Acme.com/" normalizes to "https://sentry.acme.com"; without an explicit host, setAuthToken("tok-2") uses configured SENTRY_HOST="https://env-host.example.com"; and without SENTRY_HOST or SENTRY_URL, setAuthToken("tok-3") falls back to "https://sentry.io".

🔴 (16:06) User showed packages/cli/test/lib/db/auth.host.test.ts verifies refresh-style updates preserve the existing credential host: an initial setAuthToken("tok-initial", 3600, "refresh-tok", { host: "https://sentry.acme.com" }) followed by setAuthToken("tok-refreshed", 3600, "refresh-tok") leaves getStoredAuthHost() equal to "https://sentry.acme.com".

🔴 (16:06) User showed packages/cli/test/lib/db/auth.host.test.ts simulates a pre-v16 row with INSERT OR REPLACE INTO auth (id, token, host, updated_at) VALUES (1, 'legacy-token', NULL, ?). After captureEnvTokenHost() snapshots boot-time SENTRY_HOST="https://legacy-configured.example.com", the first and second calls to getStoredAuthHost() return that origin, and SELECT host FROM auth WHERE id = 1 confirms it was persisted.

🔴 (16:06) User showed packages/cli/test/lib/db/auth.host.test.ts verifies that a legacy auth.host=NULL row with no boot-time SENTRY_HOST or SENTRY_URL is lazily migrated to the SaaS default "https://sentry.io".

🔴 (16:07) User showed the regression test packages/cli/test/lib/db/auth.host.test.ts::"lazy migration: ignores rc-poisoned current env (uses boot snapshot instead)": the old behavior read current environment through getConfiguredSentryUrl(), allowing a .sentryclirc shim to influence migration after boot. The test snapshots the SaaS default with captureEnvTokenHost(), then sets process.env.SENTRY_URL = "https://rc-sourced.example.com"; getStoredAuthHost() must still return "https://sentry.io".

🔴 (16:07) User showed packages/cli/test/lib/db/auth.host.test.ts verifies getStoredAuthHost() returns undefined when no token is stored, and hasUsableStoredToken() changes from false to true after setAuthToken("tok-usable", 3600, "refresh", { host: "https://sentry.io" }).

🔴 (16:07) User showed packages/cli/test/lib/db/auth.host.test.ts::"clearAuth evicts region-URL allow-list but PRESERVES login trust anchor": applyLoginUrl registers a process-local login trust anchor before handleExistingAuth may call clearAuth() during auth login --url <new-host>. Clearing that anchor would break IAP custom headers in the subsequent device flow, so logout preserves it; the next applyLoginUrl overwrites it.

🔴 (16:07) User showed the exact clearAuth() trust test setup and outcome: after storing a token for "https://sentry.host-a.com", calling registerLoginTrustAnchor("https://sentry.host-a.com"), and registering "https://us.host-a.com" through registerTrustedRegionUrls("https://sentry.host-a.com", [...]), both trust checks initially return true. After await clearAuth(), isTrustedRegionOrigin("https://us.host-a.com", "https://sentry.host-a.com") returns false, while isLoginTrustAnchorFor("https://sentry.host-a.com") remains true.