Feature request: Support multiple accounts or instances of the same provider

[bystritskiy]

Feature request: Support multiple accounts or instances of the same provider

Summary

Add the ability to configure multiple instances of the same provider and track their usage independently.

For example, a user may have two separate Claude Code installations or profiles on the same Mac:

• Personal Claude account
• Work Claude account

Each instance may use a different configuration or data directory. Currently, a provider can only be enabled once, so CodexBar can monitor only one account per provider.

Proposed solution

Allow users to duplicate a provider and configure each instance separately.

For example:

Claude — Personal
Config/data directory: ~/.claude

Claude — Work
Config/data directory: ~/Library/Application Support/Claude-Work

Each provider instance could:

• Have a custom display name or alias
• Use its own authentication and configuration source
• Allow selecting a custom config or data directory
• Track and display usage independently
• Appear as a separate item in CodexBar

A possible settings flow:

1. Select a provider such as Claude.
2. Click Add another account or Duplicate provider.
3. Enter an optional alias.
4. Select the provider's config or data directory.
5. CodexBar creates an independent instance of that provider.

Use case

I run two Claude installations on the same Mac, each using a separate account and user-data directory.

I would like CodexBar to show the remaining limits for both accounts at the same time, without having to sign in and out or replace the existing provider configuration.

This could also be useful for:

• Personal and work accounts
• Multiple client accounts
• Separate browser or CLI profiles
• Users with more than one subscription for the same provider

Additional context

Ideally, this would be implemented as a generic provider-instance model rather than Claude-specific behavior.

Any provider capable of loading credentials or usage information from a configurable location could then support multiple accounts.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 2, 2026, 8:42 AM ET / 12:42 UTC.

Summary
Keep open: current main has provider-scoped config plus some per-provider account mechanisms, but it does not support generic duplicate provider instances with separate aliases/config roots. The request overlaps existing product-direction work, so it should stay in maintainer review rather than be closed by cleanup.

Reproducibility: not applicable. this is a feature request, not a report of broken current behavior. Source inspection shows the requested duplicate provider-instance/config-directory model is not currently represented by the provider/config types.

Root-cause cluster
Relationship: partial_overlap
Canonical: #1268
Summary: This issue overlaps the existing same-provider multi-account product thread, while the Claude example also overlaps the narrower Claude account-switching thread and open architecture decision PR.

Members:

• canonical: Allow multiple account in the status bar for same provider. #1268 - Open older issue tracks same-provider multi-account/status-bar direction and has owner guidance referencing unresolved product choices.
• partial_overlap: Support multiple Claude accounts OR support account swapping with claude-swap #1756 - Open Claude-specific issue covers multiple Claude accounts and external account-switcher/profile integration.
• needs_human: Document Claude multi-account architecture #1812 - Open docs PR is the architecture/UI decision record, not a merged runtime implementation.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

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
Manual review is needed because the remaining action is a product/auth model decision, not a narrow autonomous fix.

Review details

Best possible solution:

Use the existing provider-neutral account snapshot/product decision path as the design anchor, then add generic same-provider account instances only after maintainers choose the UX, persistence, and auth boundaries.

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

Not applicable; this is a feature request, not a report of broken current behavior. Source inspection shows the requested duplicate provider-instance/config-directory model is not currently represented by the provider/config types.

Is this the best way to solve the issue?

Unclear; the generic model is plausible, but current maintainer discussion is already steering toward a provider-neutral account snapshot and selected-account UI, so this should not be implemented independently.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• This overlaps active product-direction work in Allow multiple account in the status bar for same provider. #1268, Support multiple Claude accounts OR support account swapping with claude-swap #1756, and Document Claude multi-account architecture #1812; implementing from this issue alone could fork the account model.
• The requested generic provider-instance model touches auth/config roots, persisted settings, account identity, and provider rendering, all of which need maintainer sign-off under VISION.md.

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

Label changes

Label changes:

• add P3: This is a useful but low-urgency multi-account feature request rather than a broken existing workflow.
• add impact:auth-provider: The request affects provider account identity, auth/config source selection, and independent usage routing.
• 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:fix-shape-clear: 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 useful but low-urgency multi-account feature request rather than a broken existing workflow.
• impact:auth-provider: The request affects provider account identity, auth/config source selection, and independent usage routing.

Evidence reviewed

What I checked:

• AGENTS policy read: Read the full repository AGENTS.md; provider data siloing, no live keychain/provider probes, and model-seam test guidance apply to any eventual implementation. (AGENTS.md:1, daba50847e18)
• Vision scope: VISION.md supports provider limit/status coverage and shared provider-driven UI, but new features and provider auth/data-storage changes need sign-off. (VISION.md:3, daba50847e18)
• Provider identity model: UsageProvider is a fixed provider enum, not an account/instance identity that can represent two Claude rows with different aliases or config directories. (Sources/CodexBarCore/Providers/Providers.swift:5, daba50847e18)
• Config currently deduplicates provider IDs: CodexBarConfig.normalized skips later entries with the same provider id, and setProviderConfig replaces by provider id, so duplicate provider instances are not currently represented. (Sources/CodexBarCore/Config/CodexBarConfig.swift:49, daba50847e18)
• Token accounts are nested under one provider: ProviderTokenAccountsFile stores a dictionary keyed by provider raw value, with account rows inside that provider rather than first-class provider instances. (Sources/CodexBarCore/TokenAccounts.swift:95, daba50847e18)
• Codex has a special home-routing path: ProviderRegistry applies home scoping only when provider == .codex, which is useful existing account routing but not a provider-neutral duplicate-instance model. (Sources/CodexBar/ProviderRegistry.swift:142, daba50847e18)

Likely related people:

• steipete: Git blame ties the current provider config, token-account baseline, and Codex routing code to Peter Steinberger, and owner comments on the related issues define the current product decision path. (role: recent area contributor and product-direction commenter; confidence: high; commits: 91bf4b4f02a1; files: Sources/CodexBarCore/Config/CodexBarConfig.swift, Sources/CodexBarCore/TokenAccounts.swift, Sources/CodexBar/ProviderRegistry.swift)
• BAKEZQ: Recent z.ai team-usage work added shared token-account metadata fields that sit on the same account model this request would likely need to evolve. (role: recent adjacent contributor; confidence: medium; commits: 2435c93453fe; files: Sources/CodexBarCore/TokenAccounts.swift)

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.