Signing in to Cursor with a free (Hobby) account completes in the browser, and the client then reports it is not authenticated. Retry sign-in runs the whole browser flow again and lands in the same place. Swap to a paid account and the identical flow works first go. This is pingdotgg/t3code#19766.
Why it happens
Cursor's local SDK requires a paid plan - confirmed on Cursor's own forum. A free-plan key is answered with 403 plan_required, but the client's catalog check only treats 401 as an authentication failure. The plan rejection surfaces as a generic catalog error, the verification step discards the credential that was just created, and the account view shows a fixed "sign-in failed or expired" message that never mentions the plan. The user retries a flow that cannot succeed.
What to do
Sign in with a paid account, or set CURSOR_API_KEY from one:
export CURSOR_API_KEY=<key-from-a-paid-account>
The wider lesson is worth keeping. When a sign-in reports failure immediately after a successful browser round trip, look at the status code before blaming the token. A 403 that is not 401 is usually the product saying no - a plan, a licence, an enterprise policy - and any client that folds every rejection into "your session expired" will send you chasing credentials that were never the problem. An enterprise account whose identity lookup returns 403 fails through the same path, so the same check applies there. The fix upstream is to surface the plan rejection instead of the generic message (pingdotgg/t3code#15075).