Fix "FORBIDDEN: unauthorized: not licensed to use Copilot" (403)

Seeing a 403 with unauthorized: not licensed to use Copilot? This one has a precise, documented meaning: the account that owns the credential has no Copilot seat. It is a licensing problem, and no amount of re-authenticating will fix it.

The Error

403 "unauthorized: not licensed to use Copilot"

Frequently seen as part of a longer failure:

Failed to list models: 403 : unauthorized: not authorized to use this Copilot feature
FORBIDDEN: unauthorized: not licensed to use Copilot

GitHub's own troubleshooting documentation states the cause and fix directly: the cause is "No Copilot seat for PAT owner", and the resolution is that a site admin enables Copilot and an org admin assigns a seat to the token owner.

The phrase "token owner" is the part that trips people up, and it is the key to the whole diagnosis.

Why This Happens

1. The account has no Copilot seat. The straightforward case: nobody has assigned one.
2. The seat and the token belong to different accounts. You have a seat; the request is authenticated as somebody or something else — a machine account, a bot, a shared service identity, or a colleague's token left in an environment variable. The seat check applies to whoever owns the credential.
3. The token lacks the right permission. A fine-grained token needs Copilot Requests: Read; a classic token needs the copilot scope. A token without it produces a related error about the resource not being accessible by the personal access token.
4. GitHub Enterprise Server without enterprise Copilot enabled, or with GitHub Connect not configured. In that state you may also see Error loading models: 400 Bad Request.
5. A seat was recently revoked or reassigned — common when someone changes teams or a licence pool is rebalanced.

Distinguish this carefully from the neighbouring error. If your message says not authorized to use this Copilot feature, a seat exists and a policy is blocking a specific capability — see You are not authorized to use this Copilot feature instead.

Fix 1: Identify the Token Owner

Before asking anyone for a licence, establish which account is actually making the request. This is where most of these get misdiagnosed.

Check whether a token is set in your environment, because an explicit token silently overrides an interactive sign-in:

env | grep -i -E 'GITHUB_TOKEN|GH_TOKEN|COPILOT'

If one is present, it — not your browser session — is authenticating the request, and its owner needs the seat. Unset it to fall back to your own credentials:

unset GITHUB_TOKEN GH_TOKEN

Then retry. If the error disappears, you have your answer: the token belonged to an account without a seat.

Fix 2: Get a Seat Assigned to That Account

Once you know the owning account, an administrator needs to assign it a Copilot seat in the organization's Copilot settings.

Give the admin the login of the token owner, not your own name. When a CI pipeline or shared automation is failing, the account needing the seat is frequently a machine account nobody thinks of as a "user", and a request phrased as "please give me access" gets the wrong account licensed.

After the seat is granted, sign out and back in so a fresh token reflecting the new entitlement is issued. Reusing a token minted before the change can keep returning the same 403.

Fix 3: Check Token Permissions

A seat alone is not sufficient if the credential cannot carry Copilot requests. GitHub documents the requirement as a fine-grained personal access token with Copilot Requests: Read, or a classic token with the copilot scope.

If you see 403 "Resource not accessible by personal access token" rather than the licensing message, this is your problem rather than seat assignment. Regenerate the token with the correct permission and retry.

Fix 4: GitHub Enterprise Server Specifics

On GHES the entitlement chain has an extra link. Confirm with your site administrator that:

• Copilot is enabled for the enterprise in site admin settings
• GitHub Connect is enabled — without it, enterprise Copilot licensing cannot be resolved
• The seat is assigned within the enterprise, not only on github.com

A 400 Bad Request when loading models, rather than a 403, points specifically at enterprise Copilot not being licensed or GitHub Connect being off.

You may also need GH_HOST set to your GHES hostname for CLI commands to target the right server at all.

Verify the Fix

Start a session and exercise the authorization path directly:

/models

A populated model list confirms both the seat and the token permission are correct. Continuing to see a 403 means the seat still is not attached to the identity making the request — return to Fix 1 and re-confirm the token owner.

For sign-in and SSO problems that are genuinely authentication rather than licensing, see GitHub Copilot CLI authorization errors.

Prevention

• Give automation its own machine account with its own explicitly assigned Copilot seat, and document that the seat exists. Automation failing months later because nobody knew a bot needed a licence is a recurring pattern.
• Audit seat assignment when people change teams. Reassignment silently breaks whatever that account was authenticating.
• Avoid leaving GITHUB_TOKEN set globally in your shell profile. It overrides interactive sign-in in ways that are invisible until something 403s.
• When creating tokens for Copilot, set Copilot Requests: Read (fine-grained) or the copilot scope (classic) at creation time rather than diagnosing it later.
• Record which accounts hold seats alongside which policies are enabled — the two are separate controls and both must be right.

Summary

1. This means no Copilot seat for the token owner — GitHub documents that cause explicitly
2. Find out which account owns the credential with env | grep GITHUB_TOKEN; unset it and retry
3. Have an admin assign a seat to that exact account, then sign out and back in
4. Check token permissions — Copilot Requests: Read, or the copilot scope
5. On GHES, confirm enterprise Copilot and GitHub Connect are both enabled
6. Do not confuse it with "not authorized to use this Copilot feature", which is a policy toggle