[saphid]

Problem

A Claude instance that signs in with an API key (ANTHROPIC_API_KEY, an apiKeyHelper, or a Console /login managed key) shows a bare "Authenticated" in Settings → Providers, with no auth method. Codex shows "Authenticated · OpenAI API Key" in the same situation, and Claude shows "Claude API Key" when the key comes through ANTHROPIC_AUTH_TOKEN.

The Claude SDK reports these logins as tokenSource: "none" and apiKeySource: "ANTHROPIC_API_KEY" (or apiKeyHelper, /login managed key). The status probe already counts a non-none apiKeySource as signed in (claudeAuthStatus), but claudeAuthMetadata only reads tokenSource, so the snapshot gets no auth type or label.

Change

claudeAuthMetadata now also returns the Claude API Key label when apiKeySource is set and not none. It uses the same check claudeAuthStatus uses for hasApiKey. The Bedrock and custom-endpoint labels are checked first, as before, so they still win.

Scope and approval

Very small, focused fix for an obvious bug, so no prior issue: the probe already decides these installs are signed in with an API key, but drops the label. The SDK typings describe apiKeySource as "where the credential used for API requests came from". The fix touches one server function and adds one assertion to an existing test.

Overlap search: the closest open PRs are #25580 (usage limits behind a custom endpoint) and #29408 / #29713 (Claude home and keychain selection). None of them changes how the auth label is chosen.

Verification

• Red on main: the extended case keeps an API key install authenticated when it reports no token source in apps/server/src/provider/ProviderRegistry.test.ts failed with AssertionError: expected undefined to equal 'Claude API Key'.
• Green: vp test run src/provider/ProviderRegistry.test.ts passes 52/52 (also after rebasing on current main).
• vp run check:changed passes: format, lint, knip, typecheck (3 packages), tests 53/53.
• Not checked: a live Claude CLI signed in with a real API key. The fix relies on the SDK's documented apiKeySource values.

Reviewed with sol-loop: 1 round with GPT-6.1 Sol on high. Sol verdict: approved.

Created with Claude Opus 5.5 in Claude Code (T3 Code).

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at a160dab

Macroscope's review found this PR approvable — Claude API-key logins now display “Claude API Key” in provider status. The change preserves authentication decisions and endpoint-specific labels, with no material operational or access impact.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

Claude provider status now reports API-key authentication when the normalized auth method is apiKey or apiKeySource is present and is not none. The test checks the resulting status label.

Changes: Claude authentication label

Layer / File(s)	Summary
Determine and verify API-key label apps/server/src/provider/ClaudeProvider.ts, apps/server/src/provider/ProviderRegistry.test.ts	claudeAuthMetadata now considers apiKeySource alongside the normalized auth method. checkClaudeProviderStatus passes the probed source. The test asserts the Claude API Key label.

Estimated code review effort: 2 (Simple) | ~5 minutes

Change: Bug fix

Suggested reviewers: juliusmarminge, t3dotgg

Merge Risk: Minimal · up to a160d

Claude API-key logins will now show as "Claude API Key" in provider status, matching how authentication is already detected. The change is small and tested, and no concrete merge risk was found.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title names the main change: Claude API-key logins should show the 'Claude API Key' label in provider status. It matches the raw summary, which says claudeAuthMetadata now returns that label when …
Description check		The description follows the template well. It has Problem, Change, Scope, and Verification sections. The Problem section states expected behavior and environments. The Change section explains the fix …
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Title check

Explanation

The title names the main change: Claude API-key logins should show the 'Claude API Key' label in provider status. It matches the raw summary, which says claudeAuthMetadata now returns that label when apiKeySource is set and not none. The title uses the conventional commit form, and the 'fix(server)' scope matches the touched server file.

Full details: Description check

Explanation

The description follows the template well. It has Problem, Change, Scope, and Verification sections. The Problem section states expected behavior and environments. The Change section explains the fix and its reuse of the hasApiKey check. The Scope section explains why no issue is linked and names the overlapping open PRs. The Verification section gives a red-then-green test result, the check:changed outcome, and a stated gap (no live Claude CLI check). The template's guidance on conventional titles and the agent model line is also met. The description does not link a tracked issue, but it gives a reason for that.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: f52e5c1
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 1d4634bc-4555-4acd-b2f2-1f64380a9de4

Commits

Reviewing files that changed from the base of the PR and between dcb1830 and a160dab.

Files selected for processing: 2

• apps/server/src/provider/ClaudeProvider.ts
• apps/server/src/provider/ProviderRegistry.test.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 3 remain after this review.

[saphid]

Review requested

Date (UTC)	Reviewer	Where
2026-11-13	Julius	Discord DM

_{Logged so this PR shows when a maintainer was asked to review it.}

Dismissing prior approval to re-evaluate a160dab

[juliusmarminge]

Evidence

Ran the same scenario on fresh databases with a dummy ANTHROPIC_API_KEY, an empty Claude config directory, and no inherited proxy credentials. Paired the web client, opened Settings → Providers, enabled and selected Claude, then captured its authentication status. Chromium, 1280×800, light theme on both sides.

Before	After
f52e5c1919	a160dab2a6

Scenario source

scenarios:prove exited 0: failsOnBase=true, passesOnHead=true. Both the provider list entry and Status row show the difference.

Not shown:

• apiKeyHelper and Console-managed key variants were not exercised; this proof covers ANTHROPIC_API_KEY.
• The dummy API key was not validated against Anthropic; the proof verifies environment-derived authentication labeling, matching the triage reproduction.