`gh aw trial` is unusable on GitHub Enterprise Server — git clone operations hardcode github.com (ignore `GH_HOST`)

[anthonymastreanvae]

Summary

On GitHub Enterprise Server (GHES), gh aw trial fails in every repository mode because its git clone operations target github.com regardless of GH_HOST or the active gh host. The tool's API calls resolve correctly against the enterprise host (the repo-existence check succeeds), but the git clone of that same repo goes to github.com and fails with Repository not found / Authentication failed. Two distinct clone steps are affected:

• --clone-repo <owner>/<repo> clones the source repo from github.com.
• Default / direct mode (no --clone-repo) clones the host repo from github.com.

There is no flag or environment override, so trial cannot run on GHES at all.

Environment

• gh-aw: v0.79.8 (CLI extension; github/gh-aw-actions/setup@v0.79.8)
• Host: GitHub Enterprise Server (private), GH_HOST=example.ghe.com
• gh auth: authenticated to the GHES host only (no github.com token)
• OS: macOS

Reproduction & evidence

Two modes, two different git-clone failures, one shared root cause. The discriminating detail in both: the ✓ Using existing host repository line resolves on the enterprise host (the API path honors GH_HOST), but the very next git clone URL is https://github.com/....

A) --clone-repo — fails cloning the source:

GH_HOST=example.ghe.com gh aw trial ./.github/workflows/my-workflow.md \
  --host-repo myorg/gh-aw-trial --clone-repo myorg/source-repo --yes

ℹ Clone mode: Will clone contents from myorg/source-repo into host repository
✓ Using existing host repository: https://github.com/myorg/gh-aw-trial
✗ failed to clone repository contents
  failed to clone source repository https://github.com/myorg/source-repo.git: exit status 128 (output:
  remote: Repository not found.
  fatal: Authentication failed for 'https://github.com/myorg/source-repo.git/'
  )

B) No --clone-repo (direct mode) — fails cloning the host:

GH_HOST=example.ghe.com gh aw trial ./.github/workflows/my-workflow.md \
  --host-repo myorg/gh-aw-trial --yes

ℹ Direct trial mode: Workflows will be installed and run directly in the specified repository
✓ Using existing host repository: https://github.com/myorg/gh-aw-trial
✗ failed to clone host repository
  failed to clone host repository https://github.com/myorg/gh-aw-trial.git: exit status 128 (output:
  remote: Repository not found.
  fatal: Authentication failed for 'https://github.com/myorg/gh-aw-trial.git/'
  )

(myorg/gh-aw-trial and myorg/source-repo exist on example.ghe.com, not on github.com.)

Relationship to #<CLONE_REPO_ISSUE>

#<CLONE_REPO_ISSUE> reports mode (A) only — the --clone-repo source clone hitting github.com. It's a real, valid report, but it's one symptom of a wider bug: in --clone-repo mode the run dies at the source clone, which masks the fact that the host clone has the same defect. Drop --clone-repo and mode (B) surfaces it — the host clone fails the same way. Same hardcoded-host construction, two clone sites.

Filing both, cross-linked, so the fix isn't scoped to the --clone-repo path alone: correcting only mode (A) would leave trial still broken in mode (B). The suggested fix below addresses the shared construction and resolves both.

Expected

All trial git operations — host clone and source clone — use the same host that the API operations and gh are authenticated to (GH_HOST / the active gh host), so trial works on GHES.

What I tried

• GH_HOST=example.ghe.com set explicitly — git clones still target github.com.
• Full GHES URL for --clone-repo (https://example.ghe.com/myorg/source-repo) — reduced to owner/repo, still cloned from github.com.

Likely cause

Trial constructs git clone URLs as https://github.com/<owner>/<repo>.git with a hardcoded host, while repo-existence/API calls go through the gh client that honors GH_HOST. The host-repo clone (direct mode) and the --clone-repo source clone share this construction, so the API path and the git path disagree on the host.

Suggested fix

Derive the git-clone host from the same resolved gh host the API path already uses, and honor a fully-qualified URL passed to --clone-repo verbatim. Because both modes share the URL construction, one fix should cover host clone and source clone together.

Impact and workaround

gh aw trial is unusable on GHES today (it fails closed — no github.com token, so it errors rather than reaching the wrong host, but it cannot proceed). Workaround: skip trial and validate by running the compiled workflow on GHES Actions directly — e.g. dispatch it against a branch in the real repository. That executes server-side on the enterprise host and is unaffected by the CLI's clone-host construction.

---

Related: #39881 reports the --clone-repo source-clone failure. This issue is the broader root cause that also breaks the default/direct mode — see Relationship below. Likely one shared fix.