/login device auth fails with HTTP 500 after successful browser approval (CLI v0.42.0, macOS)

[milesbuckton]

Environment

• CLI version: 0.42.0
• OS: macOS
• Account: free plan (Adagio tier)
• Also reproduced via the VS Code extension

Steps to reproduce

1. Run /login in the CLI
2. Browser opens with a device code (e.g. WGBT-C3BW, QLE2-MYVL)
3. Approve the login in the browser with the correct account — approval succeeds in the browser
4. CLI then reports:

   Login failed: The server had an error while processing your request
   

Expected

Login completes and credentials are stored.

Actual

The token exchange after browser approval appears to return HTTP 500. Reproduced 3+ times with fresh device codes.

What I've ruled out

• Stale local credentials: none exist — /logout returns "Nothing to logout"; no ~/.kimi or ~/.config/kimi directories
• Network: no proxy/VPN; stable connection
• Wrong account / expired codes: approved promptly with the correct account, multiple fresh codes
• Account/quota health: the Kimi Work agent (desktop app) works perfectly on the same account at the same time, and My Quota shows ~50% remaining — so the model backend is fine; only the CLI device-auth token exchange fails

Because the failure happens after successful browser approval, and no CLI commands work without login, this looks like a server-side issue in the token-exchange step, possibly specific to my account.

Possibly related

The API-key path also fails for this account: requests return
429 ... account suspended due to insufficient balance
even though Billing & Invoices is empty (expected on a free plan). This hints the account's billing state may be mis-flagged server-side, which could be the root cause of both errors.

Request

Could you check server-side logs for failed token exchanges on my account? Happy to share my account email / org ID privately.

[milesbuckton]

Update: the login is working now. ✅

Running /login again (same CLI v0.42.0, macOS, same account), the device-auth flow completed successfully — browser approval with a fresh code (FDTZ-NIKJ) was followed by Logged in. in the CLI, and the model selector now shows the available models (K2.7 Coding, K3, K3-256k).

So the HTTP 500 during the token exchange appears to have been a transient server-side issue that has since been fixed. Nothing changed on my side. From my perspective this issue can be closed — thanks!