Login token expiration too short for slow email delivery

100%

I suspect they're using this crippled login process to manage user concurrency in a rather opaque fashion.

Yes, this is happening to me as well. The email doesnt' arrive for 10+ mins which is one issue, but the next logout for re-auth will come again very soon. the Desktop app is effectively un-usable. Claude for Windows Version 1.32885.1 (a757f5)

Header analysis of one delayed sign-in email (2026-08-24): Anthropic's send
hop took ~1 second -- the entire ~10-minute delay was recipient-side, and it's
worth stressing this came from an ordinary layered setup, not an exotic one:
the message crossed two independent scanning layers (a third-party gateway
plus a major vendor's built-in email security), whose latency compounded past
the whole token lifetime before the email reached the inbox. "Send faster"
wouldn't fix this; the token needs to survive multi-minute recipient-side
delays.

The current resend button doesn't solve it either. My colleagues and I already
work around it by requesting a link, watching it expire before the email
arrives, resending, and refreshing webmail repeatedly -- hoping one attempt
lands inside the ~10-min window. Often several attempts in a row all lose the
race, because the delay routinely exceeds the token lifetime. Resending can't
rescue an email already in flight.

Realistically this turns every sign-in into a multi-minute fight -- several
failed link requests, constant inbox-refreshing, and often 10-15 minutes lost
just to log in. Multiply that across a team that has to re-auth regularly and
it's a serious, recurring time sink, not a one-off annoyance.

What would actually fix it: the token needs to stay valid long enough (measured
from send) that ordinary multi-minute delays don't kill it -- observed delays
cluster at 10-11 min, so 30-60 min, not ~10. Even better, a code-based flow
(email a short code typed into the still-open login page) removes the
"navigated away, token expired" failure mode entirely.