Changes to which environment credentials sessions pick up

What

Claude Code can read credentials from environment variables, named values given to a program when it starts, such as ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN and CLAUDE_CODE_OAUTH_TOKEN. Several places now control more tightly when those are used.

• Background sessions: starting a background session, one that keeps running without a terminal attached, now carries a binding to an auth profile (a named sign-in, see ANTHROPIC_PROFILE). Listed credential variables are removed from the new session's environment. With a profile: binding, ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN and CLAUDE_CODE_OAUTH_TOKEN are deleted, and ANTHROPIC_CONFIG_DIR and ANTHROPIC_PROFILE are kept only when they match the binding. This sits behind a remote switch, tengu_steady_anchor, which counts as on when it has no value; nothing has been read about that switch. References to ANTHROPIC_PROFILE and ANTHROPIC_CONFIG_DIR grew sharply in this build.
• Host credential push: a program that embeds Claude Code can now hand a running session a sign-in credential through update_environment_variables. A blank value or one that is not allowed is rejected, and the session refreshes before applying it. Before, only an allowed list of variables and the host's choice were accepted. When a credential is supplied, the path that claims a spare session also clears a set of environment variables.
• Ignored env credentials: the code that finds the API key, the auth token and the credential source now returns nothing, or "none", when a new check is true. What that check looks at was not traced.

Why

If you use named profiles, background sessions should sign in with the profile they were bound to rather than a key or token left in your environment. In practice, a credential set in your environment may no longer be the one a session uses in these cases.