could not resolve remote "origin": none of the git remotes configured for this repository correspond to the `GH_HOST` environment variable.

[scr-oath]

Describe the bug

When using GH_HOST, GH_REPO, and GH_ENTERPRISE_TOKEN in conjunction with gh pr create, it started failing about a week ago for us, and we can't reproduce as a human (even with a token) or determine any glaring differences between the CI/CD and local invocations of the same tool, nor even with any version bumps since the last working version (even if we downgrade to 2.70.0, it still fails now 2.70.0 still works actually).

could not resolve remote "origin": 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

Some of the settings/troubleshooting attempts

GH_HOST=our.enterprise.host
GH_REPO=out.enterprise.host/ourorg/ourrepo
GH_ENTERPRISE_TOKEN=<set to something>
GH_DEBUG=true

00:00:45 + git remote -v
00:00:45 origin	git@our.enterprise.host:ourorg/ourrepo (fetch)
00:00:45 origin	git@our.enterprise.host:ourorg/ourrepo (push)
00:00:45 + git version
00:00:45 git version 2.43.5
00:00:45 + gh version
00:00:45 gh version 2.71.2 (2025-04-24)
00:00:45 + git config --get-regexp '^branch\.autoupdate/20250428-183455\.(remote|merge|pushremote|gh-merge-base)$'
00:00:45 branch.autoupdate/20250428-183455.remote origin
00:00:45 branch.autoupdate/20250428-183455.merge refs/heads/autoupdate/20250428-183455
00:00:45 + git rev-parse --symbolic-full-name 'autoupdate/20250428-183455@{push}'
00:00:45 refs/remotes/origin/autoupdate/20250428-183455

and invocation

00:00:45 + gh pr create --label autoupdate-server_admap --title '[autoupdate][20250428-183455] Update files from source folder' --body 'This PR is a result of script, which auto update files from the source directory.'
00:00:45 [git remote -v]
00:00:45 [git config --get-regexp ^remote\..*\.gh-resolved$]
00:00:45 * Request at 2025-04-28 18:34:59.675488605 +0000 UTC m=+0.085715954
00:00:45 * Request to https://our.enterprise.host/api/graphql
00:00:46 * Request took 245.740739ms
00:00:46 [git status --porcelain]
00:00:46 [git symbolic-ref --quiet HEAD]
00:00:46 [git config --get-regexp ^branch\.autoupdate/20250428-183455\.(remote|merge|pushremote|gh-merge-base)$]
00:00:46 [git rev-parse --symbolic-full-name autoupdate/20250428-183455@{push}]
00:00:46 could not resolve remote "origin": 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

Affected version

Please run gh version and paste the output below.

gh version 2.71.2 (2025-04-24)

Steps to reproduce the behavior

1. Have an enterprise server
2. Set the GH_HOST, GH_REPO, GH_ENTERPRISE_TOKEN appropriately
3. Have an origin with ssh-formatted location (not quite URL but git@ style)

Expected vs actual behavior

A PR should be created (and was up until a week ago); the error regarding inability to find the origin is output and a failure rc is returned.

Logs

See invocation above

[williammartin]

Hmmm sorry for the inconvenience. If possible can you provide the debug logs with 2.70.0 as well? Would just like to double check something.

[scr-oath]

Actually… I think we didn't actually try with 2.70.0 - there were two cases where the downgrade was done and the place we were eyeballing didn't have the downgrade… we're trying it again now… if that fixes things, I'll let you know!

[scr-oath]

v2.70.0 actually DOES work afterall, still.

00:01:02 + gh pr create --label autoupdate-deals --title '[autoupdate][deals][20250428-232318] Update files from source folder' --body 'This PR is a result of script, which auto update files from the source directory.'
00:01:02 [git remote -v]
00:01:02 [git config --get-regexp ^remote\..*\.gh-resolved$]
00:01:02 * Request at 2025-04-28 23:23:22.060837195 +0000 UTC m=+0.072287632
00:01:02 * Request to https://our.enterprise.host/api/graphql
00:01:02 * Request took 227.920413ms
00:01:02 [git symbolic-ref --quiet HEAD]
00:01:02 [git status --porcelain]
00:01:02 [git config --get-regexp ^branch\.autoupdate/20250428-232318\.(remote|merge|pushremote|gh-merge-base)$]
00:01:02 [git show-ref --verify -- HEAD refs/remotes/origin/autoupdate/20250428-232318]
00:01:02 * Request at 2025-04-28 23:23:22.314543122 +0000 UTC m=+0.325993562
00:01:02 * Request to https://our.enterprise.host/api/graphql
00:01:02 * Request took 148.505962ms
00:01:02 * Request at 2025-04-28 23:23:22.46389135 +0000 UTC m=+0.475341806
00:01:02 * Request to https://our.enterprise.host/api/graphql
00:01:03 * Request took 126.888572ms
00:01:03 * Request at 2025-04-28 23:23:22.59096085 +0000 UTC m=+0.602411290
00:01:03 * Request to https://our.enterprise.host/api/graphql
00:01:03 * Request took 558.349206ms
00:01:03 * Request at 2025-04-28 23:23:23.149547271 +0000 UTC m=+1.160997715
00:01:03 * Request to https://our.enterprise.host/api/graphql
00:01:04 * Request took 473.630369ms
00:01:04 https://our.enterprise.host/ourorg/ourrepo/pull/1329

[williammartin]

Makes sense that the problem would be introduced in 2.71.0 with all the changes we made around respecting git config on pr create. Thanks for the extra information!

[williammartin]

So, the only explanation I have for this right now is that we were previously suppressing an error:

cli/pkg/cmd/pr/create/create.go

Line 966 in e138782

if opts.RepoOverride == "" {

And the same codepath that was called here is now called later with the error unsuppressed:

cli/pkg/cmd/pr/shared/find_refs_resolution.go

Line 260 in e138782

return nil, fmt.Errorf("could not resolve remote %q: %w", v.name, err)

However, I cannot reproduce your error with a valid setup:

➜  test git:(feature) gh version
gh version 2.71.2 (2025-04-24)
https://github.com/cli/cli/releases/tag/v2.71.2

➜  test git:(feature) echo $GH_HOST
ghe.io
➜  test git:(feature) echo $GH_REPO
ghe.io/williammartin/test
➜  test git:(feature) echo $GH_ENTERPRISE_TOKEN
gho_****************************

➜  test git:(feature) git remote -v
origin  git@ghe.io:williammartin/test.git (fetch)
origin  git@ghe.io:williammartin/test.git (push)

➜  test git:(feature) GH_DEBUG=1 gh pr create --title test --body test
[git remote -v]
[git config --get-regexp ^remote\..*\.gh-resolved$]
* Request at 2025-04-29 10:31:45.050698 +0200 CEST m=+0.126742585
* Request to https://ghe.io/api/graphql
* Request took 599.400333ms
[git status --porcelain]
[git symbolic-ref --quiet HEAD]
[git config --get-regexp ^branch\.feature\.(remote|merge|pushremote|gh-merge-base)$]
[git rev-parse --symbolic-full-name feature@{push}]
[git show-ref --verify -- HEAD refs/remotes/origin/feature]
⣾* Request at 2025-04-29 10:31:45.705733 +0200 CEST m=+0.781773793
* Request to https://ghe.io/api/graphql
⢿* Request took 413.290583ms

Creating pull request for feature into main in williammartin/test

⣾* Request at 2025-04-29 10:31:46.125649 +0200 CEST m=+1.201688543
* Request to https://ghe.io/api/graphql
⣯* Request took 751.386625ms
https://ghe.io/williammartin/test/pull/11

The only way I can reproduce it is if I misconfigure GH_HOST:

➜  test git:(feature) echo $GH_HOST
ghe.ios

Then v2.71.0 fails where v2.70.0 passes:

➜  test git:(feature) GH_DEBUG=1 gh pr create --title test --body test
[git remote -v]
[git config --get-regexp ^remote\..*\.gh-resolved$]
* Request at 2025-04-29 10:18:06.631162 +0200 CEST m=+0.139859959
* Request to https://ghe.io/api/graphql
* Request took 487.029459ms
[git status --porcelain]
[git symbolic-ref --quiet HEAD]
[git config --get-regexp ^branch\.feature\.(remote|merge|pushremote|gh-merge-base)$]
[git rev-parse --symbolic-full-name feature@{push}]
could not resolve remote "origin": 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

➜  test git:(feature) GH_DEBUG=1 ~/workspace/cli/bin/gh pr create --title test --body test
[git remote -v]
[git config --get-regexp ^remote\..*\.gh-resolved$]
* Request at 2025-04-29 10:18:22.991411 +0200 CEST m=+0.097882043
* Request to https://ghe.io/api/graphql
* Request took 437.762208ms
[git symbolic-ref --quiet HEAD]
[git status --porcelain]
[git config --get-regexp ^branch\.feature\.(remote|merge|pushremote|gh-merge-base)$]                       [git show-ref --verify -- HEAD refs/remotes/origin/feature]
* Request at 2025-04-29 10:18:23.48337 +0200 CEST m=+0.589838793
* Request to https://ghe.io/api/graphql                                                                    ⣻* Request took 305.86ms

Creating pull request for feature into main in williammartin/test
⣾* Request at 2025-04-29 10:18:23.793544 +0200 CEST m=+0.900011668
* Request to https://ghe.io/api/graphql
⡿* Request took 607.150375ms
https://ghe.io/williammartin/test/pull/8

Or, if I misconfigure the git remote:

➜  test git:(feature) echo $GH_HOST
ghe.io

➜  test git:(feature) git remote -v
origin  git@NONSENSE.io:williammartin/test.git (fetch)
origin  git@NONSENSE.io:williammartin/test.git (push)

➜  test git:(feature) GH_DEBUG=1 gh pr create --title test --body test
[git remote -v]
[git config --get-regexp ^remote\..*\.gh-resolved$]
* Request at 2025-04-29 10:23:47.706454 +0200 CEST m=+0.072512876
* Request to https://ghe.io/api/graphql
* Request took 379.052667ms
[git status --porcelain]
[git symbolic-ref --quiet HEAD]
[git config --get-regexp ^branch\.feature\.(remote|merge|pushremote|gh-merge-base)$]
[git rev-parse --symbolic-full-name feature@{push}]
could not resolve remote "origin": 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

➜  test git:(feature) GH_DEBUG=1 ~/workspace/cli/bin/gh pr create --title test --body test
[git remote -v]
[git config --get-regexp ^remote\..*\.gh-resolved$]
* Request at 2025-04-29 10:23:57.933781 +0200 CEST m=+0.072119417
* Request to https://ghe.io/api/graphql
* Request took 343.252959ms
[git symbolic-ref --quiet HEAD]
[git status --porcelain]
[git config --get-regexp ^branch\.feature\.(remote|merge|pushremote|gh-merge-base)$]
[git show-ref --verify -- HEAD refs/remotes/origin/feature]
⣾* Request at 2025-04-29 10:23:58.328791 +0200 CEST m=+0.467128001
* Request to https://ghe.io/api/graphql
⣻* Request took 295.429ms

Creating pull request for feature into main in williammartin/test

⣾* Request at 2025-04-29 10:23:58.629306 +0200 CEST m=+0.767641459
* Request to https://ghe.io/api/graphql
⡿* Request took 534.9275ms
https://ghe.io/williammartin/test/pull/10

This is strange behaviour but works because the value of GH_REPO is used to determine the host to target for API requests, and because the branch is already pushed, there's no need to use the git remote.

➜  test git:(feature) unset GH_REPO

➜  test git:(feature) GH_DEBUG=1 ~/workspace/cli/bin/gh pr create --title test --body test
[git remote -v]
[git config --get-regexp ^remote\..*\.gh-resolved$]
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

---

It's highly likely that I'm missing something here, but can you please double check GH_REPO, GH_HOST and git remote -v configuration. If you don't think you can share these publicly but are willing to share with me you can email me at my handle @github.com.

[scr-oath]

hi - sent an email with fuller logs… if you have any public slack/irc/other connectivity to chat please LMK if you have patience to troubleshoot closer to "live"

[williammartin]

Investigation Summary

The error:

could not resolve remote "origin": 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

Comes from our code that "resolves remotes" which is a process of:

• Collecting git remotes in the current working directory
• Collecting known hosts (e.g. those in hosts.yml or GH_HOST env var, or github.com)
• Using the remote URL to construct a repo struct with a host that has undergone SSH translation (more on this below)
• Filtering the git remotes to retain only those with a repo host that match a subset of known hosts

In the case of a user providing the GH_HOST env var, we expect to only retain the git remotes for those with a repo host that matches exactly the value of `GH_HOST.

SSH Translation

SSH Translation is the process of taking a git remote that is an SSH URL (e.g. git@github.com:cli/cli) and asking ssh whether the host (github.com) is being mapped to some other hostname. This mapping usually lives in ~/.ssh/config and looks like:

Host host1
    HostName host1.example.com

It's important that gh does this translation in order to send API requests to the real host, for example, when creating a pull request.

Problem

If a user does not have a host in the hosts.yml, the only way they can indicate the presence of a known host to gh is via the GH_HOST environment variable. This GH_HOST environment variable is used by commands that don't have a base repo to provide the host (e.g. gh repo list) to determine the API endpoint. Without this environment variable set, remotes for an expected host will be filtered out as per the bullet list above and also as per the bulleted list above, it is expected that the value of GH_HOST exactly matches the repo's hostname, after SSH translation.

So given I want to create a PR in my enterprise server that doesn't exist in hosts.yml, a user must pass GH_HOST

GH_HOST=myghes.com gh pr create --title title --body body

However if my enterprise setup also has a hostname mapping to force ssh requests to go through a proxy:

Host myghes.com
    HostName ssh-proxy.myghes.com

Then after SSH translation myghes.com will not match ssh-proxy.myghes.com and no remotes will be retained.

Evidence

In trunk...wm/debug-gh-host-ssh-translate, you will find a commit with acceptance test that demonstrates this behaviour (requires some manual patching of go-gh to avoid writing to a real SSH config), and a commit with a series of debug logs sprinkled throughout.

Here is the output of the debug logs for this test:

 > exec gh pr create --title 'Feature Title' --body 'Feature Body'
        [stdout]
        *** Starting Resolver
                Git Remotes (1)
                        Name:  origin
                        FetchURL:  ssh://git@github.com/gh-acceptance-testing/pr_create_ssh_hostname_rewrite_and_gh_host-rhnQEabRYw.git
                        PushURL:  ssh://git@github.com/gh-acceptance-testing/pr_create_ssh_hostname_rewrite_and_gh_host-rhnQEabRYw.git
        *** Starting TranslateRemotes
                Translating:  origin
                        Fetch URL: ssh://git@github.com/gh-acceptance-testing/pr_create_ssh_hostname_rewrite_and_gh_host-rhnQEabRYw.git
                        Translated Fetch URL: ssh://git@example.com/gh-acceptance-testing/pr_create_ssh_hostname_rewrite_and_gh_host-rhnQEabRYw.git
        *** Ending TranslateRemotes
                Resolved Remotes (1)
                        Name:  origin
                        FetchURL:  ssh://git@github.com/gh-acceptance-testing/pr_create_ssh_hostname_rewrite_and_gh_host-rhnQEabRYw.git
                        PushURL:  ssh://git@github.com/gh-acceptance-testing/pr_create_ssh_hostname_rewrite_and_gh_host-rhnQEabRYw.git
                        Repo: &ghrepo.ghRepo{owner:"gh-acceptance-testing", name:"pr_create_ssh_hostname_rewrite_and_gh_host-rhnQEabRYw", hostname:"example.com"}
        *** Starting FilterByHosts
                Hosts: (1)
                        Host: github.com
                Remotes: (1)
                        Name: origin
                        FetchURL: ssh://git@github.com/gh-acceptance-testing/pr_create_ssh_hostname_rewrite_and_gh_host-rhnQEabRYw.git
                        PushURL: ssh://git@github.com/gh-acceptance-testing/pr_create_ssh_hostname_rewrite_and_gh_host-rhnQEabRYw.git
                        Repo: &ghrepo.ghRepo{owner:"gh-acceptance-testing", name:"pr_create_ssh_hostname_rewrite_and_gh_host-rhnQEabRYw", hostname:"example.com"}
                        Comparing example.com to github.com
                        No match example.com to github.com
                Retained Remotes: (0)
        *** Ending FilterByHosts
                Filtering by default host:  github.com
        *** Starting FilterByHosts
                Hosts: (1)
                        Host: github.com
                Remotes: (0)
                Retained Remotes: (0)
        *** Ending FilterByHosts
        *** Ending Resolver
        *** Starting Resolver
        *** Ending Resolver

We can see the translation of our FetchURL

      *** Starting TranslateRemotes
              Translating:  origin
                      Fetch URL: ssh://git@github.com/gh-acceptance-testing/pr_create_ssh_hostname_rewrite_and_gh_host-rhnQEabRYw.git
                      Translated Fetch URL: ssh://git@example.com/gh-acceptance-testing/pr_create_ssh_hostname_rewrite_and_gh_host-rhnQEabRYw.git
      *** Ending TranslateRemotes

And that the later comparison uses the translated URL:

Comparing example.com to github.com
No match example.com to github.com

Why didn't this fail before?

Alluded to in #10891 (comment), before v2.71.0 we were suppressing this error in the only place that remotes were resolved during pr create

cli/pkg/cmd/pr/create/create.go

Lines 960 to 971 in e138782

	func getRemotes(opts *CreateOptions) (ghContext.Remotes, error) {
	// TODO: consider obtaining remotes from GitClient instead
	remotes, err := opts.Remotes()
	if err != nil {
	// When a repo override value is given, ignore errors when fetching git remotes
	// to support using this command outside of git repos.
	if opts.RepoOverride == "" {
	return nil, err
	}
	}
	return remotes, nil
	}

However, with the changes in v2.71.0, we started calling this function in another location and are not suppressing the error:

cli/pkg/cmd/pr/shared/find_refs_resolution.go

Lines 255 to 262 in e138782

	func (r remoteToRepoResolver) resolve(remote remote) (ghrepo.Interface, error) {
	switch v := remote.(type) {
	case remoteName:
	repo, err := r.remoteNameToRepo(v.name)
	if err != nil {
	return nil, fmt.Errorf("could not resolve remote %q: %w", v.name, err)
	}
	return repo, nil

This may indicate another bug that I need to look into with regards the comment:

		// When a repo override value is given, ignore errors when fetching git remotes
		// to support using this command outside of git repos.

But that is outside the scope of this investigation.

What do we do next?

Todo, since it's a vacation day here but I wanted to write this up for the team to look at.

[andyfeller]

If I understand everything above, it seems like the problem is that resolving remotes does not consider the SSH aliasing case below:

cli/pkg/cmd/factory/remote_resolver.go

Lines 72 to 80 in d6d8275

	// Filter again by default host if one is set
	// For config file default host fallback to cachedRemotes if none match
	// For environment default host (GH_HOST) do not fallback to cachedRemotes if none match
	if src != "default" {
	filteredRemotes := rr.cachedRemotes.FilterByHosts([]string{defaultHost})
	if isHostEnv(src) || len(filteredRemotes) > 0 {
	rr.cachedRemotes = filteredRemotes
	}
	}

Should this line also include the translated version of the hosts when trying to resolve the remotes? If so, does the ordering matter? Should a translated host have higher precedence?

[scr-oath]

Well the latest debugging with @williammartin has shown that

1. We have a Host directive in the $HOME/.ssh/config
2. If we set GH_HOST to that instead of the name used in the GH_REPO (first path) it seems to work.

I don't like needing to know how my ssh is configured to make the tool work, but would be ok with some flag or env var to disable the ssh inspection if that could be possible in the tool.

[scr-oath]

I suppose, we could learn about, and provide a yaml file if that would fix the behavior- I think we want/need the REST stuff to go to the named host, even if the ssh stuff (push/pull) goes through the x509 proxy.