Copilot plugin does not support gh CLI multi-account — always uses wrong account's token

[MaxAnderson95]

Summary

The copilot plugin does not support the gh CLI's multi-account feature. When multiple GitHub accounts are authenticated via gh auth login, the plugin picks whichever token macOS Keychain returns first for the gh:github.com service — which may not be the intended account. In my case, it consistently fetches usage for my personal account instead of my enterprise Copilot account.

Environment

• macOS (Apple Silicon)
• OpenUsage 0.6.9
• gh CLI with two accounts authenticated on github.com (one personal, one enterprise — the enterprise account is set as active)

Root Cause

In plugin.js, loadTokenFromGhCli() reads from the keychain using only the service name:

const GH_KEYCHAIN_SERVICE = "gh:github.com";
// ...
const raw = ctx.host.keychain.readGenericPassword(GH_KEYCHAIN_SERVICE);

The gh CLI stores each account's token under the same service (gh:github.com) but with a different account attribute in the keychain entry. Since readGenericPassword is called with only the service name and no account specifier, macOS returns whichever entry it finds first — which happens to be my personal account, not the enterprise one.

That token then gets persisted into plugins_data/copilot/auth.json, further cementing the wrong credentials.

Steps to Reproduce

1. Authenticate two GitHub accounts via gh auth login (e.g., one personal, one enterprise with Copilot)
2. Set the enterprise account as active (gh auth switch)
3. Install OpenUsage and enable the copilot plugin
4. Observe that the usage bar shows the personal account's Copilot usage, not the enterprise account's

Suggested Fixes

A few approaches that could address this, in rough order of user impact:

1. Respect gh CLI's active account: Read gh auth status (or the gh CLI config/state files) to determine which account is currently active, then look up the keychain entry using both the service name and the account name. This would make OpenUsage match the user's gh CLI context automatically.

2. Add a plugin setting for account selection: Allow users to configure which GitHub account the copilot plugin should use (e.g., a github_account field in the plugin config or OpenUsage settings). This would let the plugin call readGenericPassword with both the service and account name.

3. Support multiple Copilot instances: Ideally, when multiple gh accounts are detected, OpenUsage could show a separate usage bar for each account's Copilot subscription (similar to how you might track multiple AI services). Each instance would use its respective account's token.

4. Prompt on ambiguity: If multiple gh:github.com keychain entries are detected and no preference is configured, surface a one-time prompt or settings entry asking the user which account to use.

Any of these would resolve the current behavior where the plugin silently uses the wrong account with no way for the user to control it.

[robinebers]

In #331 I've introduced a new host API that may deprecate the existing one. It only reads the current user. If you'd like, you could add a PR that refactors the plugin, and respect the gh auth status.