[Question] Copilot Requests permission unavailable for organization-owned repos, fine-grained PATs blocks CI/CD automation

[sriram-rach]

Question

Summary

When using GitHub Copilot CLI (@github/copilot) in GitHub Actions for organization repositories, authentication fails because fine-grained PATs cannot have both "Copilot Requests" permission AND organization repository access simultaneously.

Problem

Fine-grained Personal Access Tokens have a fundamental limitation:

Token Resource Owner	Copilot Requests Permission	Org Repository Access
Personal Account	✅ Available	❌ Limited
Organization	❌ Not Available	✅ Full Access

This forces users to choose between:

1. A user-owned token with Copilot access but limited org repo visibility
2. An org-owned token with repo access but no Copilot authentication

Use Case

We are trying to automate release notes generation using Copilot CLI in GitHub Actions:

- name: Generate release notes with Copilot
  env:
    COPILOT_GITHUB_TOKEN: ${{ secrets.COPILOT_TOKEN }}
  run: |
    copilot -p "Generate release notes for changes in the last 7 days across all repos in 'our-org'" --allow-all-tools < /dev/null

Error

When using an org-owned fine-grained PAT (with repo access but no Copilot Requests permission):

The organization 'org-name' either doesn't exist or isn't accessible.

When using a user-owned fine-grained PAT (with Copilot Requests but limited org access):

• Cannot access organization repositories

Expected Behavior

Organization-owned fine-grained PATs should have the "Copilot Requests" permission available, allowing enterprises to:

• Use Copilot CLI in CI/CD pipelines
• Access organization repositories with proper scoping

[austenstone]

Good question, and you've diagnosed it correctly — this is a GitHub platform constraint, not something this action can fix.

The "Copilot Requests" fine-grained permission is only offered on user-owned PATs by design, because a Copilot license is a per-user seat. Org-owned fine-grained PATs (and GitHub App tokens) have no user seat attached, so they can't make Copilot requests — that's intentional, not a gap this wrapper can work around.

Recommended workaround: a user-owned classic PAT

A classic PAT issued by a user who (a) has a Copilot seat and (b) is a member of your-org, with the repo scope and SSO-authorized for the org, gives you both in one token:

• ✅ Carries that user's Copilot entitlement (Copilot auth works)
• ✅ Full org repository access via the repo scope

- uses: austenstone/copilot-cli@v3
  with:
    copilot-token: ${{ secrets.COPILOT_PAT }}   # user-owned classic PAT, SSO-authorized
    prompt: "Generate release notes for the last 7 days across our-org"
    allow-all-tools: true

Heads up: as of v3.x the action wires copilot-token into COPILOT_GITHUB_TOKEN with correct precedence, so passing it through the copilot-token input authenticates properly (older versions had a token-precedence bug).

Alternatives

• A user-owned fine-grained PAT also works if your org admin has enabled fine-grained PATs and the specific repos are granted — but classic PATs are simpler for "all repos in the org."
• For org-wide automation, a service/bot user account with its own Copilot seat keeps it off a human's identity.

On the "expected behavior"

Org-owned FG-PATs gaining "Copilot Requests" would require GitHub to decouple Copilot billing from individual seats — that's product feedback for GitHub (https://github.com/orgs/community/discussions), not this repo.

Closing as answered — shout if the classic-PAT route doesn't unblock you. 👍