claude login: read the shared Keychain credential when the CLI doesn't namespace by config dir - #20
Open
rbutera wants to merge 1 commit into
Open
Conversation
…espace the config dir
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
tokenmaxx login claudereports success but never stores an account, so the proxy later answers every request with503 no active anthropic account.registerClaudeAccountruns an isolatedclaude auth login --claudeaiunder a temporaryCLAUDE_CONFIG_DIR, thenimportCliCredentialreads the credential back from the macOS Keychain under a service name namespaced by a hash of that config dir (Claude Code-credentials-<hash8>). Current Claude Code (checked on v2.1.220 and v2.1.223) stores its OAuth credential under the plain serviceClaude Code-credentialsregardless ofCLAUDE_CONFIG_DIR, and writes no.credentials.jsonon macOS. Both read branches miss,importCliCredentialthrowsCREDENTIAL_MISSING, and no account row is written. The inner login has already printed "Login successful", so from the outside it looks like it worked and the account simply never appears in the list.Fix
Read whichever store the CLI actually wrote. Try the namespaced service first, so any build that does namespace keeps working, then fall back to the shared
Claude Code-credentialsservice (keeping the same-a <user>filter), then the on-disk file.removeClaudeProfilestill deletes only the namespaced service, so cleanup never touches the user's own shared Claude Code login.Evidence
On v2.1.223,
security dump-keychainshows only the plainClaude Code-credentialsservice with no namespaced variant, and that entry carries theclaudeAiOauthobject the schema expects. The-a <user>filter matters: without it the same service name resolves to a differentmcpOAuth-only entry, so the read keeps the user filter.Tests
Added a regression test: the namespaced lookup misses, the shared service returns the credential, and
registerClaudeAccountpersists it. The existing namespaced-path test still passes.bun test, typecheck, and biome are all clean.The version bump and changelog line came from the repo's own
preparecommit hook; drop or reformat them if you'd rather handle that at release.