Skip to content

CLI proxy: GH_HOST=localhost:18443 in $GITHUB_ENV breaks gh --repo in user-defined steps #3937

@lpcox

Description

@lpcox

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:

malformed version: 

Upstream issue: github/gh-aw#35264

Why AWF is involved

AWF already solves this problem inside the agent containersrc/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:

  1. 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.

  2. Route via GITHUB_API_URL / GITHUB_GRAPHQL_URLstart_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).

  3. 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.

  4. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions