claude_authenticate joins a login already in progress and respects allowedProviders; --desktop refuses subcommands
SDK login requests now reuse a sign-in already under way and are blocked by the allowedProviders managed setting; --desktop can't be combined with subcommands
Group of 2You'll noticeNo documentation foundImprovements
You'll noticeTier: how much it should matter to you
2Useful: my rating, 1 to 5
2Signal: worth watching, 1 to 5
SDKArea: what it touches
ImprovementsKind: in v2.1.285,
ImprovementsSection of the release
What
claude_authenticate is the request that programs driving Claude Code through the SDK (the toolkit for controlling Claude Code from other software) use to sign a user in. It changes in two ways, and a new command-line option appears:
A repeat claude_authenticate request now joins the OAuth sign-in (the browser-based login) that is already in progress and reuses its URLs. Before, each request cleaned up the old sign-in and started a new one.
If the allowedProviders managed setting (a setting controlled by your organization's administrator) does not permit the Anthropic API, login is refused with "Login blocked: this machine's managed settings do not permit signing in to the Anthropic API here (allowedProviders)". Before, there was no provider check.
A new --desktop option appears. It is refused when combined with a subcommand, with the message "--desktop can't be combined with".
Why
Tools that send a second login request while one is pending no longer restart the sign-in and invalidate the first link. Administrators who limit which API providers a machine may use now have that limit applied to SDK logins too.
Read from
Names in the bundleclaude_authenticate
How sure we are
One source agreesOne thing we can check says the same as this entry.
Anthropic's release notes agreeAdded allowedProviders managed setting to limit which API providers a machine may use (Anthropic API, a custom endpoint, Bedrock, Mantle…
