Repository navigation
Select authenticated user via GH_USER env var #12145
Description
Activity
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.
Thanks for sharing your feedback, @gringolito! 🍻
I see your point, and
ghdoes have a similar offering, although it might not be very visible. You can override theGH_CONFIG_DIRenv var to makeghswitch 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
ghto store the configuration, assign andexporttheGH_CONFIG_DIRenv var, login once with your account, and continue usingghin 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_DIRto 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?
Thanks @babakks, this worked for me.
I still would consider leaving this opened as an improvement (not a feature request anymore).
Reacted by Babak K. Shandiz- changed the title
[-]Select authenticated user via GH_USER env var[/-][+]Select authenticated user via `GH_USER` env var[/+]on Nov 15, 2025 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
Reacted by Filipe Utzig and Kynan WareThis 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!
Reacted by Babak K. ShandizOur 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!
- marked Feature: per-command user selection (--user flag) #13088 as a duplicate of this issue
on Apr 6, 2026 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.
A complementary approach worth considering: a
--userflag on individualghsubcommands (e.g.gh pr create --user jimisola).GH_USERsolves 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--userwould be self-contained and explicit at the call site.Both could coexist:
GH_USERfor interactive sessions,--userfor scripted/agentic use.Reacted by Mayer János and Stefan Wang+1 for the
--userflag that, that would be a huge help for agentic coding- added a commit that references this issue
on Jun 12, 2026 For anyone hitting this now, two workarounds that work on a single host:
GH_CONFIG_DIR=~/profile-a gh auth loginonce per profile, then exportGH_CONFIG_DIRin the shell. Full isolation across commands.export GH_TOKEN=$(gh auth token --user USER). No setup, but spawns aghper 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 markedstale, 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
ghcommands. #13984 explores that with aGH_USERenv var scoped to token resolution; a--userflag (per @jimisola) would fit scripted callers.Reacted by Ilia Kondrashov@deemwario great summary and I agree with everything you wrote, especially throwing an error if the selected account is not logged in
- added a commit that references this issue
on Sep 6, 2026
Describe the feature or problem you’d like to solve
I manage multiple GitHub accounts across several projects and must manually run
gh auth switchto 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