Follow Discord
Sweep 22 Oct 2026 · 04:32Z Build v2.1.308 527 read Stable v2.1.308 Latest v2.1.308 Next v2.1.308 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.234 ·

Setup-token lifetime is plumbed through but always 365 days

Setup tokens can now carry any lifetime, but everything still hands over the 365-day maximum.

Under the hood Nothing to try yet In Development
JSON All of v2.1.234
Under the hoodTier: how much it should matter to you
2Useful: my rating, 1 to 5
3Signal: worth watching, 1 to 5
AuthArea: what it touches
In DevelopmentKind: in v2.1.234,
In DevelopmentSection of the release

Token duration is plumbed as data and reported on the login screen, but only the one-year value is ever supplied.

What

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.

Details
  • The configured duration reaches the login component as an expiresIn value 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.
Evidence

mode: "setup-token", SETUP_TOKEN_MAX_EXPIRY_DAYS

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

Read from
Names in the bundlesetup-token
Since it was published

The entry above is what we published on the day. These lines were added later, as Anthropic's own pages caught up, and they sit beside the original rather than replacing it.

Added since A small documentation edit on Test self-hosted environments end to end touched a line naming setup-token after this was published. There is no long-lived CI token for this today. The scope that grants cloud-session control, `user:sessions:claude_code`, is capped server-side at 30 days, so `claude setup-token`, which mints a one-year inference-only token, doesn't cover… self-hosted-environments-testing see the edit
Confirmed since Anthropic's documentation has since written up setup-token, on CLI reference. | `claude setup-token` | Generate a long-lived OAuth token for CI and scripts. Prints the token to the terminal without saving it. Requires a Claude subscription. See [Generate a long-lived token](/docs/en/authentication#generate-a-long-li… cli-reference see the edit
How sure we are
One source agreesOne thing we can check says the same as this entry.
Anthropic's documentation agreesAnthropic's documentation has since written up setup-token, on CLI reference.

See this entry in the whole of v2.1.234 →

Feedback