Skip to content

Feature: Auto-switch accounts based on git config #12459

Description

@jayproulx

Summary

Add native support for automatic account switching based on git configuration, specifically reading git config github.account to 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, gh CLI requires manual account switching with gh auth switch, which breaks the seamless multi-account workflow.

Current workflow (manual):

# Working on personal project
cd ~/projects/personal
gh auth switch --user personal-account
gh pr create

# Switching to work project  
cd ~/projects/work
gh auth switch --user work-account
gh pr create

Desired workflow (automatic):

# Working on personal project
cd ~/projects/personal
gh pr create  # Uses personal-account automatically

# Switching to work project
cd ~/projects/work  
gh pr create  # Uses work-account automatically

Proposed Solution

Enhance gh to read git config github.account and automatically use that account if:

  1. The config value exists
  2. The user has authenticated with that account

This mirrors how git itself handles multiple identities through conditional includes.

Example: Directory-based git configuration

# ~/.gitconfig
[includeIf "gitdir:~/projects/personal/"]
    path = ~/.gitconfig-personal
[includeIf "gitdir:~/projects/work/"]
    path = ~/.gitconfig-work

# ~/.gitconfig-personal
[user]
    name = Personal Name
    email = [email protected]
[github]
    account = personal-username

# ~/.gitconfig-work
[user]
    name = Work Name
    email = [email protected]
[github]
    account = work-username

With this setup:

  • cd ~/projects/personal && git config github.account → returns personal-username
  • cd ~/projects/work && git config github.account → returns work-username
  • Git automatically applies the correct config based on directory
  • gh would automatically use the corresponding authenticated account

Implementation

The logic would be:

  1. Check for git config github.account
  2. If found and user is authenticated with that account, use it
  3. Otherwise, fall back to current behavior (active account)

This is backward compatible - it only activates when the config exists.

User Workaround

Users can currently implement this with a shell function wrapper:

gh() {
  local gh_account=$(git config github.account 2>/dev/null)
  
  if [[ -n "$gh_account" ]]; then
    if ! command gh auth status 2>&1 | grep -q "$gh_account.*Active account: true"; then
      command gh auth switch --user "$gh_account" &>/dev/null
    fi
  fi
  
  command gh "$@"
}

However, native support would benefit all users managing multiple accounts.

Benefits

  • Zero friction: Matches existing git multi-identity patterns
  • Backward compatible: Only activates when config exists
  • Proven pattern: Leverages git's established conditional include mechanism
  • Low complexity: Simple config value lookup
  • Better UX: Eliminates manual account switching

Related

This aligns with how other tools handle multi-account scenarios (e.g., AWS CLI with profiles, kubectl with contexts).

Activity

  1. added
    enhancementa request to improve CLI
    and removed on Feb 2, 2026
  2. yuvrajangadsingh commented on Feb 6, 2026

    @yuvrajangadsingh
    Contributor

    I'd love to work on this. I manage separate personal and work GitHub accounts and already use includeIf in my gitconfig for switching identity by directory. Having to manually run gh auth switch every 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() in internal/config/config.go, checking git config github.account before falling back to the stored active user. Happy to submit a PR if the team is open to it.

  3. added 2 commits that reference this issue on Feb 6, 2026
    ea67ca3
    c175d57
  4. bbbonnibel commented on Feb 9, 2026

    @bbbonnibel

    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!

  5. awakecoding commented on Feb 14, 2026

    @awakecoding

    +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

  6. deiga commented on Feb 19, 2026

    @deiga

    @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?

  7. davidlovas commented on May 27, 2026

    @davidlovas

    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 in ActiveUser(). 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. The gh CLI supporting multiple accounts but requiring manual switching between them is an incomplete feature. Would love to see this prioritized or at least labeled help wanted so the community can land it.

  8. eggplants commented on May 30, 2026

    @eggplants

    https://github.com/cli/cli/blob/9a2f33078d324e4ec175a035051436987acff810/docs/multiple-accounts.md#what-is-out-of-scope-for-this-release says:

    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?

  9. yuvrajangadsingh commented on Jun 1, 2026

    @yuvrajangadsingh
    Contributor

    author of #12628 here. davidlovas and eggplants are right, the close was procedural (no help wanted label on the issue) and not technical. the change is ~22 lines in ActiveUser() and matches the existing pattern git's includeIf already uses for user.name/user.email.

    happy to rebase and resubmit if maintainers can label this help wanted. let me know.

  10. bwt615 commented on Aug 27, 2026

    @bwt615

    Another 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 switch in one terminal silently changes which account every other concurrent session acts as, so a gh pr create intended 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 outside gh.

    A repo-scoped git config github.account pin 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, and includeIf scales 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 / logout untouched), with tests and docs — mindful of the help wanted policy 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 for help wanted?

  11. yuvrajangadsingh commented on Aug 27, 2026

    @yuvrajangadsingh
    Contributor

    +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 switch from 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 includeIf in 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.

  12. added
    coreThis issue is not accepting PRs from outside contributors
    on Aug 27, 2026
  13. davidlovas commented on Aug 28, 2026

    @davidlovas

    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.

  14. yuvrajangadsingh commented on Aug 28, 2026

    @yuvrajangadsingh
    Contributor

    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.

  15. sutarmin commented on Sep 19, 2026

    @sutarmin

    It sucks not to have this, commenting for visibility :)

  16. ValTM commented on Oct 8, 2026

    @ValTM

    I also need this functionality.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    coreThis issue is not accepting PRs from outside contributorsenhancementa request to improve CLI

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions