Select authenticated user via GH_USER env var

Describe the feature or problem you’d like to solve

I manage multiple GitHub accounts across several projects and must manually run gh auth switch to change identities or explicitly set a flag to choose which authenticated account to use. I often forget to switch, which leads to accidental operations under the wrong account and interrupts my workflow. I would like to set an environment variable in my current workspace to instruct/hint gh CLI which user it should use.

Proposed solution

When multiple users are authenticated, gh should respect an environment variable (e.g. GH_USER) to pick the active user non-interactively, similar to AWS CLI's AWS_PROFILE.

Additional context

$ gh auth status
github.com
  ✓ Logged in to github.com account gringolito (keyring)
  - Active account: false
  - Git operations protocol: https
  - Token: ************************************
  - Token scopes: **********************************

  ✓ Logged in to github.com account Filipe-Utzig (keyring)
  - Active account: true
  - Git operations protocol: https
  - Token: ************************************
  - Token scopes: **********************************
$ export GH_USER=gringolito
$ gh api /user | jq -r ".login"
gringolito
$ export GH_USER=Filipe-Utzig
$ gh api /user | jq -r ".login"
Filipe-Utzig

Thank you for your issue! We have categorized it as a feature request, and it has been added to our backlog. In doing so, we are not committing to implementing this feature at this time, but, we will consider it for future releases based on community feedback and our own product roadmap.

Unless you see the help wanted Contributions welcome label, we are not currently looking for external contributions for this feature.

If you come across this issue and would like to see it implemented, please add a thumbs up! This will help us prioritize the feature. Please only comment if you have additional information or viewpoints to contribute.

@gringolito

Thanks for sharing your feedback, @gringolito! 🍻

I see your point, and gh does have a similar offering, although it might not be very visible. You can override the GH_CONFIG_DIR env var to make gh switch to a different set of configuration and user accounts.

Surely you can do it in whatever way that suits your use case, but as an example you can create a directory for gh to store the configuration, assign and export the GH_CONFIG_DIR env var, login once with your account, and continue using gh in the same shell/environment:

mkdir ~/profile-a
export GH_CONFIG_DIR=~/profile-a
gh auth login -c
# Complete the flow

# From now on, gh will only know and use the newly authenticated user.

You can repeat the same process to add more profiles/configurations, and override GH_CONFIG_DIR to the target account profile/configuration directory. Note that the accounts are isolated, and if you ever need to use the same account via multiple profiles/configurations, you should login on each of them separately.

Can you please check this and tell me if it works for you?

@babakks

Thanks @babakks, this worked for me.

I still would consider leaving this opened as an improvement (not a feature request anymore).

By the way, if your both accounts are on the same GitHub host (e.g. github.com), you may want to try this simpler approach:

export GH_TOKEN=$(gh auth token --user USER1 --hostname github.com)
# from now on `gh` acts on behalf of USER1

export GH_TOKEN=$(gh auth token --user USER2 --hostname github.com)
# from now on `gh` acts on behalf of USER2

@babakks

This worked for me as well. Personally, I prefer this approach over creating multiple config paths, it’s more straightforward and doesn’t require any extra setup on the user side. This solution meets all my expectations. Thanks, @babakks!

Yeah, this is definitely simpler. The other approach works best if you're working with multiple GitHub hosts (e.g. in #11935).

@gringolito

Our corporate network blocks SSH, so I've had to resort to HTTPS for git remotes. This created the same multi-account issue as @gringolito, and I began using the proposed solution from @babakks. I've since been able to streamline it further using conditional git configs:

~/.gitconfig

[credential "https://github.com"]
	helper = !gh auth git-credential
[includeIf "gitdir:/projects/@client-one/"]
	path = /projects/@client-one/.gitconfig
[includeIf "gitdir:/projects/@client-two/"]
	path = /projects/@client-two/.gitconfig

/projects/@client-one/.gitconfig

[user]
	email = [email protected]
[credential "https://github.com"]
	helper =
	helper = !GH_TOKEN=$(gh auth token --user simen-client-one) gh auth git-credential

Hope this helps others!

I came at this problem from a different direction, looking to make it automatic to use my non-personal account for any repo in the non-personal org, and my personal account for everything else. I implemented it in a PR, that was of course automatically closed, but wanted to add it here as a reference as well.
I set it up so that you can add a mapping of owner -> user, and then any repo with a configured owner will use the mapped user via the factory created http client. If there is not an owner->user match, it will use the globally active one. This allows me to leave it as my personal account in general, but ensures that when I need to interact with a non-personal repo, I'm using the correct credential.

The solutions suggested here are good solutions if the repos are segregated by directory easily. That wasn't the case for me, so the owner path seemed the most straightforward.

PR: #13130
Root Cause Analysis: #12885

Similar Issues:
#326
#9111
#11938

A complementary approach worth considering: a --user flag on individual gh subcommands (e.g. gh pr create --user jimisola).

GH_USER solves the per-session case well, but a per-command flag would be useful when running commands programmatically (e.g. in scripts or AI coding agents like Claude Code) where shell state doesn't persist between invocations. In those contexts, exporting an env var each time adds ceremony, whereas --user would be self-contained and explicit at the call site.

Both could coexist: GH_USER for interactive sessions, --user for scripted/agentic use.

+1 for the --user flag that, that would be a huge help for agentic coding

install-tend: isolate bot auth in per-bot GH_CONFIG_DIR (#688)

@jimisola

For anyone hitting this now, two workarounds that work on a single host:

GH_CONFIG_DIR=~/profile-a gh auth login once per profile, then export GH_CONFIG_DIR in the shell. Full isolation across commands.
export GH_TOKEN=$(gh auth token --user USER). No setup, but spawns a gh per call.

The underlying bug is #12885: the keychain lookup keys on service only (gh:github.com), so with several accounts on a host it returns an arbitrary token. It's marked stale, but it's a correctness issue.

What neither workaround covers is per-call account selection with no shell state, which is what agent harnesses need when firing many gh commands. #13984 explores that with a GH_USER env var scoped to token resolution; a --user flag (per @jimisola) would fit scripted callers.

@deemwario

@deemwario great summary and I agree with everything you wrote, especially throwing an error if the selected account is not logged in

docs: shape the gh-config-dir-profiles change

Add sks-sudo for gh identity switching

Add sks-sudo for gh identity switching (#327)

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

Set GHX_PROFILE=<profile or login> in a shell, or put a .ghx file with a gh login in the repo, or map folders in ~/.config/ghx/config.yaml. ghx runs the real gh with GH_TOKEN from gh auth token --user <login>. It never calls gh auth switch, so other terminals keep their account. All gh commands, flags and extensions pass through unchanged.

Navigation Menu

Repository navigation

Select authenticated user via `GH_USER` env var #12145

Describe the feature or problem you’d like to solve

Proposed solution

Additional context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Select authenticated user via GH_USER env var #12145

Description

Describe the feature or problem you’d like to solve

Proposed solution

Additional context

Activity

github-actions commented on Nov 13, 2025

babakks commented on Nov 14, 2025

gringolito commented on Nov 14, 2025

babakks commented on Nov 17, 2025

gringolito commented on Nov 17, 2025

babakks commented on Nov 17, 2025

simenbrekken commented on Mar 30, 2026

galamdring commented on Apr 10, 2026

jimisola commented on May 6, 2026

mjanos10 commented on Jun 9, 2026

1fanwang commented on Jul 28, 2026

mjanos10 commented on Aug 17, 2026

barnuri commented on Oct 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Select authenticated user via `GH_USER` env var #12145