Handling of host-supplied and environment OAuth tokens tightened

What

Claude Code can be signed in by a token handed to it by the program that started it, or through the CLAUDE_CODE_OAUTH_TOKEN environment variable (a named value set outside Claude Code). Several places that handle these tokens changed:

• On a 401 (the server refusing the login), a session whose login came from a host-supplied token, including one passed through a file descriptor, no longer switches to the login saved on the machine, because it may be a different account. The new message reads: "OAuth 401: the login this session is using was refused. The login saved on this machine was not used because it may be a different account. Sign in again in the app that started this session, or run /login."
• The login source is now reported as "env" only when the stored access token matches CLAUDE_CODE_OAUTH_TOKEN or the other environment token source. Before, any set CLAUDE_CODE_OAUTH_TOKEN counted. When the variable is set, the file-descriptor token lookup is skipped.
• CLAUDE_CODE_OAUTH_TOKEN is removed from the environment given to shell commands when dropShellOAuthToken is set or when a new check passes. Before, dropShellOAuthToken was the only condition.
• When CLAUDE_CODE_OAUTH_TOKEN is set, loading policy limits now runs the same reset it ran only for credentials not held in the saved store.

Why

A session started by another app can no longer quietly change to a different account when its login is refused; you are asked to sign in again instead. If you sign in with CLAUDE_CODE_OAUTH_TOKEN, which credential Claude Code uses and whether the token reaches commands it runs may differ from before.