claude login: read the shared Keychain credential when the CLI doesn't namespace by config dir

[rbutera]

Problem

tokenmaxx login claude reports success but never stores an account, so the proxy later answers every request with 503 no active anthropic account.

registerClaudeAccount runs an isolated claude auth login --claudeai under a temporary CLAUDE_CONFIG_DIR, then importCliCredential reads 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 service Claude Code-credentials regardless of CLAUDE_CONFIG_DIR, and writes no .credentials.json on macOS. Both read branches miss, importCliCredential throws CREDENTIAL_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-credentials service (keeping the same -a <user> filter), then the on-disk file.

removeClaudeProfile still deletes only the namespaced service, so cleanup never touches the user's own shared Claude Code login.

Evidence

On v2.1.223, security dump-keychain shows only the plain Claude Code-credentials service with no namespaced variant, and that entry carries the claudeAiOauth object the schema expects. The -a <user> filter matters: without it the same service name resolves to a different mcpOAuth-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 registerClaudeAccount persists 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 prepare commit hook; drop or reformat them if you'd rather handle that at release.

[DexterStorey]

Hey @rbutera, thanks for the PR! I tried to confirm the premise and got the opposite result, so let me share the test.

The PR's claim is that the CLI ignores CLAUDE_CONFIG_DIR and always uses the shared Claude Code-credentials keychain entry -- which would mean tokenmaxx's namespaced lookup can never find anything. To check that, I wrote a fake credential into the namespaced entry for a temp config dir (the exact entry tokenmaxx expects), then ran claude auth status with CLAUDE_CONFIG_DIR pointed at that dir:

• With the fake credential planted: auth status reported logged in, with my fake data. So the CLI does read the namespaced entry.
• With nothing planted: it reported logged out — even though my real login sat in the shared entry the whole time. So it doesn't fall back to shared either.

Same result on 2.1.235 and 2.1.221 (inside the version range you tested). That's the opposite of what the PR assumes, so something else must be going on in your setup, or I messed up, or misunderstood something!

Separate from the repro: reading the shared entry as a fallback is risky even when it works -- that entry is your main Claude Code login, so a miss on the namespaced read would make tokenmaxx silently import the wrong account and then compete with Claude Code over the same OAuth session.

Can you share claude --version, how it's installed (npm vs native), and whether your shell sets CLAUDE_CONFIG_DIR anywhere? Happy to help fix, or update my understanding!

[rbutera]

Hey @DexterStorey, thanks for digging in and sharing the exact repro, that's genuinely helpful. I think we're both right and looking at two different halves of the flow.

Your test plants a credential in the namespaced entry and checks claude auth status, which proves the CLI READS namespaced first (and won't fall back to shared on read). I see the same. But my PR's evidence is about the WRITE side: where a fresh claude auth login --claudeai actually stores the credential when it runs under a temp CLAUDE_CONFIG_DIR. On my setup, after the isolated login, security dump-keychain showed the credential in the plain Claude Code-credentials service, with no namespaced entry ever created. So login wrote to shared while the read looks namespaced-first, and tokenmaxx's namespaced-only read misses what login actually wrote. That also explains the disagreement: you planted the entry the code expects, so the write path never came into your repro.

The variable I'd bet on is install method. My setup:

• claude 2.1.235
• native install (not npm): ~/.local/bin/claude resolves to ~/.local/share/claude/versions/2.1.235, a Mach-O arm64 binary
• CLAUDE_CONFIG_DIR is not set anywhere (shell or env)

Decisive test if you can: on a NATIVE install, run an actual claude auth login --claudeai with CLAUDE_CONFIG_DIR pointed at a fresh temp dir, then security dump-keychain | grep "Claude Code". My bet is it lands in the shared service, not the namespaced one. If native and npm builds differ on where login writes, that's the whole discrepancy.

On the safety point, you're right and I don't want to import the wrong account or fight Claude Code over the OAuth session. Two mitigations already in the PR: the fallback read keeps the same -a <user> filter, so it only imports the account matching the user who just logged in, and removeClaudeProfile still deletes only the namespaced service, so cleanup never touches your real shared login. Happy to gate the shared fallback more tightly (only when the namespaced read misses AND the shared entry's account matches the expected user), or to reframe this as a native-build write-location bug to raise upstream and keep the fallback as the pragmatic bridge until then. Whatever you prefer.