Summary

Fixes #12179 - Allows gh pr checkout and related commands to work when git remote hostname differs from GitHub API hostname.

Problem

Commands like gh pr checkout, gh pr create, and gh repo fork fail in enterprise environments where:

• Git operations route through git.company.com (proxy/bastion)
• API operations target github.company.com (GitHub Enterprise)

Error encountered:

none of the git remotes configured for this repository correspond to the
GH_HOST environment variable

This affects legitimate enterprise configurations using git proxies, SSH bastions, or git mirrors.

Root Cause

The remote resolver in pkg/cmd/factory/remote_resolver.go returns an error when no git remotes match authenticated hosts, even though:

• Git operations only need owner/repo matching (not hostname)
• Git commands use remote name (origin), not the URL
• API operations validate hostname separately via GH_HOST

The git remote hostname and API hostname are separate concerns.

Solution

Changed the remote resolver to fall back to all remotes when no remotes match authenticated hosts, rather than failing with an error.

Before:

if len(rr.cachedRemotes) == 0 {
    if isHostEnv(src) {
        rr.remotesError = fmt.Errorf("none of the git remotes configured...")
        return nil, rr.remotesError
    }
    // ... more error paths
}

After:

if len(rr.cachedRemotes) == 0 {
    // Fall back to all remotes for commands that only need owner/repo matching.
    // Commands performing API operations will still fail with clear errors when
    // the API host is wrong. This allows git operations through proxies/bastions
    // where the git remote host differs from the GitHub API host.
    rr.cachedRemotes = resolvedRemotes
}

Changes Made

• Modified pkg/cmd/factory/remote_resolver.go:
  • Replaced error returns with fallback to all remotes (6 lines)
  • Removed unused fmt import

Testing

Test scenario:

# Git remote through proxy
$ git remote -v
origin  git@git.company.com:corp/repo.git

# Authenticated to GitHub Enterprise
$ gh auth login --hostname github.company.com
$ export GH_HOST=github.company.com

# This now works:
$ gh pr checkout 123
✓ Checks out PR successfully

Verified:

• ✅ gh pr checkout works with mismatched hostnames
• ✅ gh pr view, gh pr list still work (API operations)
• ✅ Commands fail appropriately when API host is genuinely wrong
• ✅ Backwards compatible with standard configurations

Real-world testing:

• Tested in Netflix enterprise environment (git.netflix.net / github.netflix.net)
• Successfully checked out PR [WIP] #2353 emoji parser #2407 in production repository
• Wrapper script complexity reduced from ~220 lines to ~10 lines

Impact

Benefits:

• ✅ Fixes legitimate enterprise git proxy configurations
• ✅ Generic solution (not company-specific)
• ✅ Minimal code change (6 lines)
• ✅ No security impact (API auth still validated)
• ✅ Backwards compatible
• ✅ Clearer separation of concerns

Who this helps:

• Enterprises using git proxies for security/auditing
• Organizations with SSH bastions/jump hosts
• Teams using git mirrors for performance
• Any environment where git and API use different hostnames

Security Considerations

• API host validation is unchanged - still enforced via GH_HOST and auth config
• Authentication still required for all API operations
• Only affects which remotes are considered for git operations
• Git operations already require appropriate git credentials

Alternative Considered

Created a separate GitRemotes() factory method for git-only operations, but the fallback approach is simpler and achieves the same goal with less code.