Suspected regression in v0.65.6: `Install GitHub Copilot CLI` no longer emits `GH_HOST: github.com`

[jaroslawgajewski]

Summary

It looks like gh aw compile may have regressed in v0.65.6 for workflows that set a workflow-level env.GH_HOST value for GitHub Enterprise Server.

Historically, the compiled Install GitHub Copilot CLI step emitted:

env:
  GH_HOST: github.com

Was natively handled since v0.58.3

That override is important because the Copilot CLI install/download path needs github.com, while GHES workflows commonly set a top-level GH_HOST for later GHES API calls.

In v0.65.6, this override may no longer be emitted automatically.

Expected behavior

When compiling a workflow that uses Copilot CLI, the generated Install GitHub Copilot CLI step should still include:

so the install step is isolated from any workflow-level GHES GH_HOST setting.

Actual behavior

In v0.65.6, the compiled workflow appears to omit that step-level override, allowing the workflow-level GH_HOST to leak into the Copilot CLI install step.

Why this matters

On GHES deployments, workflows often require a top-level GH_HOST such as a GHES hostname. If that value propagates into the Copilot CLI install step, the install/auth path can target the wrong host.

Minimal reproduction

Create a minimal workflow source with:
engine: copilot
a workflow-level env.GH_HOST set to a non-github.com host
Run:

gh aw compile path/to/workflow.md

Inspect the generated lock file:

grep -n "Install GitHub Copilot CLI" path/to/workflow.lock.yml
grep -n "GH_HOST: github.com" path/to/workflow.lock.yml

Check whether the install step still contains the explicit GH_HOST: github.com override.

[pelikhan]

@lpcox let's chat about GHE

[lpcox]

Diagnosis

This regression was real but has already been fixed on main.

Timeline

1. PR refactor: eliminate duplicated AWF injection, secret validation, and MCP secret collection across engine implementations #24283 (374ed78a79, merged earlier today) — "refactor: eliminate duplicated AWF injection" — This refactor accidentally removed the GH_HOST: github.com env pin from the Install GitHub Copilot CLI step. The refactor comment incorrectly stated that GH_HOST should not be hardcoded.

2. PR fix: restore GH_HOST: github.com pin on Install GitHub Copilot CLI step #24321 (b3c60d2d79, also merged today) — "fix: restore GH_HOST: github.com pin" — This immediately restored the pin, including a clear comment explaining why it's needed:

// GH_HOST is pinned to github.com at the step level to prevent any workflow-level
// env.GH_HOST (common on GHES deployments) from leaking into this step and
// interfering with the Copilot CLI install/auth path, which requires github.com.

Current state

The fix is already on main. Current copilot_installer.go correctly emits:

- name: Install GitHub Copilot CLI
  run: ${RUNNER_TEMP}/gh-aw/actions/install_copilot_cli.sh latest
  env:
    GH_HOST: github.com

Action needed

This issue can be closed. Any workflows compiled from current main (or the next release after v0.65.6) will include the GH_HOST: github.com pin. Workflows compiled during the brief window when #24283 was merged but #24321 was not should be recompiled with gh aw compile.

[lpcox]

Correction to my earlier diagnosis — the user is right, this affects released versions.

Actual timeline

1. v0.58.3 — PR fix: emit GH_HOST: github.com on Install GitHub Copilot CLI step to prevent GHES host leakage #20992 (5a8a60ab96) added the GH_HOST: github.com pin on the Install Copilot CLI step
2. v0.64.3 — PR Fix DIFC proxy GH_HOST mismatch for user-defined setup steps #23367 (4549e7bc20) / commit ec9495c0f2 removed it as part of the DIFC proxy GH_HOST mismatch fix. The rationale was that configure_gh_for_ghe.sh and the new "Derive GH_HOST" step would handle it. This was incorrect — those don't protect against workflow-level env.GH_HOST overrides.
3. v0.64.3 through v0.65.6 — All released versions are missing the pin
4. main (unreleased) — PR fix: restore GH_HOST: github.com pin on Install GitHub Copilot CLI step #24321 (b3c60d2d79) restored the pin

Affected versions

Version	GH_HOST pin present?
v0.58.3 – v0.64.2	✅ Yes
v0.64.3 – v0.65.6	❌ No (regression)
main (unreleased)	✅ Yes (fixed by #24321)

Impact

Any GHES workflow compiled with v0.64.3 through v0.65.6 that sets a workflow-level env.GH_HOST will have that value leak into the Copilot CLI install step. The fix in #24321 is on main but not yet released.

Workaround

Until the next release, users can work around this by not setting GH_HOST at the workflow level, or by recompiling from a local build of main.