What
Users can now authenticate with an enterprise cloud gateway directly from Claude Code using a browser-based device code OAuth flow, complete with TLS certificate pinning.
Usage
claude login # opens the /login flow; gateway URL is provisioned via managed settings (forceLoginGatewayUrl)
/login # same, from inside a sessionDetails
- The gateway URL must use
https://(plainhttp://is only allowed for localhost in development). - On first connection, Claude Code shows the gateway's SHA-256 certificate fingerprint and prompts "You haven't connected to this gateway before. Once trusted, it can push settings to this machine that execute commands and change your environment. Only continue if this is your organization's gateway."
- If the certificate changes after a previous trust, a warning is shown: "The TLS certificate for this gateway has changed since you last connected. Only continue if your administrator has confirmed a certificate rotation."
- DNS resolution is validated to confirm the gateway host resolves to private-network addresses only. Direct IPs, dual-stack hostnames with a public AAAA record, and HTTP proxy hosts on public networks are all flagged with specific error messages.
- The token is persisted via secure storage after the browser flow completes.
- If
NODE_EXTRA_CA_CERTSis needed for a private CA or self-signed certificate, a help message now explains exactly how to set it (both as an environment variable and viaenv.NODE_EXTRA_CA_CERTSin~/.claude/settings.json).
Evidence
Full browser-based OAuth flow (search for "Connecting to gateway…", "Certificate fingerprint (SHA-256):", "Gateway URL must use https://")
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
One source agreesOne thing we can check says the same as this entry.
Anthropic's release notes agree
Fixed external plugins enabled only by project .claude/settings.json not requiring explicit install consent on every loader path