gh pr checkout fails when GH_HOST points at a local proxy host while git remotes use the real GitHub host

[j-srodka]

Analysis

In workflows that use a proxied / integrity-filtered (e.g. DIFC-style) pre-agent setup, environment variables for the GitHub CLI are often rewritten so GH_HOST (and sometimes related GITHUB_*_URL values) target a local proxy host, while the checked-out repository’s origin remote remains the canonical GitHub.com / GHES HTTPS host (as set by typical actions/checkout + tokenized remotes).

The generated PR checkout path then runs gh pr checkout <pr-number> with GH_HOST still pointing at the proxy. The GitHub CLI validates remotes against GH_HOST and exits with:

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

So the job fails before normal agent execution, even when the repository, PR, and token are valid. The failure is environment normalization / step isolation, not token scope. It is also easy to misdiagnose as permissions, fork handling, or invalid PR metadata.

Summary

This issue asks that generated gh-aw workflows (and/or shared setup actions) normalize or scope environment for PR checkout so gh pr checkout sees GH_HOST / API URLs consistent with git remotes, or use a git-native checkout for same-repo heads where appropriate—without downstream consumers hand-editing compiled lockfiles after every compile.

Observed failure shape

Typical gh error:

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

Logs may show GH_HOST set to a localhost / loopback hostname (or another non-canonical host) while git remote -v still shows the real GitHub instance host.

What appears to be happening

1. Early steps start a proxy (or similar) and adjust GH_HOST / related GITHUB_*_URL so gh traffic goes through the proxy.
2. PR checkout runs gh pr checkout while GH_HOST still reflects the proxy, but git remotes still reference the real GitHub server hostname.
3. gh refuses to proceed because no remote matches GH_HOST.

Minimal repro (shape)

Conditions

• Workflow uses a proxy / DIFC-style pre-agent gh setup that sets GH_HOST to a local proxy host.
• The workspace git remote still targets the normal GitHub.com or GHES host.
• The generated checkout step uses gh pr checkout (by PR number).

Result

• gh pr checkout exits non-zero with the message above; dependent steps do not run.

A minimal public repro could be a small workflow that sets GH_HOST to a synthetic localhost value before gh pr checkout, without relying on proprietary proxy details.

Why this matters

• PR-triggered agent workflows can fail very early despite valid PRs and working auth.
• Operators and automation often assume 403 / permissions or fork issues first; the fix is checkout-scoped env or checkout strategy.
• Consumers should not rely on permanent post-compile patches to injected YAML for this class of failure.

Suggested implementation plan (for maintainers / implementing agent)

1. Smallest / targeted (compiler or shared action)
   Immediately before the generated PR checkout step, emit step-level env (or equivalent) so that step uses real instance values, for example:

   • Derive GH_HOST from GITHUB_SERVER_URL (strip scheme).
   • Set GITHUB_API_URL and GITHUB_GRAPHQL_URL to the non-proxied endpoints that match that instance for the checkout step only.
     Then run gh pr checkout under that env. Do not rely on job-wide GITHUB_ENV alone if later steps still need proxy settings—prefer scoping to the checkout step.

2. Better isolation
   Ensure proxy-specific GH_HOST / API overrides do not leak into steps that must align with normal git remotes (explicit step env, or explicit unset/override for checkout only).

3. Stronger long-term
   For same-repository PR heads, prefer deterministic git fetch / git checkout of the head ref when safe, and reserve gh pr checkout for cross-repo / fork cases where it is required.

4. Tests / validation
   Add a regression test or workflow fixture that simulates GH_HOST mismatch (e.g. localhost) before checkout and asserts the generated workflow or helper normalizes env or chooses a git-native path.

5. Observability (optional but helpful)
   When webhook PR metadata is partial, concise logging of same-repo vs cross-repo checkout decisions (from API-resolved metadata) helps distinguish fork/cross-repo needs, metadata ambiguity, and proxy / GH_HOST mismatch.

Additional note (observability)

When webhook PR metadata is thin (e.g. missing head repo), checkout strategy may differ. Logging same-repo vs cross-repo decisions would help separate:

• true fork / cross-repo checkout needs
• metadata ambiguity
• proxy / GH_HOST mismatch (this issue)

Expected outcome

Generated gh-aw workflows check out PR branches reliably in proxied / DIFC-style environments without requiring consumers to hand-patch compiled lockfiles after every compile.

---

Thanks for considering this — happy to help validate a fix against our setup if useful (in generic terms, without sharing private repository details).

[dsyme]

@j-srodka I also hit this problem. It seems there is a (partial?) fix for this in main, so I've published a new release v0.64.3 and it has resovled my version of the problem.

Could you check if this fix addresses your problem please? If not we will wait for @lpcox and @pelikhan to take a look today or tomorrow.

Thank you

[j-srodka]

Will do @dsyme Thank you.

[lpcox]

🔗 AWF tracking issue: github/gh-aw-firewall#1492

A fix is already in progress via github/gh-aw-firewall#1493 — it ensures GH_HOST is always derived from GITHUB_SERVER_URL (the canonical runner-injected value) and removes any proxy-rewritten value passed through --env-all.

Generated by Firewall Issue Dispatcher · ◷