Repository navigation
gh pr view should use repo’s remote host when GH_HOST points to a different server #11935
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 the feedback, @Shion1305! 🍻
I understand the frustration, but as a rule of thumb env vars are meant to override
ghnormal behaviour. So, setting a globalGH_HOSTenv var is a bad practice unless it's used in an isolated/controlled environment (e.g. CI workflows). Please note thatghis smart about hosts and uses the git remotes to derive the right hostname, of course, unless theGH_HOSToverride is in place.That said, can you please tell me more about your setup/situation so that I can see if there's a way to have an effortless configuration.
Hi @babakks, thanks again for the thoughtful reply! 😊
To explain my setup a bit more — I regularly work across multiple GitHub Enterprise servers and my personal GitHub.com account.
As far as I know, there’s currently no way to define a “default” server withinghitself, so I’ve been setting theGH_HOSTvariable in my.zshrcto one of the Enterprise hosts I use most often.The issue is that this setup quickly becomes inconvenient:
- When I clone a repository from a different Enterprise instance or from GitHub.com, I need to manually switch the
GH_HOSTeach time. - If I open a new terminal session, I have to remember to re-export the correct host for the project I’m working on.
- Many
ghcommands don’t seem to consider the obvious intent when there’s only a single remote configured — they’ll still fail due to a mismatchedGH_HOST.
So my improvement suggestions would be:
- Add an internal way to specify a default host — so that users don’t have to rely solely on environment variables.
- Make
ghsmarter about host detection — for example, if a repository has just one remote,ghcould automatically infer that remote’s host and proceed accordingly.
Even limiting this behavior to public GitHub (github.com) would already be a huge quality-of-life improvement.
Hope that helps clarify my situation! Totally understand the current design philosophy around env vars, but this kind of flexibility could make
gha lot smoother for folks who bounce between multiple hosts every day🙏- When I clone a repository from a different Enterprise instance or from GitHub.com, I need to manually switch the
Thanks, @Shion1305! 🙏 I got your point, but I'm afraid, I'm still not in favour of modifying
gh's behaviour aroundGH_HOST. It's definitely a breaking change, even if in some cases it provides a smoother experience.I think the right approach to your use case is to keep multiple
ghconfigurations, as I have explained in another issue (See #12145 (comment)). You'd still have to manually override an env var to pick the config you need, but it's less frustrating than settingGH_HOSTwith less unexpected results.Can you please try that and let me know if that helps with your case?
Reacted by Shion IchikawaThis issue has been automatically marked as stale because it has not had any activity in the last 30 days,
and it will be closed in 30 days if no further activity occurs.If you think this is a mistake, please comment on this issue to keep it open.
This issue has been automatically closed due to inactivity.
If you think this is a mistake, please comment on this issue.
Describe the feature or problem you’d like to solve
When running
gh pr view(or similar commands) with theGH_HOSTenvironment variable set to a GitHub Enterprise server, the command raises an error, even if the current repository’soriginclearly points to a public GitHub repository ongithub.com.This behavior is inconvenient for users who work with both GitHub Enterprise and public GitHub, as it forces them to unset or reconfigure
GH_HOSTwhenever switching contexts — even when the correct server is already obvious from the repository’s Git configuration.Proposed solution
The CLI could automatically detect the appropriate host based on the repository’s remote URL.
If the
GH_HOSTenvironment variable is set but the current repository’s remote clearly points to a different GitHub host (for example,github.com),ghshould:Prefer the host detected from the repository’s remote, or
At least issue a clear warning and offer to proceed using the detected host.
This improvement would make the CLI more intuitive for users working across public GitHub server and Enterprise server, reducing configuration friction and improve user experience.
Additional context
Example reproduction: