Repository navigation
gh pr view should use repo’s remote host when GH_HOST points to a different server #11935
Description
Describe the feature or problem you’d like to solve
When running gh pr view (or similar commands) with the GH_HOST environment variable set to a GitHub Enterprise server, the command raises an error, even if the current repository’s origin clearly points to a public GitHub repository on github.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_HOST whenever 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_HOST environment variable is set but the current repository’s remote clearly points to a different GitHub host (for example, github.com), gh should:
-
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:
git clone https://github.com/cli/cli.git
export GH_HOST=github.mycompany.com
gh repo view -w
> none of the git remotes configured for this repository correspond to the GH_HOST environment variable. Try adding a matching remote or unsetting the variable
unset GH_HOST
gh repo view -w
> works now
Activity
github-actions commentedon Oct 14, 2025
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 wantedContributions 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.
babakks commentedon Oct 23, 2025
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.
Shion1305 commentedon Oct 23, 2025
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 within
ghitself, 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:
GH_HOSTeach time.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:
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🙏babakks commentedon Nov 17, 2025
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?
github-actions commentedon Dec 18, 2025
This 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.
github-actions commentedon Jan 17, 2026
This issue has been automatically closed due to inactivity.
If you think this is a mistake, please comment on this issue.