`gh aw add` cannot be used from an agentic workflow to roll out shared workflows cross-repo, even when the source repo is public

[corymhall]

Summary

We are trying to use GitHub Agentic Workflows to roll out shared workflows into other repositories from a central worker workflow.

That use case feels like it should be supported, but today it appears blocked when the source workflows are installed with:

gh aw add owner/repo/path/to/workflow.md@ref

In our case, the source repository is public, but gh aw add still fails from inside the worker workflow with a GitHub authentication error.

Real example

We are using shared workflows from the public repository pulumi-labs/gh-aw-internal.

The worker runs:

gh aw add pulumi-labs/gh-aw-internal/.github/workflows/gh-aw-pr-review.md@main --name aws-pr-review --force
gh aw add pulumi-labs/gh-aw-internal/.github/workflows/gh-aw-pr-rereview.md@main --name aws-pr-rereview --force

and gets:

workflow 'pulumi-labs/gh-aw-internal/.github/workflows/gh-aw-pr-review.md@main' not found:
failed to download workflow from pulumi-labs/gh-aw-internal/.github/workflows/gh-aw-pr-review.md@main:
failed to create REST client: authentication token not found for host github.com

The important point is that pulumi-labs/gh-aw-internal is public.

So this does not appear to be just a private repo auth limitation. It looks like the CLI install path requires GitHub auth even in a rollout scenario where:

• the source repo is public
• the surrounding agentic workflow already has authenticated GitHub access configured for its GitHub MCP/tooling

Use case

We want to maintain shared workflows in one repository and roll them out across many other repositories using a central gh-aw workflow.

Example desired flow:

1. Central orchestrator parses rollout instructions.
2. Worker checks out target repo.
3. Worker runs gh aw add to install shared workflows from a source repo.
4. Worker runs gh aw compile and gh aw validate.
5. Worker opens one PR in the target repo.

This seems like a natural agentic-workflow-on-agentic-workflow use case.

Important detail

The installed workflows also contain frontmatter imports: entries such as:

imports:
  - pulumi-labs/gh-aw-internal/.github/snippets/code-review.md@main

That import target is also public.

So the problem appears to affect both:

1. top-level gh aw add owner/repo/path@ref
2. later import resolution during compile

Analysis

Our understanding from reading the code is:

• Remote workflow specs (owner/repo/path@ref) go through direct GitHub fetch logic.
• Local filesystem paths use a different code path.
• Running gh aw as MCP does not seem to change that backend behavior; it just changes how the agent invokes the command.
• The failure happens before any successful public fetch, because the CLI path errors with:
  failed to create REST client: authentication token not found for host github.com

That suggests the issue is not repository visibility by itself, but how gh aw add resolves GitHub access when invoked from inside an agentic workflow.

Expected behavior

At least one of these should work:

1. gh aw add should work inside an agentic workflow for public source repositories without requiring separate gh CLI auth.
2. gh aw add should automatically use the workflow's configured GitHub auth in this environment.
3. There should be a documented and supported rollout pattern for cross-repo installation of shared workflows.

Why this matters

Rolling out shared gh-aw workflows to many repositories from a central automation repo seems like a core use case for the product.

Right now, the worker can talk to GitHub through MCP, but the gh aw add and import-resolution path appears to use a separate CLI auth story that breaks this scenario even for public source repositories.

Reproduction

A minimal repro would be:

1. Put a workflow .md file in a public repo.
2. Optionally add a public remote imports: entry in that workflow.
3. In a separate repo, run an agentic workflow that invokes:

gh aw add owner/public-repo/.github/workflows/example.md@main
gh aw compile
gh aw validate

4. Observe that gh aw add and/or import resolution fails with a GitHub auth error instead of treating the public source as installable.

Requested outcome

Please support one of the following:

1. Make gh aw add and import resolution work inside agentic workflows for public source repos without extra gh CLI auth.
2. Automatically wire the workflow's configured GitHub auth into the CLI install/import path.
3. Document the supported rollout pattern for using gh-aw to install gh-aw workflows into other repositories.

Related issue

This may be adjacent to, but broader than, #19732 (GitHub App token is repo scoped).

[pelikhan]

@copilot the add command should attempt unauthenticated downloads for public repository. Also when SAML cross org issues creates auth issues on public file.