Goal
Use multiple accounts on the same GitHub host concurrently, including separate personal and work accounts on GitHub.com, with explicit repository-to-account selection.
This is the Run phase, building on host-aware connections in Walk (#9004). Crawl (#9003 / #8996) provides basic multi-Enterprise configuration and account switching; Walk adds simultaneous hosts. Neither phase provides simultaneous accounts on one host.
User experience
In one window, a user should be able to work on repository A with one account and repository B with another account on the same host, without repeatedly changing a provider-wide preference. The selected account and its permissions should be clear, and changing one binding should not silently switch unrelated repositories.
Scope
- Identify connections by provider, issuer/deployment, and account. Do not rely on account labels or native IDs being globally unique.
- Define an explicit repository-to-account binding and account-picker experience. Do not infer authentication identity from Git commit authorship or a username embedded in a remote URL.
- Decide where bindings persist, how workspace preferences interact with user preferences, and what happens when a binding is absent, inaccessible, signed out, or removed.
- Request and validate the intended account and issuer for every repository-bound operation, including reauthentication and scope upgrades. Never silently retry an operation with another account just because it has access.
- Partition permission-sensitive repository metadata, user caches, reviews/comments, and notifications by connection identity, including when the same repository is accessible to several accounts.
- Define account selection or aggregation for hostless tools, notifications, clone/search, and agent entry points.
- Keep sign-in, consent, switching, and removal explicit while reusing native authentication/account UX where the platform supports it.
Design prerequisite
Verify which VS Code authentication and account-preference APIs can express the required bindings before committing to the UX. Coordinate with upstream structured-account identity work rather than encoding identities into display labels or creating a competing preference store without a clear need.
Acceptance
- Two GitHub.com accounts can operate concurrently on different repositories in one window.
- Two accounts on the same Enterprise instance can operate concurrently, including different permissions and scope sets.
- Switching/signing out/re-authenticating one binding does not change another account's repositories or cached state.
- Ambiguous or missing bindings produce an actionable choice/error, not an unintended account fallback.
- Regression coverage proves credentials, comments, notifications, and permission-sensitive data do not cross account boundaries, with real-account verification across supported environments.
Related
Goal
Use multiple accounts on the same GitHub host concurrently, including separate personal and work accounts on GitHub.com, with explicit repository-to-account selection.
This is the Run phase, building on host-aware connections in Walk (#9004). Crawl (#9003 / #8996) provides basic multi-Enterprise configuration and account switching; Walk adds simultaneous hosts. Neither phase provides simultaneous accounts on one host.
User experience
In one window, a user should be able to work on repository A with one account and repository B with another account on the same host, without repeatedly changing a provider-wide preference. The selected account and its permissions should be clear, and changing one binding should not silently switch unrelated repositories.
Scope
Design prerequisite
Verify which VS Code authentication and account-preference APIs can express the required bindings before committing to the UX. Coordinate with upstream structured-account identity work rather than encoding identities into display labels or creating a competing preference store without a clear need.
Acceptance
Related