Fix "You are not authorized to use this Copilot feature" — CLI

Copilot CLI refusing to run with "You are not authorized to use this Copilot feature, it requires an enterprise or organization policy to be enabled"? You are authenticated — GitHub is telling you a policy blocks this feature, which is a different problem from a failed sign-in.

The Error

✗ You are not authorized to use this Copilot feature, it requires an
  enterprise or organization policy to be enabled

It commonly arrives alongside these, all from the same root cause:

/models  → Failed to load models: access denied by Copilot policy.
           (Request ID: DFBE:25DEF5:25AD435:2B5358B:69C4FFD6)

/context → Context information is not yet available. Please wait for
           login to complete

That second one is misleading. It suggests sign-in is still in progress when in fact sign-in already succeeded and the policy check is what failed.

Why This Happens

Authentication and authorization are separate steps. Your token proves who you are; the policy check decides what that identity is permitted to use. You can hold a perfectly valid session and still be refused.

In order of likelihood:

1. The Copilot CLI policy is disabled for the organization or enterprise that provides your seat.
2. Policy propagation lag. Changes are cached and applied asynchronously. Users have reported the error clearing on its own after roughly thirty minutes with no configuration change at all, then returning days later.
3. The CLI is using the wrong account. If you belong to a personal account and one or more organizations, the token in use may be for an account whose policies differ from the one you assume.
4. A personal subscription is being overridden. Copilot Pro does not exempt you from an organization's policy when you are operating in that organization's context.
5. A stale cached token issued before a policy change, still presenting old entitlements.

Fix 1: Re-authenticate

Because a large share of these are stale-token or propagation problems, start here — it costs a minute and resolves a meaningful proportion of cases.

Sign out of the CLI, then sign back in, and watch which account the browser flow authorizes. If you have both a personal account and an organization account, confirm it is the one carrying your Copilot seat. Selecting the wrong identity here is a common and easily missed cause.

After signing back in, retry the command that failed. If the error persists immediately with no change, move on — this is a genuine policy block rather than a token problem.

Fix 2: Have an Admin Enable the Copilot CLI Policy

The policy governing Copilot CLI is set at the organization or enterprise level, under Copilot policy settings. An administrator needs to confirm it is enabled for the organization that provides your seat.

Two details that cause repeated back-and-forth with admins:

• The setting applies to the seat provider, not to you personally. If your seat comes from an organization, that organization's policy governs you regardless of any personal subscription.
• Enabling a policy is not instant. Expect propagation delay before the CLI reflects the change. Do not conclude the setting did not work because it failed thirty seconds later.

If you are the administrator and the settings genuinely have not changed since it last worked, you are most likely looking at Fix 3 rather than a configuration error — several reports describe exactly this, with admins confirming no setting changed between a working session and a failing one.

Fix 3: Wait Out Propagation

This feels unsatisfying and is nonetheless frequently correct. The error has been reported to:

• appear a few times a week and disappear again without intervention
• resolve consistently after about thirty minutes of waiting
• persist for days for some users while others on the same organization are unaffected

If your settings are correct and unchanged, re-authenticate once, wait, and retry before escalating. Escalating immediately usually produces an admin confirming the policy is already on — which you both already knew.

Fix 4: Confirm Your Seat and Plan

Verify separately that a Copilot seat is actually assigned to the account the CLI is using. A missing seat produces a different message — not licensed to use Copilot — which is covered in FORBIDDEN: unauthorized: not licensed to use Copilot. If you see that string instead, follow that guide.

The distinction matters because the fixes differ:

For token, SSO and SAML problems rather than policy problems, see GitHub Copilot CLI authorization errors.

Verify the Fix

Start a session and run a command that exercises the policy path:

/models

Success is a populated model list rather than access denied by Copilot policy. That command is a better test than simply launching the CLI, because it round-trips through the same authorization check that produced the original error.

Then run an ordinary prompt to confirm normal operation. If /models succeeds but prompts still fail, capture both outputs — that combination indicates something narrower than a blanket policy block.

Prevention

• If you administer the organization, document which Copilot policies are enabled and review them alongside seat assignment, so a policy toggle and a seat grant do not drift apart.
• Keep the CLI updated. Several reports are version-specific, and authorization handling has changed across releases.
• When you belong to multiple accounts, be deliberate about which identity the CLI authorizes, and re-check after any sign-out.
• Record the Request ID whenever a policy message includes one. It is the fastest way for support to trace a specific rejection, and it is lost as soon as the terminal scrolls.
• Treat intermittent failures with unchanged settings as propagation until proven otherwise, rather than repeatedly reconfiguring a policy that is already correct.

Summary

1. This is authorization, not authentication — being signed in does not mean being permitted
2. Re-authenticate first and confirm which account the browser flow authorizes
3. Have an admin verify the Copilot CLI policy on the organization providing your seat
4. Allow for propagation delay — reports describe it clearing after about thirty minutes
5. Distinguish it from "not licensed", which means no seat rather than a disabled policy
6. Test with /models, which exercises the same authorization path