[FEATURE] Make auth source/profile resolution explicit and warn on env overrides

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code can currently pick up authentication and provider state from several places: environment variables, local credentials, profile/config settings, and provider-specific configuration (for example Anthropic API vs Vertex vs Bedrock).

That flexibility is useful, but when more than one source is present the active auth path can become too implicit. In practice this makes it easy to debug the wrong problem: a shell/session may be picking up stale or unintended auth/provider settings even though the user believes they are using a different profile or credential source.

This is especially easy to run into when switching contexts frequently, using multiple shells, or working in environments where shell startup files, direnv, or other tooling inject credentials automatically. Even when the final requests are technically valid, the lack of visibility into which auth source and which provider selection actually won can make the behavior hard to reason about.

Related prior issues suggest parts of this problem already exist in narrower forms:

• #16238 (CLAUDE_CODE_OAUTH_TOKEN overriding credentials file without enough visibility)
• #27130 (custom API key setting appearing to lose to provider env state)

What seems missing is a more general, first-class way to make auth/profile resolution explicit and safer.

Proposed Solution

Please make the active auth source and provider resolution explicit, and warn when environment state is overriding a more obvious or user-selected path.

Concretely, something like this would help a lot:

1. Show the active credential source and provider source clearly in /status and/or startup diagnostics.

Example:

• Provider: Anthropic API (from explicit profile)
• Credential source: ANTHROPIC_API_KEY (environment variable)
• Credential source: OAuth token (~/.claude/.credentials.json)
• Provider: Google Vertex AI (from environment)

1. Warn when environment variables are overriding local credentials, selected profiles, or config in a way that is likely to surprise the user.

Example:

• Warning: CLAUDE_CODE_OAUTH_TOKEN is overriding credentials from ~/.claude/.credentials.json
• Warning: Vertex-related environment variables are forcing provider selection despite local config

1. Prefer explicit user/profile selection over ambient shell state when possible, or at minimum surface the precedence order clearly.

1. Add a lightweight diagnostic command or mode (even if folded into /status) that answers: “which provider/auth inputs were considered, and which one won?”

The main request is not a brand-new auth system; it is better visibility and safer conflict handling around the one that already exists.

Alternative Solutions

Current workarounds are all manual and error-prone:

• unsetting environment variables by hand before every session
• using separate shells for different auth contexts
• deleting cached config/state when behavior looks wrong
• trial-and-error with /status and repeated login attempts

These workarounds only help after the user already suspects auth resolution is the issue.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

1. A user has logged into Claude Code before and also has environment-based auth configured for another workflow.
2. Later they switch context and expect Claude Code to use a different profile or credential source.
3. Ambient shell state still injects a provider or token they forgot about.
4. Claude Code authenticates successfully, but not through the path the user thinks it is using.
5. The user sees confusing behavior and has no quick way to tell which auth source/provider actually won.

If /status and startup diagnostics made this explicit, the problem would be much faster to detect and much less likely to turn into hours of debugging.

Additional Context

I am filing this as a general DX/safety improvement request, not as a claim about one specific backend or one specific bug. The broader pattern is that auth ambiguity is expensive: it can lead to confusing behavior, wasted debugging time, and accidental use of an unintended account/provider.

A stronger version of /status plus explicit override warnings would likely solve a meaningful class of issues without requiring users to reverse-engineer precedence rules from trial and error.