Summary
The DIFC proxy setup script (start_difc_proxy.sh in gh-aw) writes GH_HOST=localhost:18443 to $GITHUB_ENV. This persists to user-defined steps: blocks that run on the runner (outside AWF's container). Any gh command using an explicit --repo flag then treats the proxy as a GHES instance, attempts an enterprise version check, and fails with:
Upstream issue: github/gh-aw#35264
Why AWF is involved
AWF already solves this problem inside the agent container — src/services/agent-environment/github-actions-environment.ts (lines 18-23) strips the proxy-rewritten GH_HOST or replaces it with the real hostname derived from GITHUB_SERVER_URL. But user-defined steps: run directly on the runner, outside the container, so they still see the poisoned GH_HOST from $GITHUB_ENV.
The CLI proxy service (src/services/cli-proxy-service.ts) currently requires GH_HOST=localhost:${difcProxyPort} for TLS certificate SAN matching — gh needs to connect to the proxy with a hostname that matches its self-signed cert.
Proposed solution
Stop relying on GH_HOST to route gh CLI traffic through the proxy. Instead:
-
Use gh's --hostname or GH_HOST only inside the cli-proxy container (where it's scoped), not at the runner job level via $GITHUB_ENV.
-
Route via GITHUB_API_URL / GITHUB_GRAPHQL_URL — start_difc_proxy.sh already sets these to point at the proxy. The gh CLI uses these for API calls. The version-check issue only triggers when GH_HOST is set to a non-github.com value AND --repo is used (because gh resolves the host for the repo and does a GHES version probe).
-
If GH_HOST must be written to $GITHUB_ENV (for non---repo cases on GHES), write the real hostname (e.g., github.com or the GHES FQDN), not localhost:18443. The proxy routing should be handled entirely via GITHUB_API_URL/GITHUB_GRAPHQL_URL environment variables.
-
Alternatively, implement a /api/v3/meta endpoint on the DIFC proxy that returns a valid version response, so gh's GHES version check doesn't fail. This is more of a workaround than a proper fix.
Affected files
src/services/cli-proxy-service.ts — CLI proxy configuration (uses GH_HOST for cert SAN matching)
src/services/agent-environment/github-actions-environment.ts — Already strips proxy GH_HOST inside container
containers/cli-proxy/server.js — CLI proxy server implementation
Scope note
The primary fix for start_difc_proxy.sh writing to $GITHUB_ENV belongs in gh-aw (the setup action script). However, if the CLI proxy's TLS cert SAN strategy is changed (option 2/3 above), that change lives here in gh-aw-firewall.
Summary
The DIFC proxy setup script (
start_difc_proxy.shin gh-aw) writesGH_HOST=localhost:18443to$GITHUB_ENV. This persists to user-definedsteps:blocks that run on the runner (outside AWF's container). Anyghcommand using an explicit--repoflag then treats the proxy as a GHES instance, attempts an enterprise version check, and fails with:Upstream issue: github/gh-aw#35264
Why AWF is involved
AWF already solves this problem inside the agent container —
src/services/agent-environment/github-actions-environment.ts(lines 18-23) strips the proxy-rewrittenGH_HOSTor replaces it with the real hostname derived fromGITHUB_SERVER_URL. But user-definedsteps:run directly on the runner, outside the container, so they still see the poisonedGH_HOSTfrom$GITHUB_ENV.The CLI proxy service (
src/services/cli-proxy-service.ts) currently requiresGH_HOST=localhost:${difcProxyPort}for TLS certificate SAN matching —ghneeds to connect to the proxy with a hostname that matches its self-signed cert.Proposed solution
Stop relying on
GH_HOSTto routeghCLI traffic through the proxy. Instead:Use
gh's--hostnameorGH_HOSTonly inside the cli-proxy container (where it's scoped), not at the runner job level via$GITHUB_ENV.Route via
GITHUB_API_URL/GITHUB_GRAPHQL_URL—start_difc_proxy.shalready sets these to point at the proxy. TheghCLI uses these for API calls. The version-check issue only triggers whenGH_HOSTis set to a non-github.com value AND--repois used (becauseghresolves the host for the repo and does a GHES version probe).If
GH_HOSTmust be written to$GITHUB_ENV(for non---repocases on GHES), write the real hostname (e.g.,github.comor the GHES FQDN), notlocalhost:18443. The proxy routing should be handled entirely viaGITHUB_API_URL/GITHUB_GRAPHQL_URLenvironment variables.Alternatively, implement a
/api/v3/metaendpoint on the DIFC proxy that returns a valid version response, sogh's GHES version check doesn't fail. This is more of a workaround than a proper fix.Affected files
src/services/cli-proxy-service.ts— CLI proxy configuration (usesGH_HOSTfor cert SAN matching)src/services/agent-environment/github-actions-environment.ts— Already strips proxyGH_HOSTinside containercontainers/cli-proxy/server.js— CLI proxy server implementationScope note
The primary fix for
start_difc_proxy.shwriting to$GITHUB_ENVbelongs in gh-aw (the setup action script). However, if the CLI proxy's TLS cert SAN strategy is changed (option 2/3 above), that change lives here in gh-aw-firewall.