Feature: Auto-switch accounts based on git config

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:

The config value exists
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:

Check for git config github.account
If found and user is authenticated with that account, use it
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

+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

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

Upstream sync 2026-05-29 (#16)

Upstream sync 2026-05-29 (#19)

feat: auto-select authenticated account based on repo context

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?

feat: auto-select authenticated account based on repo context

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.

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?

+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.

@yuvrajangadsingh

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.

@davidlovas

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.

Until this lands natively, I built a small wrapper that does this: https://github.com/barnuri/ghx

It maps folders to gh accounts (~/.config/ghx/config.yaml, deepest match wins) or a per-repo .ghx file, then runs the real gh with GH_TOKEN from gh auth token --user <login>. It never calls gh auth switch, so terminals and agents in different folders don't change each other's account. All gh commands, flags and extensions pass through unchanged. It installs as a gh shim, and gh auth git-credential gets the folder's token, so git push uses the right account too.

Navigation Menu

Repository navigation

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

Summary

Motivation

Proposed Solution

Implementation

User Workaround

Benefits

Related

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary

Motivation

Proposed Solution

Implementation

User Workaround

Benefits

Related

Activity

yuvrajangadsingh commented on Feb 6, 2026

bbbonnibel commented on Feb 9, 2026

awakecoding commented on Feb 14, 2026

deiga commented on Feb 19, 2026

davidlovas commented on May 27, 2026

eggplants commented on May 30, 2026

yuvrajangadsingh commented on Jun 1, 2026

bwt615 commented on Aug 27, 2026

yuvrajangadsingh commented on Aug 27, 2026

davidlovas commented on Aug 28, 2026

yuvrajangadsingh commented on Aug 28, 2026

sutarmin commented on Sep 19, 2026

ValTM commented on Oct 8, 2026

barnuri commented on Oct 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions