gh aw add-wizard on GHE: confusing cross-host workflow resolution (github.com workflow source)

[anthonymastreanvae]

Summary

When using gh aw add-wizard from a repository hosted on GitHub Enterprise (GHE), workflow specs in shorthand form (for example owner/repo/workflow) are resolved against GHE instead of github.com.

For public workflow catalogs (for example githubnext/agentics/...), this fails with HTTP 404 and a misleading "workflow not found"/"resolve main to commit SHA" path, even though the workflow exists on github.com.

Using a full github.com URL works, so this appears to be a cross-host resolution behavior/UX issue.

Environment

• OS: macOS 26.4.1 (Apple Silicon)
• Kernel/arch: Darwin 25.4.0, arm64
• CPU: Apple M5 Max
• gh: 2.92.0
• gh-aw: v0.74.0
• Extension source: github/gh-aw
• Auth host: GHE (sanitized): ghe.example.com
• Repo (sanitized): example/example-repo

Reproduction

1) In a GHE-hosted repo

cd /path/to/example-repo

2) Run shorthand workflow spec

gh aw add-wizard githubnext/agentics/daily-repo-status

3) Observe failure

failed to resolve workflows
workflow 'githubnext/agentics/workflows/daily-repo-status.md' not found
failed to resolve 'main' to commit SHA for 'githubnext/agentics'
failed to resolve ref main to SHA for githubnext/agentics: gh: Not Found (HTTP 404)

4) Run full github.com URL instead

gh aw add-wizard https://github.com/githubnext/agentics/blob/main/workflows/daily-repo-status.md

5) Observe interactive repository detection warning

⚠ Could not determine the repository automatically.
✓ Target repository: example/example-repo   # provided interactively

6) Try forcing host explicitly

GH_HOST=ghe.example.com gh aw add-wizard https://github.com/githubnext/agentics/blob/main/workflows/daily-repo-status.md

7) Observe GH_HOST does not resolve auto-detection warning

⚠ Could not determine the repository automatically.
✓ Target repository: example/example-repo   # provided interactively

8) Run continues to later validation (for example dirty working tree)

✗ Working directory is not clean.

Expected behavior

One of these should happen:

1. gh aw should support cross-host fetch for public workflow sources by default (github.com source + GHE target repo), or
2. gh aw should fail with a very explicit message for shorthand specs in GHE contexts, including a remediation hint to use full github.com URL syntax.

Actual behavior

• Shorthand specs are resolved against GHE and fail with 404/missing workflow messaging that looks like workflow/ref problems.
• Full github.com URL resolves workflow content, but wizard repository auto-detection still warns and requires interactive target confirmation.
• Setting GH_HOST explicitly does not remove the auto-detection warning in this flow.

Why this matters

Teams on GHE commonly consume public workflow templates from github.com. Current behavior is easy to misdiagnose and creates avoidable support load.

Because repository detection in the wizard is unreliable in this flow, users cannot trust the guided experience described in quick start and must manually validate each step.

Practical impact in this scenario:

• Prerequisite checks and repository targeting require manual confirmation.
• AI engine selection still proceeds, but in a partially degraded flow.
• Secret setup must be handled manually with extra caution because the flow already failed key auto-detection behavior.
• Workflow installation and first-run triggering become manual/confirm-heavy tasks instead of a dependable guided path.

Suggested fix

• Prefer explicit source-host parsing logic:
  • Shorthand: resolve on current host (or document clearly)
  • URL: always resolve against URL host
• Improve error text for shorthand on GHE when repo/ref lookup returns 404:
  • "This spec was resolved on . If the workflow is on github.com, use the full URL form."

Footer

Agent attribution: Drafted with GitHub Copilot (GPT-5.3-Codex) in VS Code and reviewed by the reporter.

[pelikhan]

@copilot cross host should automatically use the https://github.com/github org as a fallback

[anthonymastreanvae]

Update: I found a major confounder in my environment.

This repo had been transferred, and my local origin was stale (GHE redirect in play). After updating the remote to the correct owner/repo, gh aw add-wizard started working as expected.

So at least part of the behavior reported here was caused by repository identity mismatch rather than gh-aw itself.

If helpful, I can retest and post a minimal repro containing only symptoms that still reproduce with:

• correct origin
• correct gh repo view target
• no redirect/mismatch

[pelikhan]

@salmanmkc

[pelikhan]

@copilot report clearly that full URLs are to be used in GHE

#34521

• special case github, githubnext, microsoft orgs