Setup tokens can now carry any lifetime, but everything still hands over the 365-day maximum.
Token duration is plumbed as data and reported on the login screen, but only the one-year value is ever supplied.
What's wrong with this entry?
The setup-token flow now carries a token duration as data instead of a fixed sentence, so the login screen reports whatever lifetime it was handed: "1-year" when the value matches the one-year constant, and an explicit day count otherwise. Everything needed to issue a shorter token is present, but nothing in this build supplies a different value, so every token created is still the 365-day maximum.
- The configured duration reaches the login component as an
expiresInvalue rather than as prebaked wording, which is what lets the screen state the real lifetime. - A ceiling constant caps the lifetime at 365 days, and a parser exists to turn a requested number of days into a duration.
- That parser discards its input and always returns the maximum, 365 days or 31536000 seconds, so the derived wording always resolves to "1-year".
- The rejection path is written but unreachable: an out-of-range value would print a message and exit with status 1.
- No command-line option feeds a requested day count into the parser, so no user action changes a token lifetime in this build.
mode: "setup-token", SETUP_TOKEN_MAX_EXPIRY_DAYS
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.242
GitHub CLI login is detected with
gh auth tokenBoth mention token auth
-
v2.1.242
/web-setuptip and status row for Claude Code on the webBoth mention setup
-
v2.1.242
Quick web setup still off
Both mention setup