Summary

The gh aw compile command does not inject GH_HOST into workflow steps that use the gh CLI on GHE Cloud with data residency instances (*.ghe.com). This causes all gh CLI commands (like gh issue list, gh pr list) to fail with:

none of the git remotes configured for this repository point to a known GitHub host.
To tell gh about a new GitHub host, please use `gh auth login`

Additionally, the compiler does not add copilot-telemetry-service.<slug>.ghe.com to the firewall allowed domains list.

Environment

• gh-aw: v0.60.0
• Platform: GHE Cloud with data residency (EU)
• Domain: contoso-aw.ghe.com
• Workflow: repo-assist (from githubnext/agentics)

Reproduction

1. Create a workflow on a GHE Cloud data residency instance with api-target: "copilot-api.<slug>.ghe.com" in frontmatter
2. Run gh aw compile <workflow>
3. Dispatch the compiled lock file
4. The first step that uses gh CLI fails (e.g., "Fetch repo data for task weighting")

Evidence: Run 22287496 on contoso-aw.ghe.com/platform/aw-test — freshly compiled lock file, no manual edits. Fails at the very first gh CLI step.

Gap 1: GH_HOST not injected (BREAKING)

The compiled lock file does not set GH_HOST for steps that invoke the gh CLI. On *.ghe.com instances, the gh CLI requires GH_HOST to know which GitHub host to target.

Steps that need GH_HOST: <slug>.ghe.com:

• "Fetch repo data for task weighting" (uses gh issue list, gh pr list)
• "Clone repo-memory branch" (uses gh for git operations)
• "Execute GitHub Copilot CLI" (Copilot CLI needs GH_HOST for auth)
• Any other step that calls gh commands

The compiler already sets GH_HOST: github.com in one place (line 441 in the compiled output). For *.ghe.com instances, it should derive the correct value from GITHUB_SERVER_URL or the api-target frontmatter field.

Workaround: Manually add GH_HOST: <slug>.ghe.com to the env block of every gh-using step in the lock file. This gets wiped on every recompile.

Gap 2: copilot-telemetry-service domain missing (NON-BREAKING but suboptimal)

The compiler auto-adds copilot-api.<slug>.ghe.com to --allow-domains (fixed in gh-aw-firewall#1331), but does NOT add copilot-telemetry-service.<slug>.ghe.com.

HTTP traffic capture (run 22235251) showed the Copilot CLI contacts 4 hosts on data residency:

The telemetry domain is likely non-fatal (the CLI works without it), but telemetry requests will be blocked by the firewall, which may cause delays or warnings.

Note: gh-aw-firewall#1331 added telemetry domain auto-injection in extractGhecDomainsFromServerUrl(), but the gh-aw compiler may not be calling that function or may have its own domain list.

Comparison Methodology

Created a copy of the working (manually fixed) repo-assist.md, compiled it fresh with gh aw compile, then diffed the two lock files:

Manual lock file:  2141 lines (working — run 22240726 succeeded)
Compiled lock file: 1529 lines (failing — run 22287496 failed)

Key differences (excluding diagnostic steps we'd added):

• GH_HOST: contoso-aw.ghe.com present in 4 places in manual, 0 in compiled
• copilot-telemetry-service.contoso-aw.ghe.com in manual allow-list, absent in compiled
• copilot-api-target correctly set in both (compiler gets this right ✅)
• copilot-api.contoso-aw.ghe.com in allow-list in both (compiler gets this right ✅)

Suggested Fix

In the compiler, when GITHUB_SERVER_URL is a *.ghe.com domain:

1. Inject GH_HOST: <hostname> into the env: block of every step that uses gh CLI commands or the Copilot CLI
2. Add copilot-telemetry-service.<slug>.ghe.com to the --allow-domains and GH_AW_ALLOWED_DOMAINS lists

The hostname can be derived from GITHUB_SERVER_URL (available as ${{ github.server_url }} in Actions) or from the api-target frontmatter field.