Skip to content

fix(server): Claude API-key logins show as Claude API Key in provider status - #29855

Open
saphid wants to merge 1 commit into
pingdotgg:mainfrom
saphid:fix/claude-api-key-auth-label
Open

saphid wants to merge 1 commit into
pingdotgg:mainfrom
saphid:fix/claude-api-key-auth-label

Conversation

@saphid

@saphid saphid commented Nov 3, 2026

Copy link
Copy Markdown
Contributor

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

… status

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions github-actions Bot added vouch:trusted PR author is trusted by repo permissions or the VOUCHED list. size:XS 0-9 changed lines (additions + deletions). labels Nov 3, 2026
@macroscopeapp

macroscopeapp Bot commented Nov 3, 2026

Copy link
Copy Markdown
Contributor

Approvability

Verdict: Approved at dcb1830

Macroscope's review found this PR approvable — Claude API-key logins now display “Claude API Key” in provider status. This is a metadata-only change that preserves existing authentication behavior and Bedrock/custom-endpoint label precedence.

You can add or adjust custom eligibility rules. Learn more.

@coderabbitai

coderabbitai Bot commented Nov 3, 2026

Copy link
Copy Markdown
Contributor

Review in Change Stack →

No actionable comments were generated in the recent review.

Walkthrough

Claude provider status now reports the API-key authentication label when the normalized auth method is apiKey or the probed apiKeySource is present and is not none. The test checks the resulting 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, and the test asserts the Claude API Key label.

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

Change: Bug fix

Possibly related issues

  • pingdotgg/t3code#29674 — The change labels a login as Claude API Key when apiKeySource is set, but it does not address the issue’s home-path credential selection.
  • pingdotgg/t3code#26909 — The change modifies Claude authentication-label selection, but it does not add proxy detection for custom endpoints.

Possibly related PRs

  • pingdotgg/t3code#27356 — This PR changes proxy authentication metadata in the same Claude provider status path.
  • pingdotgg/t3code#28325 — This PR changes authentication-label selection for configured Claude gateways.
  • pingdotgg/t3code#26937 — This PR changes Claude authentication metadata for configured endpoints and API keys.

Suggested labels: bugfix, size:S

Suggested reviewers: juliusmarminge, t3dotgg

Merge Risk: Minimal · up to dcb18

The change correctly labels supported Claude API-key logins without introducing an actionable merge risk.

Pre-merge checks: Passed 4
Check name Status Explanation
Title check Passed The title names the main change: Claude API-key logins should be labeled "Claude API Key" in provider status. The changeset adds that label in claudeAuthMetadata when apiKeySource is set and not "none…
Description check Passed The description follows the repository template. It has Problem, Change, Scope and approval, and Verification sections. The Problem section gives the expected and actual behavior with the environment …
Linked Issues check Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check Passed 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 be labeled "Claude API Key" in provider status. The changeset adds that label in claudeAuthMetadata when apiKeySource is set and not "none", and adds a test assertion for it. The title uses the conventional commit form and is specific.

Full details: Description check

Explanation

The description follows the repository template. It has Problem, Change, Scope and approval, and Verification sections. The Problem section gives the expected and actual behavior with the environment variables involved. The Change section explains the claudeAuthMetadata update and the check order for Bedrock and custom-endpoint labels. The Scope section explains why no prior issue exists and reports an overlap search. The Verification section gives a failing test before the fix, passing test results, and an unchecked item (a live Claude CLI login with a real API key). The description does not include a screenshot, but the change is not a UI change, so none is needed. It also does not link a triaged issue, but it gives a reason for the small-fix exemption as the template allows.

Finishing Touches
Generate unit tests (beta)
  • Create a new PR
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Warning

Some tools did not complete. Review the errors below.

ast-grep (0.51.1)

ast-grep could not parse rule config: /ast-grep-rules/ast-grep-essentials/rules/c/security/fprintf-non-literal-format-string-c.yml

Usage-based review receipt

Note

This review was completed with usage-based billing: files reviewed beyond your plan's included limits are billed at $0.25/file. View usage-based billing.

CodeRabbit Verify

  • Run CodeRabbit Verify to test the changes in this pull request.
Recent review info
Run configuration
Commits

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

Files selected for processing: 2
  • apps/server/src/provider/ClaudeProvider.ts
  • apps/server/src/provider/ProviderRegistry.test.ts

Limit details: You’ve used all 10 included reviews currently available.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size:XS 0-9 changed lines (additions + deletions). vouch:trusted PR author is trusted by repo permissions or the VOUCHED list.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant