Support for org-wide GitHub App tokens

[straub]

Hi folks,

I have some agentic workflows that benefit from looking up information across my organization. I would love to be able to create a GitHub App token valid for all repos in an organization, but the current safe_outputs_app.go doesn't support that form, it always supplies a repositories field.

Is this an intentional omission, or would you be open to a PR to support this? I've been having a great time experimenting with Agentic Workflows lately, so I'd be very happy to provide a Copilot PR to implement this.

Thanks for your time!

[pelikhan]

/scout expand this bug report and provide mode details.

[github-actions]

🔍 Scout Research Report

Triggered by @pelikhan

Executive Summary

This feature request is valid and well-founded. The current implementation in safe_outputs_app.go:141-149 always supplies a repositories field when creating GitHub App tokens, which restricts token scope to specific repositories. According to the official actions/create-github-app-token documentation, omitting the repositories field entirely grants access to all repositories in the organization/owner's installation—a critical capability for org-wide agentic workflows.

Click to expand detailed findings

Research Findings

Current Implementation Limitation

The code at pkg/workflow/safe_outputs_app.go:141-149 demonstrates the issue:

// Add repositories - default to current repository name if not specified
if len(app.Repositories) > 0 {
    reposStr := strings.Join(app.Repositories, ",")
    steps = append(steps, fmt.Sprintf("          repositories: %s\n", reposStr))
} else {
    // Extract repo name from github.repository (which is "owner/repo")
    // Using GitHub Actions expression: split(github.repository, '/')[1]
    steps = append(steps, "          repositories: $\{\{ github.event.repository.name }}\n")
}

Problem: The else clause defaults to the current repository when no repositories are specified, preventing org-wide token creation.

How Org-Wide Tokens Work

According to the official actions/create-github-app-token action documentation:

repositories (Optional): Comma or newline-separated list of repositories to grant access to.

Note: If owner is set and repositories is empty, access will be scoped to all repositories in the provided repository owner's installation.

Example from documentation:

- uses: actions/create-github-app-token@v2
  id: app-token
  with:
    app-id: $\{\{ vars.APP_ID }}
    private-key: $\{\{ secrets.PRIVATE_KEY }}
    owner: $\{\{ github.repository_owner }}
  # Note: No repositories field = org-wide access

Use Cases for Org-Wide Tokens

Research identified several compelling use cases for org-wide GitHub App tokens in agentic workflows:

1. Cross-Repository Issue Tracking: Centralizing issue tracking by automatically creating tracking issues in a central repository with status synchronization and multi-component coordination

2. Hub-and-Spoke Architecture: Central repository aggregates information from multiple component repositories across an organization

3. Organization-Wide Coordination: Workflows that discover and process work items across multiple repositories without knowing repository names in advance

4. Multi-Repository Search and Analysis: Agents that need to search across all organization repositories (e.g., security audits, dependency tracking, documentation updates)

5. Dynamic Repository Discovery: Workflows that dynamically discover repositories based on criteria (topics, languages, activity) rather than static lists

From the gh-aw documentation on Multi-Repository Examples:

"All multi-repo workflows require proper authentication. GitHub App tokens are minted on-demand, automatically revoked after job completion, and provide better security than long-lived PATs."

Security Considerations

Org-wide tokens are secure when properly configured because:

1. Permissions are still scoped: The token only gets the specific permissions (contents, issues, PRs) granted to the GitHub App installation
2. Time-limited: Tokens expire after 1 hour automatically
3. Auto-revoked: gh-aw automatically revokes tokens after job completion
4. Audit trail: All actions are attributed to the GitHub App with clear logging
5. Installation-level control: Organization admins control which repos the App is installed on

This is actually more secure than PATs which:

• Are long-lived unless manually rotated
• Have broader scope across all accessible repositories
• Don't provide automatic revocation
• Are tied to user accounts rather than automation identities

Implementation Approach

The fix requires modifying the conditional logic in buildGitHubAppTokenMintStep to omit the repositories field entirely when no repositories are specified:

// Add repositories - only if explicitly specified
if len(app.Repositories) > 0 {
    reposStr := strings.Join(app.Repositories, ",")
    steps = append(steps, fmt.Sprintf("          repositories: %s\n", reposStr))
}
// When omitted: owner specified + no repositories = org-wide access
// When omitted: no owner + no repositories = current repo access (GitHub default)

This change aligns with the behavior of actions/create-github-app-token:

• With owner + no repositories: Token scoped to all repos in that owner's installation
• No owner + no repositories: Token scoped to current repository (default behavior)
• With repositories list: Token scoped to specified repositories (existing behavior)

Recommendations

1. Accept this feature request: The limitation is unintentional and prevents valid use cases

2. Implement the suggested fix: Modify buildGitHubAppTokenMintStep to conditionally omit the repositories field when app.Repositories is empty

3. Add documentation: Update the safe-outputs documentation to explain:

   • How to configure org-wide tokens (specify owner, omit repositories)
   • Security implications and best practices
   • Example workflows for common org-wide patterns

4. Consider a Copilot PR: As the reporter suggested, this is an excellent candidate for automated implementation via Copilot

Key Sources

• actions/create-github-app-token README - Official documentation showing org-wide token usage
• [Multi-Repository Examples | GitHub Agentic Workflows]((github.github.io/redacted) - Use cases for cross-repository automation
• GitHub API: Create installation access token - Underlying API behavior

Suggested Configuration Example

After implementation, users could configure org-wide tokens like this:

safe-outputs:
  app:
    app-id: $\{\{ vars.APP_ID }}
    private-key: $\{\{ secrets.APP_PRIVATE_KEY }}
    owner: $\{\{ github.repository_owner }}
    # Omit repositories field for org-wide access
  create-issue:
    target-repo: "org/any-repo"  # Can now target any repo in the org

Conclusion

This is a straightforward fix with clear benefits for organization-wide agentic workflows. The limitation appears to be an oversight rather than an intentional design choice, and removing it would significantly expand the capabilities of gh-aw for enterprise use cases.

🔭 Intelligence gathered by Scout for issue #16424

[pelikhan]

Add support for * to allow all repositories. Keep current behavior of locking down to current repositories when omitted.