SDK hosts can hand Claude Code a separate cloud-sessions token

What

An SDK host is an app that runs Claude Code inside itself through the Agent SDK. Such a host could already refresh Claude Code's sign-in token. It can now also supply a second token that authorizes the cloud-sessions API. That token must belong to the same account and organization as the sign-in token.

• CLAUDE_CODE_SESSIONS_OAUTH_TOKEN is a new environment variable holding that token. It is added to three credential lists, and one of them strips secrets from the environment.
• When a host sends this variable through update_environment_variables, the value is held back and applied only if a validity check passes. Otherwise it goes on the list of refused keys. The handling of CLAUDE_CODE_OAUTH_TOKEN in the same place was reworked to refresh credentials after the update.
• The oauth_token_refresh request gains an optional kind: "sessions" that asks the host for the cloud-sessions token. Without kind, the request still means the sign-in token, which is all that older hosts know.
• CLAUDE_CODE_SDK_HAS_SESSIONS_OAUTH_REFRESH is a new variable a host sets to say it can answer that request. It also turns on the same behaviour as CLAUDE_CODE_SDK_HAS_OAUTH_REFRESH.
• Claude Code can now ask when it first needs the token. Before, the request was sent only after a 401 (a rejected request) when there was no local refresh token.
• If the host answers with the sign-in token instead, the answer is ignored with a warning, and cloud-sessions calls keep using the sign-in token.

This path runs only when the host sets the new variable, Claude Code was started in a way that allows host refresh, and one further check passes.

Why

Apps that embed Claude Code can give it a separate token just for cloud sessions, and that token is treated as a secret. Without a host that sets the new variable, nothing changes.