Support multiple Claude Code accounts with manual + automatic (on-limit) switching

[eddy-curly]

This was generated by AI during triage.

Summary

Add support for configuring multiple Claude Code accounts in the app and switching between them, so a user with more than one subscription can keep working when one account hits its usage limit.

Motivation / use case

The reporter has two Claude Code Max plan subscriptions and wants to use both with this application. When one account hits its usage limit, they want to fall back to the other instead of being blocked until the limit resets. Today this presumably requires manually re-authenticating with the other account, which is disruptive.

Note: This issue captures the desired behaviour only. Feasibility and the implementation approach have not been investigated yet — a follow-up investigation against the codebase is expected before this is picked up for build. Please do not treat the requirements below as an approved design.

User story

As a user with multiple Claude Code accounts, I want the app to hold more than one account and switch between them — automatically when I hit a limit, or manually on demand — so I can keep working without re-authenticating each time.

Requirements

Based on the reporter's answers:

1. Multiple accounts stored simultaneously — the app should keep more than one Claude Code account authenticated/saved at the same time. Switching should be instant, with no re-login.
2. Manual switching — the user can explicitly choose which account is active (e.g. a toggle/dropdown in the UI).
3. Automatic failover — when the active account hits its usage/rate limit, the app should automatically switch to another available account.
4. Per-account usage visibility — surface each account's status in the UI (which account is active, and remaining usage / limit state where available) so the user can see where they stand before hitting a wall.
5. General feature — build this as a reusable feature that any user could use to configure and switch between multiple accounts, not a one-off personal hack.

Open questions (for the feasibility investigation)

• How are Claude Code credentials currently stored/authenticated in the app? Can multiple credential sets coexist?
• Is per-account usage/limit data actually available to the app, or is limit-hit only detectable via an error response? This determines how much of requirement [Bug]: Azure DevOps source control shows "not available" on Windows because the 5s CLI probe times out on slow az --version (misclassified as missing) #4 is achievable.
• How is a "limit hit" surfaced today (error type / status code / message)? This drives the automatic-failover trigger.
• What's the right precedence when multiple accounts are available (round-robin, ordered priority, least-recently-limited)?

Scope notes

• Automatic switching should not silently lose in-flight work — behaviour on failover mid-request needs to be defined during design.
• Manual switch should always be available as an override, even when automatic failover is enabled.

Proposed breakdown into sub-issues

This is large enough to act as a parent/epic. The work splits into smaller, independently-shippable slices (rough dependency order — each can become its own linked sub-issue):

1. Multi-account credential storage (foundation) — persist and hold more than one Claude Code account's credentials at once; add / remove / list configured accounts. Blocks everything below.
2. Manual account switcher — UI to pick the active account (toggle/dropdown) with instant, no-re-login switching. Depends on t3x: auto-build & install the desktop app on change #1.
3. Per-account usage/limit display — show each account's status: which one is active, plus remaining usage / limit state where the data is available. (The reporter's example.) Depends on t3x: auto-build & install the desktop app on change #1.
4. Limit-hit detection — reliably identify when the active account has hit its usage/rate limit (pin down the signal: error type / status code / message). Foundation for failover; also feeds fix(t3x): auto-build defects found running the LaunchAgent for real #3.
5. Automatic failover on limit — when a limit is detected, switch to the next available account automatically. Depends on t3x: auto-build & install the desktop app on change #1 and [Bug]: Azure DevOps source control shows "not available" on Windows because the 5s CLI probe times out on slow az --version (misclassified as missing) #4.
6. Failover policy / account precedence — configure fallback order (ordered priority, round-robin, or least-recently-limited). Depends on Ungraceful backend exit leaves in-flight turns frozen as running → surface as cancelled; auto-resume doesn't recover them #5.
7. In-flight request handling on failover — retry/resume the interrupted request on the new account without losing work. Depends on Ungraceful backend exit leaves in-flight turns frozen as running → surface as cancelled; auto-resume doesn't recover them #5.

Minimal first vertical slice: #1 + #2 (store two accounts and switch manually) delivers value on its own; automatic failover (#4–#7) and usage visibility (#3) can follow.

[radroid]

There has been a similar issue that was addressed by the T3 code team and I do not intend to make the Anthropic team unhappy with this, so going to leave it out.