'malformed version' for all `gh` commands in user steps using explicit `--repo`

[dsyme]

Summary

start_difc_proxy.sh writes GH_HOST=localhost:18443 to $GITHUB_ENV, which persists to all subsequent steps in the job. Any gh CLI command in a user-defined steps: block that uses an explicit --repo flag then treats the DIFC proxy as a GitHub Enterprise Server, attempts an enterprise version check against it, receives an empty version string, and exits with:

malformed version: 

This crashes the step before any real work is done.

Affected scope

gh commands with an explicit --repo owner/repo flag in user-defined steps: that run after "Start DIFC Proxy". Commands that omit --repo (relying on GITHUB_REPOSITORY) appear to be unaffected — gh uses GITHUB_API_URL directly in that case and skips the host version check.

Comparison: A comparable workflow on fsprojects/FSharp.Data using the same gh-aw v0.76.1 does NOT reproduce this. Its steps: use gh issue list --state open ... and gh pr list --state open ... without --repo, which succeed fine even with GH_HOST=localhost:18443 in the environment.

Reproduction

Add a gh command with --repo to a steps: block in a workflow that starts the DIFC proxy:

steps:
  - name: Fetch data
    env:
      GH_TOKEN: ${{ secrets.MY_PAT }}
    run: |
      gh issue list --repo owner/other-repo --json number,title > /tmp/issues.json

The step immediately fails with malformed version: because GH_HOST=localhost:18443 (written to $GITHUB_ENV by start_difc_proxy.sh) causes gh to attempt a GHES enterprise version check against the proxy before making any API call.

Root cause

start_difc_proxy.sh contains something equivalent to:

echo "GH_HOST=localhost:18443" >> "$GITHUB_ENV"

This sets GH_HOST for the rest of the job. The gh CLI treats any non-github.com value for GH_HOST as a GitHub Enterprise Server hostname and performs a version validation before API calls made with --repo. The DIFC proxy doesn't implement the GHES version endpoint, so it returns an empty string, which gh rejects as malformed version: .

Workaround

Override GH_HOST at the shell level at the top of the run: script:

GH_HOST=github.com  # override proxy-injected GH_HOST; API traffic still routes
                    # through the proxy via GITHUB_API_URL / GITHUB_GRAPHQL_URL
gh issue list --repo owner/other-repo ...

Note: a step-level env: GH_HOST: github.com in the gh-aw source file has no effect because the gh-aw compiler does not preserve user-defined step env: blocks in the compiled lock file. The override must be inside the run: script.

Expected behaviour

User-defined steps: should be able to use gh --repo commands without a workaround. Either:

• start_difc_proxy.sh should not write GH_HOST to $GITHUB_ENV (or should write GH_HOST=github.com), relying on GITHUB_API_URL / GITHUB_GRAPHQL_URL to route API traffic through the proxy, or
• The proxy setup should configure gh in a way that doesn't require GH_HOST to point at the proxy address for routing to work

Environment

• gh-aw compiler version: v0.76.1
• gh CLI version: 2.79.0
• DIFC proxy image: ghcr.io/github/gh-aw-mcpg:v0.3.19

[lpcox]

Root Cause Analysis

Confirmed the exact failure chain by examining MCPG proxy logs from a failing run:

What happens

1. The gh-aw compiler injects GH_HOST=localhost:18443 as step-level env: on user-defined steps (via proxyEnvVars() in compiler_difc_proxy.go:288)
2. When gh --repo owner/name runs, it resolves the host from GH_HOST → sees localhost:18443 ≠ github.com → assumes GHES
3. gh calls GET https://localhost:18443/api/v3/meta to get the GHES version
4. The MCPG proxy correctly receives and forwards this request to https://api.github.com/meta (confirmed in logs: passthrough GET /meta, forwarding GET /meta → https://api.github.com/meta)
5. github.com returns /meta without an installed_version field (that field only exists on GHES instances)
6. gh tries to parse the empty version → malformed version: ""

Key insight

The problem is not connectivity or routing — the proxy handles /meta fine. The problem is semantic: gh thinks it is talking to GHES (because GH_HOST ≠ github.com), but the upstream is actually github.com, which does not return installed_version in its /meta response.

github.com /meta response keys (no installed_version):

verifiable_password_authentication, ssh_key_fingerprints, ssh_keys,
hooks, web, api, git, github_enterprise_importer, packages, pages,
importer, actions, actions_macos, codespaces, copilot, domains

Proposed fix

For non-GHES environments: set GH_HOST=github.com (or omit it entirely) in proxyEnvVars().

This works because:

• gh uses GH_HOST only for host identity (deciding github.com vs GHES)
• gh uses GITHUB_API_URL for actual API routing (already set to https://localhost:18443/api/v3)
• Setting GH_HOST=github.com makes gh skip the /meta version check entirely while all API traffic still flows through the proxy via GITHUB_API_URL

For GHES environments, GH_HOST should be set to the real GHES hostname (derived from GITHUB_SERVER_URL), so that gh calls /meta through the proxy → proxy forwards to the real GHES upstream → GHES returns installed_version → version check succeeds.

Implementation sketch

In compiler_difc_proxy.go proxyEnvVars():

// Instead of unconditionally setting GH_HOST=localhost:18443:
if isGHES(serverURL) {
    // Use real hostname so gh version check works through the proxy
    ghHost = extractHost(serverURL)  
} else {
    // github.com: set explicitly to skip the GHES version check
    ghHost = "github.com"
}

This is a one-line change in the compiler that fixes all gh --repo commands in user-defined workflow steps without requiring any proxy-side changes.