Can not work with multiple accounts

[titan-ron]

I have multiple accounts, and I can't connect to both and pick which Copilot license to use. Which keeps either blocking my session cause I don't have the same limit - and if removing the limited account, I cannot commit and work against these repos without workarounds. With IntelliJ and VSCode, I based it on the CLI, and it's not happening. I already marked this option in the settings, and it's not helping.

---

Field	Value
App version	1.0.17
OS	macOS 26.5.0
Theme	GitHub
Path	/chat
Tenure	Week 3

[jokeyrhyme]

possibly duplicates or is otherwise related to #1715

[titan-ron]

I'd like to reframe this as a concrete, fairly small feature request, because I think the hard part is already built.

The actual problem

Today the app binds one GitHub account per project, and that single binding does two unrelated jobs:

1. Repo access — clone/fetch/push, PRs, issues.
2. AI usage — which Copilot license/quota (or custom provider) serves inference.

These two should not be coupled. The account that has access to a repo is very often not the account whose Copilot plan I want to spend. When they're forced to be the same account, you get the failure mode in this issue and in #1715: the project must use Account A for repo access, so Account A's exhausted/deactivated Copilot entitlement blocks the session — and switching to Account B to get quota costs me push access and Git identity.

There's a second, less obvious symptom: custom model providers (BYOK) are stored scoped to an account. So choosing the project's account also silently narrows which custom providers are selectable, even though a BYOK endpoint has nothing to do with which GitHub account owns the repo.

Why this should be cheap: the runtime already supports it

The agent runtime already isolates GitHub auth per session — it's covered by the public E2E suite in github/copilot-sdk:

• nodejs/test/e2e/per_session_auth.e2e.test.ts — "Per-session GitHub auth" — creates two sessions from the same client with gitHubToken: "token-alice" (plan individual_pro) and gitHubToken: "token-bob" (plan business), and asserts that gitHubAuth.getStatus() returns the correct login and copilotPlan for each, i.e. auth is isolated between concurrent sessions.
• CopilotClient already passes a per-process token via --auth-token-env COPILOT_SDK_AUTH_TOKEN.
• The RPC surface already has account.getAllUsers (documented as "all authenticated users available for account switching"), account.getCurrentAuth, and account.getQuota({ gitHubToken }) — so quota is resolvable per token, not per app-global "active account".
• A separate direct-API auth mode already exists for BYOK (GITHUB_COPILOT_API_TOKEN + COPILOT_API_URL).

So this isn't "add multi-account support to the runtime". The runtime can already run a session under a different token than the one used for Git. What's missing is a setting in the app's project model to express that.

Proposal

1. Split the per-project account binding into two independent settings.

Setting	Used for	Default
Repo identity	Git remote auth, commit/push, PRs, issues, checks	The account that has access to the repo (today's behavior — unchanged)
AI identity	Copilot license/quota, model list, credits, BYOK provider	Same as Repo identity, overridable

Defaulting AI identity to Repo identity means zero behavior change for single-account users, and no migration.

2. Decouple custom providers from the account binding. Account-scoped providers should be selectable, not gating. If I've configured an Azure/OpenAI-compatible endpoint under any signed-in account, I should be able to attach it to any project.

3. Resolve AI identity in this order (first match wins):

session override  →  project setting  →  global default  →  repo identity

4. Add a global default: "Preferred account for Copilot usage" in Settings, so new projects inherit the right one instead of defaulting to whichever account owns the repo.

5. Read quota/credits from the AI identity, and name the account in every quota message. Something like "Monthly AI credits exhausted for @account-b — switch this project's AI account?" with a one-click switch. This alone would have prevented most of the confusion in #1715 and #1500, where the displayed quota didn't match the account the user believed was selected.

6. Guardrails.

• Never use the AI-identity token for Git or repo API operations, and never the reverse.
• When AI identity ≠ repo identity, show it plainly in the project header/session UI, and warn rather than block — cross-account is the intended use case here, not an error.
• Respect enterprise managed settings from whichever account actually serves the request (the runtime already emits a managed-settings resolution event on account switch, so the app can reflect this).

Why it matters

Anyone with a work account plus a personal account is affected — contractors, OSS maintainers with an employer seat, people on a Business/Enterprise seat who also hold Copilot Pro, and anyone whose org enforces a Copilot budget. Right now the workaround is to sign out of an account and lose repo access, or fall back to VS Code / the CLI, which don't force this coupling. Because the per-session token path already exists and tested, this looks primarily like a data-model + UI change in the app rather than new runtime capability.

Happy to help specify the settings UI or test matrix if that's useful.

[titan-ron]

This issue is still unresolved for us. Is there any update or recommended workaround?

cc: @EvanBoyle @aymenfurter