[awf] cli/docker-manager: gh pr checkout fails when GH_HOST inherits proxy value in agent environment

[lpcox]

Problem

When AWF runs in a proxied / DIFC-style environment, GH_HOST may be set on the runner host to point at a local proxy (e.g. localhost:8080 or similar). Because AWF's --env-all path (src/docker-manager.ts) copies unfiltered host environment variables into the agent container, GH_HOST is inherited by the agent.

Inside the agent, any gh pr checkout step (either user-authored or emitted by the gh-aw compiler) then fails with:

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

This is because git remotes still reference the real GitHub hostname while GH_HOST is pointing at the proxy. The workflow fails before the agent begins its primary task.

Context

• Original report: gh pr checkout fails when GH_HOST points at a local proxy host while git remotes use the real GitHub host gh-aw#23461
• A partial fix was released in v0.64.3 but the issue remains open
• The reporter notes the failure is easy to misdiagnose as a permissions or fork issue

Root Cause

Two compounding factors:

1. src/docker-manager.ts — env-all inheritance (generateDockerCompose, env-building logic around line 494–510): GH_HOST is not in EXCLUDED_ENV_VARS, so it flows through --env-all directly into the agent container, carrying whatever proxy-scoped value the host setup left behind.

2. Compiled PR checkout step (generated lock-file YAML / gh-aw compiler): The emitted gh pr checkout step runs with the ambient job-level GH_HOST, with no step-level override to restore the canonical host before checkout.

Proposed Solution

Short-term (AWF firewall env normalization)

In src/docker-manager.ts, add GH_HOST to the list of environment variables that are overridden (not just excluded) from --env-all, and set it to the canonical value derived from GITHUB_SERVER_URL:

// After env-all merging, normalize GH_HOST to canonical GitHub host
if (process.env.GITHUB_SERVER_URL) {
  const canonicalHost = new URL(process.env.GITHUB_SERVER_URL).hostname;
  agentEnv['GH_HOST'] = canonicalHost;
}

This ensures the agent always sees a GH_HOST that matches its git remotes, regardless of what the outer DIFC/proxy setup set.

Medium-term (compiler-level fix)

In the gh-aw workflow compiler, scope GH_HOST (and related GITHUB_API_URL, GITHUB_GRAPHQL_URL) to their canonical values in the emitted gh pr checkout step's env: block, so the fix is baked into compiled lock files independently of the AWF runtime.

Long-term (git-native checkout for same-repo PRs)

For same-repository PR heads, use deterministic git fetch + git checkout of the head ref instead of gh pr checkout. Reserve gh pr checkout for cross-repo / fork cases where it is necessary.

Tests / validation

Add a unit test in src/docker-manager.test.ts (or integration test) that sets GH_HOST=localhost:8080 in the process environment, calls generateDockerCompose, and asserts the resulting agent env contains the canonical GH_HOST (not localhost:8080).

Generated by Firewall Issue Dispatcher · ◷

[github-actions]

👋 Hello! I noticed this issue might be related to existing issues:

• GH_HOST passthrough from proxy environment breaks gh pr checkout inside container #1492 — GH_HOST passthrough from proxy environment breaks gh pr checkout inside container — describes the same root cause: GH_HOST inherited via --env-all from a proxy/DIFC environment causing gh pr checkout to fail inside the agent container, with the same fix location (docker-manager.ts / EXCLUDED_ENV_VARS).
• fix: auto-inject GH_HOST from GITHUB_SERVER_URL when --env-all is used #1452 — fix: auto-inject GH_HOST from GITHUB_SERVER_URL when --env-all is used — appears to be an existing fix attempt for this same GH_HOST/GITHUB_SERVER_URL normalization problem.
• cli: GH_HOST auto-injection covers agent container, but Process Safe Outputs job (outside AWF) needs GH_HOST in GITHUB_ENV on GH [Content truncated due to length] #1460 — GH_HOST auto-injection covers agent container, but Process Safe Outputs job needs GH_HOST in GITHUB_ENV on GHES — a follow-on to the same underlying GH_HOST env-passthrough issue.

If one of these (especially #1492) already addresses your concern, please consider closing this issue as a duplicate. Otherwise, feel free to clarify how your issue differs — particularly around the DIFC proxy scenario or the compiler-level fix aspect!

This is an automated message from the issue duplication detector.

Generated by Issue Duplication Detector for issue #1496