Summary

When a reusable workflow compiled by gh aw compile is invoked cross-org via workflow_call (caller in org-A, callee/platform repo in org-B, same enterprise), the activation job fails at multiple points. The compiled lock file cannot resolve the correct source repository, cannot check out the callee's files, and cannot verify the frontmatter hash.

This blocks all cross-org central-repo-ops patterns.

Environment

• gh-aw CLI: v0.67.2
• gh-aw-actions/setup: v0.67.2 (3922978bff4d7cf117e185580ad108da5a0134d8)
• Both organizations are in the same GitHub Enterprise Cloud account
• Callee repository visibility: internal

Bug 1: resolve_host_repo.cjs resolves to the caller repo

Expected

The "Resolve host repo for activation checkout" step should resolve to the callee (platform) repository so the checkout fetches the correct .github/ and .agents/ content.

Actual

It resolves to the caller repository. The script relies on GITHUB_WORKFLOW_REF (line 38), but in a workflow_call invocation, GITHUB_WORKFLOW_REF points to the top-level caller's workflow — not the reusable workflow being executed.

The code comment on line 14 states:

"GITHUB_WORKFLOW_REF always reflects the currently executing workflow file"

This is incorrect for workflow_call. The GitHub Actions docs confirm that github.workflow_ref resolves to the caller's workflow ref in reusable workflow contexts.

Suggested Fix

Apply the same referenced_workflows API lookup that check_workflow_timestamp_api.cjs already uses (lines 118–157). When the env workflow ref doesn't match the current lock file, query GET /repos/{caller}/actions/runs/{run_id} and find the matching entry in referenced_workflows[] to determine the correct callee repo and ref.

The target_repo_name output is already designed for actions/create-github-app-token (per the comment on line 76–77), confirming that cross-org was anticipated — the resolution logic just wasn't updated.

Bug 2: Checkout step cannot access the callee repo cross-org

Expected

The "Checkout .github and .agents folders" step should successfully clone the callee's repository content.

Actual

The checkout step uses the default GITHUB_TOKEN (no explicit token: parameter). The GITHUB_TOKEN is a GitHub App installation token scoped to the caller's organization. It cannot access repositories in a different org, even if both orgs are in the same enterprise and the callee repo is internal. The checkout fails with:

remote: Repository not found.
Error: fatal: repository 'https://github.com/<callee-org>/<callee-repo>/' not found

Suggested Fix — Two Options

Option A: actions/create-github-app-token integration

When resolve_host_repo detects a cross-org invocation (targetRepo !== currentRepo and different org prefix), the compiled workflow should include a step that mints a short-lived installation token via actions/create-github-app-token. This would require:

1. The user to install a GitHub App in both orgs (one-time admin setup)
2. App ID and private key stored as secrets, passed via workflow_call secrets
3. The compiled workflow to call actions/create-github-app-token with owner: and repositories: (using the existing target_repo_name output) to generate a cross-org token
4. That token is passed to the checkout step and hash check step

This is the standard GitHub-recommended approach for cross-org access.

Option B: Pre-inline all runtime imports during compilation (optional frontmatter flag)

An alternative that requires zero extra token setup: add an optional frontmatter flag (e.g., inline-imports: true or self-contained: true) that causes gh aw compile to inline all {{#runtime-import ...}} content directly into the lock file at compile time, rather than leaving them as runtime directives.

With fully inlined content:

• The cross-org checkout of .agents/ becomes unnecessary (no runtime imports to resolve)
• The checkout of .github/workflows/ is only needed for the hash check, which could be made non-fatal or skipped for cross-org scenarios
• The lock file becomes entirely self-contained — no runtime file dependencies

This would be particularly helpful for teams using central-repo-ops patterns where the platform repo and caller repos are in different organizations. The trade-off is larger lock files, which is why making it opt-in via frontmatter seems ideal.

Option B would be particularly valuable for our use case — we maintain a central platform repo with reusable agentic workflows consumed by repos across multiple orgs in the same enterprise. Eliminating the cross-org checkout dependency would significantly simplify adoption.

Bug 3: check_workflow_timestamp_api.cjs requires actions: read but the compiler doesn't add it

The hash check step calls github.rest.actions.getWorkflowRun() via the referenced_workflows API lookup (line 124). This requires the actions: read permission on the GITHUB_TOKEN. However, the compiled activation job only declares contents: read in its permissions: block.

Since explicit permissions: restricts the token to only the listed scopes, actions: read is absent and the API call fails with:

Error: Resource not accessible by integration

Suggested Fix

The compiler should add actions: read to the activation job's permissions: whenever it emits the check_workflow_timestamp_api.cjs step.

Reproduction

1. Create a reusable workflow in org-B using gh aw compile
2. Create a caller workflow in org-A (different org, same enterprise) that uses workflow_call to invoke the reusable workflow
3. Run the caller workflow
4. Observe:
   • resolve_host_repo resolves to org-A's repo (wrong)
   • Checkout clones org-A's repo (no .agents/ or .github/workflows/*.md present)
   • Hash check fails (no files on disk, API fallback also fails)

Summary of Fixes Needed

Option B (pre-inline with frontmatter flag) would be particularly valuable for our use case and likely for other teams adopting central-repo-ops across org boundaries.