Repository navigation
Feature: Auto-switch accounts based on git config #12459
Description
Activity
- addedenhancementa request to improve CLIa request to improve CLIand removedneeds-triageneeds to be reviewedneeds to be reviewed
on Feb 2, 2026 I'd love to work on this. I manage separate personal and work GitHub accounts and already use
includeIfin my gitconfig for switching identity by directory. Having to manually rungh auth switchevery time I move between repos breaks the workflow.I've looked at the codebase and the change seems scoped - the injection point would be
ActiveUser()ininternal/config/config.go, checkinggit config github.accountbefore falling back to the stored active user. Happy to submit a PR if the team is open to it.Reacted by Ramses Kools- added 2 commits that reference this issue
on Feb 6, 2026 Yes please! I'd use this, and I'm eager to see #12628 get merged. I'm an alter in a plural system and we have different accounts and projects we work on. And even non-plural people might have different projects they work on with different accounts. This would be good and helpful!
+1 for this being a huge PITA when working with multiple GitHub accounts, especially when using them concurrently. I implemented a simple auth mapping mechanism to automatically select the right auth account based on the GitHub repo URL, similar to includeIf in the SSH configuration. I prefer an approach that doesn't rely on external git configuration, even if it means creating simple rules just got GitHub CLI. Here's my pull request, I've started using it myself after building it locally: #12681
@BagToad Since you closed the PR which proposes a fix for this, could you provide details if this request is being worked on by the core team?
This is a daily pain point for anyone managing separate personal and work GitHub accounts — which is a huge chunk of your user base.
A clean, working PR (#12628) was submitted and closed because the issue wasn't labeled
help wanted— not because of any technical problem with the implementation. The change is ~22 lines inActiveUser(). I could implement this myself in five minutes.Meanwhile, the workaround is a shell wrapper that mutates global auth state on every invocation, which isn't safe across concurrent terminal sessions.
Git solved conditional identity switching years ago with
includeIf. TheghCLI supporting multiple accounts but requiring manual switching between them is an incomplete feature. Would love to see this prioritized or at least labeledhelp wantedso the community can land it.Reacted by Ramses KoolsReacted by haruna, Ramses Kools and georgekyriakopoulos- marked gh should auto-select account based on repo remote / git config #13529 as a duplicate of this issue
on May 27, 2026 - added 5 commits that reference this issue
on May 29, 2026 While these are not out of scope forever, for this release some of the big things we have intentionally not included are:
Automatic configuration of git config such as user.name and user.email when switching
Is it a business issue that the PR isn't being accepted even though it has already been created?
- added a commit that references this issue
on May 30, 2026 author of #12628 here. davidlovas and eggplants are right, the close was procedural (no
help wantedlabel on the issue) and not technical. the change is ~22 lines inActiveUser()and matches the existing pattern git'sincludeIfalready uses foruser.name/user.email.happy to rebase and resubmit if maintainers can label this
help wanted. let me know.Reacted by Matt Langreder, Ramses Kools and Max StrueverAnother data point for triage, from running many concurrent automated sessions on one machine with two accounts (work + personal): the global active account is not just inconvenient, it is an identity-safety problem.
gh auth switchin one terminal silently changes which account every other concurrent session acts as, so agh pr createintended for the work account can be filed by the personal one (or the reverse) depending on timing. The existing workarounds (GH_TOKEN=$(gh auth token --user ...)per command, wrapper shims) all amount to reimplementing per-context account selection outsidegh.A repo-scoped
git config github.accountpin as proposed here fixes that class of bug: identity becomes a function of the repository being touched rather than of shared mutable state external to the process, andincludeIfscales it to whole directory trees.I've opened #14269 implementing exactly this proposal (env tokens still win; an unauthenticated pin falls back to the active account;
auth switch/status/logoutuntouched), with tests and docs — mindful of thehelp wantedpolicy that closed #12628, so please treat it as a concrete artifact for evaluating the proposal rather than a queue-jump. Would the team consider triaging this issue forhelp wanted?+1 to the concurrent-sessions point, with a concrete instance. i run several automated sessions on this machine across a personal and a work account, and on aug 2 a
gh auth switchfrom one session silently flipped the active account under another one mid-run. the second session then tried to edit a PR as the wrong identity and failed with a permissions error, and it took a while to work out why, nothing about the failing command suggests the account changed underneath it.git itself already solves this per-directory with
includeIfin gitconfig, which is what #12628 extended to gh (~22 lines, closed on process rather than substance). happy to reopen and rebase it if a maintainer wants to label this.Reacted by David Lovas- addedcoreThis issue is not accepting PRs from outside contributorsThis issue is not accepting PRs from outside contributors
on Aug 27, 2026 I think @yuvrajangadsingh's PR should be reopened personally, had I not implemented a version of this for my own use case after my initial comment on this thread, this would be a regular nuisance. It deserves proper attention from the Github team.
thanks @davidlovas, appreciate that. looks like the team has since tagged this
core, so it's being taken in-house rather than via outside PRs. glad it's on the roadmap, happy to test a build whenever there's one.It sucks not to have this, commenting for visibility :)
I also need this functionality.
Summary
Add native support for automatic account switching based on git configuration, specifically reading
git config github.accountto determine which authenticated account to use for the current repository.Motivation
Many developers manage multiple GitHub accounts (personal, work, different clients) and use git's conditional includes (
includeIf) to automatically configure user identity per directory. However,ghCLI requires manual account switching withgh auth switch, which breaks the seamless multi-account workflow.Current workflow (manual):
Desired workflow (automatic):
Proposed Solution
Enhance
ghto readgit config github.accountand automatically use that account if:This mirrors how git itself handles multiple identities through conditional includes.
Example: Directory-based git configuration
With this setup:
cd ~/projects/personal && git config github.account→ returnspersonal-usernamecd ~/projects/work && git config github.account→ returnswork-usernameghwould automatically use the corresponding authenticated accountImplementation
The logic would be:
git config github.accountThis is backward compatible - it only activates when the config exists.
User Workaround
Users can currently implement this with a shell function wrapper:
However, native support would benefit all users managing multiple accounts.
Benefits
Related
This aligns with how other tools handle multi-account scenarios (e.g., AWS CLI with profiles, kubectl with contexts).