Allow multiple account in the status bar for same provider.

[simon-easyprog]

Having the possibilities to show different accounts in the status bar for the same provider.
If i have two openai subscription i would like to be able to see both so i can keep track on the usage of each one without having to open the menu.

It could be a global settings or if we want more granular control in the providers -> provider (codex, calude ...) -> accounts -> add a flag beside the mark it as a separate icon in the status bar.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 4, 2026, 1:08 PM ET / 17:08 UTC.

Summary
Keep open: current main still has provider-scoped status items and only menu-level multi-account display, while the merged architecture document is a decision record and the owner comment explicitly left this issue open for product choices.

Reproducibility: not applicable. as a bug reproduction: this is a feature request. Source inspection still confirms the missing capability because current main has provider-scoped status item identity/storage and no account-scoped status item case.

Root-cause cluster
Relationship: canonical
Canonical: #1268
Summary: This issue remains the canonical status-bar account visibility request; later related items cover broader same-provider instances or Claude-specific data acquisition mechanisms.

Members:

• partial_overlap: Feature request: Support multiple accounts or instances of the same provider #1843 - It asks for multiple same-provider accounts/instances generally, including independent display, but is broader than status-bar account item behavior.
• partial_overlap: Support multiple Claude accounts OR support account swapping with claude-swap #1756 - It covers multiple Claude accounts and claude-swap/account-switching integration, which can feed this issue but does not replace the provider-neutral status item decision.
• partial_overlap: Feature: Claude usage source via minimal inference call reading anthropic-ratelimit-unified-* headers (multi-account with setup-tokens / user:inference) #1894 - It proposes a Claude-specific setup-token usage source that could feed multi-account display, but it does not itself implement account status items.
• partial_overlap: Document Claude multi-account architecture #1812 - The merged PR documents the accepted architecture and references this issue, but explicitly does not add runtime behavior.
• adjacent_distinct: Fix Claude Code sign-in flow #1811 - It fixes Claude sign-in wording/flow and explicitly says multiple Claude subscriptions require a separate product/auth decision.
• 1 more in the report.

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.

Next step
The remaining action is maintainer product/auth review of the accepted account snapshot and status-item mode, not an autonomous fix PR.

Review details

Best possible solution:

Use the accepted provider-neutral account snapshot path, then add opt-in selected account status items that replace the provider item, cap selected accounts, preserve existing provider positions, and stay mutually exclusive with Merge Icons.

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

Not applicable as a bug reproduction: this is a feature request. Source inspection still confirms the missing capability because current main has provider-scoped status item identity/storage and no account-scoped status item case.

Is this the best way to solve the issue?

No for the original additive toggle as written; the narrower maintainable direction is the documented selected-account replacement mode after provider-neutral account snapshots land.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The original additive per-account toggle proposal conflicts with the accepted recommendation to replace that provider's aggregate item and keep account icons mutually exclusive with Merge Icons.
• The implementation touches account identity, persisted status item autosave names, provider auth/source boundaries, and privacy labels, so it needs maintainer product/auth approval before code work.

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

Label changes

Label changes:

• add impact:auth-provider: The request centers on tracking multiple accounts for the same provider while preserving account identity and auth boundaries.
• add impact:ux-friction: Users can inspect multi-account usage in menus today, but cannot keep multiple same-provider account quotas visible in the menu bar.

Label justifications:

• P3: This is a useful but opt-in account/status-bar feature request, not a broken current workflow.
• impact:auth-provider: The request centers on tracking multiple accounts for the same provider while preserving account identity and auth boundaries.
• impact:ux-friction: Users can inspect multi-account usage in menus today, but cannot keep multiple same-provider account quotas visible in the menu bar.

Evidence reviewed

Acceptance criteria:

• After product sign-off, validate through focused model/menu tests, status item identity/migration tests, make check, make test, packaged synthetic proof, and redacted macOS UI proof as described in docs/claude-multi-account-and-status-items.md.

What I checked:

• Repository policy read: AGENTS.md was read fully; provider data siloing, no live Keychain/provider probes, and model-seam test guidance apply to any eventual implementation. (AGENTS.md:1, 2c56846ab842)
• Vision sign-off boundary: VISION.md supports shared provider-driven UI but puts new features and provider auth/storage/privacy behavior in the sign-off bucket. (VISION.md:1, 2c56846ab842)
• Provider-scoped status item identity: StatusItemIdentity currently has only merged and provider cases with provider autosave names; there is no account identity case. (Sources/CodexBar/StatusItemController.swift:47, 2c56846ab842)
• Provider-keyed status item storage: The split status item map is keyed as [UsageProvider: NSStatusItem], so current main cannot represent multiple status items for different accounts of the same provider. (Sources/CodexBar/StatusItemController.swift:123, 2c56846ab842)
• Existing multi-account display is menu-only: Token account display builds segmented or stacked account menu models when multiple accounts exist, not account-scoped menu bar items. (Sources/CodexBar/StatusItemController+AccountMenuDisplay.swift:29, 2c56846ab842)
• Documentation confirms current menu scope: Claude docs say manual token accounts can show all accounts stacked or as a switcher bar inside the menu. (docs/claude.md:89, 2c56846ab842)

Likely related people:

• steipete: Authored and merged the current Claude multi-account decision document and left the owner comment keeping this issue open for product choices. (role: recent area contributor and product-direction owner; confidence: high; commits: 58968bd8b52e, f84a171bca1b; files: docs/claude-multi-account-and-status-items.md, Sources/CodexBar/StatusItemController.swift)
• Magicien: Introduced the menu bar item identity preservation work that underpins the current merged/provider autosave-name model. (role: status item identity contributor; confidence: medium; commits: 22cf7d4d2b76; files: Sources/CodexBar/StatusItemController.swift, Tests/CodexBarTests/StatusItemControllerSplitLifecycleTests.swift)
• Alasdair McCall: Implemented the stack-vs-segmented multi-account menu option that is adjacent to, but narrower than, the requested status bar behavior. (role: multi-account menu layout contributor; confidence: medium; commits: 28f53946ea27; files: Sources/CodexBar/UsageStore+TokenAccounts.swift, Sources/CodexBar/PreferencesDisplayPane.swift, Tests/CodexBarTests/StatusMenuCodexSwitcherTests.swift)
• Behnam M: History shows earlier work consolidating provider status items into the unified icon path that the current Merge Icons model builds on. (role: merged status item contributor; confidence: low; commits: 157802bced26; files: Sources/CodexBar/StatusItemController.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.

[CodeWithShreyans]

this would be really helpful, especially with something like a Claude sub + Claude Console/API

[robd003]

I would also like to be able to track multiple accounts. I frequently switch between two accounts whenever I hit rate limits.

[jslitzkerttcu]

Proposal + offer to implement (pending sign-off)

I'd like to pick this up if maintainers are open to it. Sketching the UX/implementation here first since per-account status items fall under VISION.md "Needs Sign-Off."

Scope: Provider-agnostic (not Claude/Codex-specific), so it stays shared provider-driven UI rather than a one-off surface.

UX (opt-in, default off):

• Providers → (provider) → Accounts → per-account toggle: "Show as separate menu bar icon."
• Off by default → zero change for existing users; accounts keep showing in the in-menu switcher/stacked-card modes.
• When ≥1 account opts in, that account gets its own NSStatusItem rendering its own usage/reset; the rest stay grouped under the existing provider item.
• Plays alongside Merge Icons mode (account items follow the same merge/standalone rules as provider items).

Implementation seam:

• Extend StatusItemIdentity (StatusItemController.swift) from .merged / .provider to an account-capable case.
• Move provider item storage from [UsageProvider: NSStatusItem] to an identity-keyed map; add stable autosave names + ordering + visibility recovery per account item.
• Config migration so existing provider items are untouched on upgrade.

Constraints I'd honor (per AGENTS.md):

• Strict provider/account data siloing — no cross-account identity/plan bleed.
• hide-personal-info respected in per-account rendering (no emails leaking into the menu bar when that's disabled).
• Tests through model seams (MenuDescriptor, account section state), not live NSStatusBar/NSMenu; XCTest cases for upgrade migration, ordering, privacy, and menu behavior.

Open questions for maintainers:

1. Is per-account status-bar visibility a direction you want, given in-menu account display already exists?
2. Account-level toggle in Settings vs. a global mode — preference?
3. Any cap on number of standalone account items before it's pushed into the switcher?

Happy to open the PR with screenshots/GIF once the direction + UX are greenlit.

[steipete]

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

Recommendation: introduce a provider-neutral account usage snapshot, then add an opt-in “Selected account icons” mode that replaces that provider's aggregate item, caps selection at four, uses aliases/ordinals instead of email, and remains mutually exclusive with Merge Icons.

The document also preserves and compares @jslitzkerttcu's additive per-account toggle proposal (selected accounts get items while the rest remain grouped and Merge Icons coexists). That option is more granular, but it creates duplicate provider/account items and makes “Merge Icons” no longer mean one item.

Leaving this issue open for the product choices; no status-item behavior or persistence changed yet. Thanks @jslitzkerttcu for the provider-agnostic implementation sketch.