MOHAN
9df12ac8c5
api_key_hash is a one-way hash, so /api/login could never hand back a previously-issued key — the frontend's fallback of reusing whatever key happened to already be in localStorage meant login only worked on the exact browser that originally signed up, and was completely broken on any new device, incognito window, or after clearing storage, even with the correct password. /api/login now issues a fresh 'Dashboard Login' named key on every successful login, replacing only that one key each time (no duplicate accumulation) and never touching the user's other named keys (e.g. an already-connected Claude Desktop/Codex client) or the legacy key. Also fixes a bug this exposed: list_api_keys' legacy-key backfill only ran when a user had zero rows in api_keys at all, so if login created a 'Dashboard Login' row first, the original signup key would never get backfilled and would silently vanish from the Tokens page (while still remaining fully valid for authentication). Backfill now checks specifically whether the legacy key's hash is already represented, independent of what other named keys exist. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>