Using GH_CONFIG_DIR for different authentications doesn't work as expected

[aaron-baff-ad-net]

Discussion Type

Bug

Discussion Content

So I have separate work & personal Github credentials, as I'm sure many do. So I've been trying to automatically switch between credentials without needing to remember to do gh switch or anything like that. So I've come up with a guide to do that using the GH_CONFIG_DIR environment parameter.

It looks like it works fine, using gh auth status it's showing the correct account authentication, but when I try and do a git push, it shows the other account authentication that I last did with gh auth login.

I can't help but think this is a bug, since the environment GH_CONFIG_DIR is correct, and gh auth status is showing me exactly what I expect.

Here's the guide that I came up with. Unless my understanding of how GH_CONFIG_DIR is supposed to function is faulty.

https://gist.github.com/Drizzt321/47cf383a19535940a26616d982783d2e

[aaron-baff-ad-net]

sigh and this is exactly my annoyance with having multiple logins/identities, created under the wrong login since my current browser session is using the other login and forgot to switch before hitting create.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[itxashancode]

I ran into this exact issue. The problem is that gh auth status reads your config directory directly, but git push relies on Git credential helper chain. If Git is configured to use a system credential manager, it will bypass gh entirely and ignore GH_CONFIG_DIR.

Run git config --get credential.helper in the repo. If you see osxkeychain, manager-core, or cache, you need to point Git directly at the CLI. Run git config --local credential.helper "!gh auth git-credential". Make sure GH_CONFIG_DIR is exported in the exact shell session where you run git push.

I am not 100% sure if your gist covers this, but terminal multiplexers and IDEs sometimes strip environment variables before spawning git processes. What does git config --get credential.helper return in the repo you are pushing from?

[Drizzt321]

So depends somewhat on the specific tool. I've updated the gist, what you see in there now works for me, at least. One thing to note is that I extended it to using a Claude Code startup hook, which I put in direnv wiki at https://github.com/direnv/direnv/wiki/Claude-Code, which is one of my big uses for this as well. So personal vs work code dev works correctly with direnv.

[itxashancode]

Nice, that's a clean setup. Using a startup hook to handle it is smarter than relying on shell env alone, good call adding that to the direnv wiki. I'll take a look at the gist update.

[Gecko51]

The root cause here is that GH_CONFIG_DIR only controls where the gh CLI reads its config and token from. Git itself doesn't know about it. When you git push, Git goes through its own credential helper chain, which is completely separate from the gh config directory.

So the fix is two parts:

1. Set GH_CONFIG_DIR to point to the right config directory (you already had this)
2. Make sure Git uses gh as the credential helper, so it actually reads from that config:

git config --local credential.helper "!gh auth git-credential"

The --local flag is key here. If you set it globally, all repos use the same credential helper, but the GH_CONFIG_DIR env var controls which identity gh resolves to. Combine this with direnv to auto-set GH_CONFIG_DIR per directory and you get seamless switching.

One gotcha: if you have credential.helper set at multiple levels (system, global, local), Git evaluates them in order and the first one that returns credentials wins. So make sure there's no system-level osxkeychain or manager-core entry that intercepts before gh gets a chance to run. You can check with:

git config --show-origin --get-all credential.helper

That'll show you every credential helper that's configured and where it comes from.