Support multiple Claude accounts OR support account swapping with claude-swap

[robd003]

For some reason CodexBar only appears to track a single Claude account.

It would be great if it could load Claude accounts using the default preferences file that the claude process reads from.

Being able to switch claude accounts with claude-swap would be great.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 25, 2026, 4:26 PM ET / 20:26 UTC.

Summary
Keep open: current main already supports stored Claude token accounts and org IDs, but I found no code/docs support for reading claude-swap or Claude CLI default account-switching state, so the remaining request needs maintainer product/auth review rather than cleanup closure.

Reproducibility: not applicable. this is a feature request, not a broken-behavior report. Source inspection shows built-in Claude token accounts exist, while claude-swap/default Claude profile integration is not present.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
Maintainers need to decide whether external Claude account-switcher/profile integration is supported, since current main already has built-in token accounts and this touches auth/secret boundaries.

Review details

Best possible solution:

Document the supported Claude token-account workflow if that answers the need; otherwise add only a narrow, opt-in claude-swap/default-profile integration after maintainers define the credential and privacy boundary.

Do we have a high-confidence way to reproduce the issue?

Not applicable; this is a feature request, not a broken-behavior report. Source inspection shows built-in Claude token accounts exist, while claude-swap/default Claude profile integration is not present.

Is this the best way to solve the issue?

Unclear; the current token-account workflow is the safest supported path, but the requested external account-switching integration needs maintainer sign-off before choosing an implementation.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The reporter may only need the already-supported stored Claude credential workflow, so this could become a docs/support answer after maintainer confirmation.
• Reading Claude CLI or claude-swap-managed account state could broaden filesystem, Keychain, and secret-handling behavior.
• Prior discussion said local Claude signed-in session rotation was not feasible at that time, so implementation should not assume a stable Claude preference-file contract.

Codex review notes: model internal, reasoning high; reviewed against ada3660e9d61.

Label changes

Label changes:

• add P3: This is a low-urgency feature/support request around account-switching ergonomics, not a broken existing workflow.
• add impact:auth-provider: The issue is about Claude account selection, credential routing, and provider auth state.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: This is a low-urgency feature/support request around account-switching ergonomics, not a broken existing workflow.
• impact:auth-provider: The issue is about Claude account selection, credential routing, and provider auth state.

Evidence reviewed

What I checked:

• AGENTS policy read: Read the full target AGENTS.md; the Claude provider guidance, provider-data siloing rule, and no-live-provider-probe rule shaped this source-only review. (AGENTS.md:1, ada3660e9d61)
• Vision scope: VISION.md frames provider limit/credit/status coverage as in scope, but says new features and behavior touching auth, storage, or privacy need sign-off. (VISION.md:1, ada3660e9d61)
• Claude stored credential support exists: Current main defines Claude token-account support for sessionKey cookies, OAuth tokens, or Anthropic Admin API keys. (Sources/CodexBarCore/TokenAccountSupportCatalog+Data.swift:13, ada3660e9d61)
• Claude organization ID UI exists: The provider settings descriptor shows an organization field for Claude, and the token-account add path passes organizationID through to persistence. (Sources/CodexBar/PreferencesProvidersPane.swift:466, ada3660e9d61)
• Claude add-account row captures org ID: The shared token-account row renders an optional Org ID field when the descriptor enables it and sends that value to addAccount. (Sources/CodexBar/PreferencesProviderSettingsRows.swift:359, ada3660e9d61)
• Selected Claude account routes credentials and org: Claude settings snapshots derive the selected token account, normalize credential routing, and carry account.sanitizedOrganizationID into the Claude provider settings. (Sources/CodexBar/Providers/Claude/ClaudeSettingsStore.swift:62, ada3660e9d61)

Likely related people:

• steipete: Git blame and related issue comments point to this handle for the current Claude token-account routing, org-field UI, and multiple-account support guidance. (role: recent area contributor; confidence: high; commits: f380287041b8; files: Sources/CodexBar/PreferencesProviderSettingsRows.swift, Sources/CodexBar/PreferencesProvidersPane.swift, Sources/CodexBar/Providers/Claude/ClaudeSettingsStore.swift)
• BAKEZQ: Recent shared token-account descriptor and settings-row work expanded account metadata plumbing used by the Claude org-field surface. (role: recent adjacent contributor; confidence: medium; commits: 2435c93453fe; files: Sources/CodexBar/Providers/Shared/ProviderSettingsDescriptors.swift, Sources/CodexBar/PreferencesProviderSettingsRows.swift, Sources/CodexBar/PreferencesProvidersPane.swift)
• ratulsarna: In the broad multiple-account discussion, this handle gave the closest maintainer-visible signal on the feasibility of rotating local Claude signed-in sessions. (role: prior product-direction commenter; confidence: medium)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[jroth1111]

+1 — I use claude-swap daily (the cswap command, v0.14.0 via uv tool) to manage multiple Claude subscription accounts, and I'd love CodexBar to display usage across all of them.

To be specific about the ask: I'm looking for multi-subscription account support via OAuth — i.e., tracking several consumer Claude Pro/Max subscriptions side by side — not API keys or token accounts. CodexBar already covers the API-key / Admin-API / token-account paths; the actual gap is multiple OAuth subscription accounts shown together.

Worth noting why the existing tokenAccount path can't back this: ProviderTokenAccount (Sources/CodexBarCore/TokenAccounts.swift, current main) holds a single token string — no refreshToken, no expiresAt. Anthropic OAuth access tokens are short-lived (~1h), so an sk-ant-oat token placed in a tokenAccount expires with no way to refresh and silently goes stale within hours. Durable multi-subscription OAuth needs the account model extended (refresh-token + expiry), or CodexBar delegating to a switcher that already handles per-account OAuth refresh.

claude-swap already exposes what CodexBar would need, without CodexBar touching credentials:

• cswap --list --json --token-status — machine-readable list of all managed accounts, including OAuth token expiry state
• cswap --status --json — the currently active account
• --strategy best picks the account with the most remaining 5h/7d quota, so claude-swap already computes the per-account quota figures CodexBar would surface

A low-risk integration: CodexBar shells out to cswap --list --json --token-status to enumerate managed accounts and show their quota/usage in the menu — CodexBar never handles credential storage/switching, since claude-swap owns that. This sidesteps both the refresh problem above and the secret-storage boundary.

Related: #1715 (the in-app "add second Claude account" flow currently hangs on "waiting for browser" and never creates a stored account). Happy to share the JSON schema or test a build.

[steipete]

Decision-ready architecture and UI proof is in #1812.

The proposal incorporates @jroth1111's durable OAuth/refresh observation and verifies the current claude-swap v0.15 schema. Recommendation: an opt-in, read-only cswap --list --json adapter; no credential/Keychain reads, no CodexBar OAuth vault, and no switching in Phase 1. Results first normalize behind a provider-neutral account snapshot.

The related broken sign-in action is separately fixed and merged in #1811; it now performs the dedicated Claude Code auth flow without claiming to create a durable CodexBar account.

Leaving this issue open for the maintainer decision on the optional external dependency and whether switching should become a later explicit-action phase. Thanks @jroth1111 for the concrete schema and refresh-boundary detail.

[jroth1111]

Anytime @steipete, thanks for a great tool!

[LawyZheng]

Opened #1829 as a zero-dependency complement to the claude-swap direction in #1812 — it makes the credential layer itself CLAUDE_CONFIG_DIR-aware.

While digging into this I confirmed on macOS that Claude Code already isolates each CLAUDE_CONFIG_DIR into its own Keychain entry (not a single overwritten one):

Config dir	Keychain service	File
~/.claude (default)	Claude Code-credentials	~/.claude/.credentials.json
custom CLAUDE_CONFIG_DIR	Claude Code-credentials-<hash>	$CLAUDE_CONFIG_DIR/.credentials.json

where <hash> = first 8 hex chars of sha256(<config dir absolute path>). Verified against a live machine: sha256("/Users/…/.claude-work")[0..<8] → da6d47a8 → an actual Claude Code-credentials-da6d47a8 entry sitting alongside the default one.

So for the common "I run several subscriptions, each under its own CLAUDE_CONFIG_DIR" setup, CodexBar can read every account's usage directly — real OAuth tokens with working refresh, no external tool and no pasted credentials to expire.

#1829 is intentionally infrastructure-only (no UI / account enumeration / storage):

• claudeKeychainService becomes computed from the active CLAUDE_CONFIG_DIR — one change makes all 14 existing references resolve to the right account
• the credentials file path follows the config dir
• in-memory + Keychain caches are scoped per account (default key unchanged, backward compatible)
• the config dir is injected as a TaskLocal at the loadRecord entry point; the environment dict already flows end-to-end

It's meant to sit under whatever UX you land on — a cswap --list --json adapter and this can coexist (adapter for discovery/switching, this for reading native tokens per dir). Happy to adjust to match the #1812 plan.