Manage Copilot and users via Enterprise Teams in public preview

[Akash1134]

🆕 GitHub Enterprise Cloud now offers Enterprise Teams in public preview, streamlining enterprise user and Copilot license management experiences for businesses.

Enterprise owners can now:

• Add users directly to the enterprise without requiring organization access. These unaffiliated users do not consume a license by default.
• Create and manage groups of users in the enterprise account through Enterprise Teams.
• Enterprise accounts with Enterprise Managed Users can synchronize groups of users from their identity provider to Enterprise Teams via SCIM.
• Manage Copilot Business licenses for individuals or entire enterprise teams through the enterprise-level Copilot licensing page.

---

What Enterprise Teams enable ❓

In the coming months, enterprise owners will also be able to use enterprise teams to:

• Assign an enterprise role.
• Assign it to a number of organizations within that enterprise, granting organization membership.
• Empower organization and repository owners to assign roles to teams within their scope.

Unaffiliated users (non-EMU enterprises) 👀

For enterprises that do not use enterprise-managed users (EMU), enterprise owners can now invite unaffiliated users to their enterprise. These users will not have access to organizations or licenses by default, but can later be assigned to an enterprise team, an organization, or Copilot Business license.

If a user is removed from all organizations, they will remain in the enterprise as an unaffiliated user unless the remove from enterprise action is taken. Since users may not be automatically removed from your enterprise, we recommend reviewing your offboarding process to ensure it accounts for this change.

Copilot Business licensing updates 💼

Along with enterprise teams and unaffiliated users now being available to all enterprises, updates have been made to Copilot Business licensing. Enterprise owners can use a dedicated Copilot Business licensing page to assign users and enterprise teams. These updates provide more flexible and scalable license management for enterprises, including the ability to assign Copilot Business to users without also requiring a GitHub Enterprise Cloud license.

Join us in the comments below to share your feedback and ask questions. 👇

Learn more

To learn more, check out our documentation on Enterprise Teams, unaffiliated users, and Copilot Business licensing. If you have feedback about these new features, join us on this discussion.

⚠️ Disclaimer: The UI for features in public preview is subject to change.

[rodwill]

Problem: Issues when moving current Copilot Business users to the new Enterprise Teams solution

Context

My Enterprise currently consists of two separate organizations:

• Org A → dedicated only to users licensed under Copilot Business (this org contains only these users).
• Org B → our main organization, which contains all users. In this org, only some of the users have Copilot Enterprise licenses, provisioned via an IdP group.

Steps to Reproduce

1. Org A was used only to assign GitHub Copilot Business licenses.
2. With the new functionality, I created an Enterprise Team, linked it to the EMU/IdP group, and assigned Copilot Business licenses to that Enterprise Team.
3. I removed the license assignment from Org A.
4. At this point, all Copilot Business users lost access to Copilot.
5. I reverted the change: reassigned Copilot Business licenses back to Org A and removed the Enterprise Team.

Expected Behavior

• Users should retain their Copilot Business access when moving license assignment from Org A to the Enterprise Team.
• The license usage report should correctly reflect Business licenses, not Enterprise.

Actual Behavior

• Users lost access to Copilot after the change.
• After reverting, users regained access, but in the GitHub license information it now shows that they are consuming Enterprise licenses instead of Business.

Additional Notes

• The licenses were initially working fine under Org A.
• Org B (main org) already mixes users with and without Copilot Enterprise licenses via IdP group.
• The issue seems to be related to how license consumption is being reported when moving from an org-level assignment (Org A) to an Enterprise Team assignment.

[raymondtiu]

@jmaixl we are looking into this issue. Note that sometimes it might take up to 15 mins for the Copilot license assignment to be completed for an enterprise team. If you remove the organization access before that, it might result in an access gap.

Do you also have this issue besides the access loss?

After reverting, users regained access, but in the GitHub license information it now shows that they are consuming Enterprise licenses instead of Business.

[jmaixl]

Thanks for the follow-up. I didn't wait long before removing the organization access, so I'll try testing this again with a longer wait time.

We do NOT have the same issue where enterprise licenses are being consumed after the revert.

[rodwill]

Hi @rodwill, I am part of the Product team for this launch. Do you mind if I reach out to you by email to help you troubleshoot? If so, I can reach out to the email registered in your GitHub account and continue the conversation.

Hello @raymondtiu , I opened a support ticket in my enterprise account to try to resolve the issue. I also discussed the problem with my Account Manager, and he reached out to your team to provide more detailed feedback.

[raymondtiu]

@rodwill the issue with Enterprise team assignment should be fixed now. I will let you know via your account manager once we found a remedy/solution with the Copilot Enterprise licenses issue.

[yaegashi]

@raymondtiu Our enterprise has encountered a similar issue since the end of last month. We've already filed a support request and hope it will be resolved soon.

Here is the anonymized summary:

In the Enterprise XYZ with Enterprise Managed Users, user_xyz has only a single Copilot Business seat, which is assigned directly from Enterprise XYZ. However, all of this user’s Copilot Features remain Disabled, and they are unable to use Copilot.

Context:

• Enterprise XYZ is using Enterprise Managed Users.
• Enterprise XYZ: All Policies are set to "Let organizations decide".
• Enterprise XYZ: "Policies for enterprise-assigned users" is Enabled.
• Orgs in XYZ: All Policies are set to Enabled.
• user_xyz: Assigned a Copilot Business seat directly from the Enterprise Team (not via any Orgs).
• user_xyz: Belongs to several Orgs, but none of those Orgs assign a Copilot Business seat.

Result:

• user_xyz: Copilot Business seat is assigned only from Enterprise XYZ (confirmed at https://api.github.com/enterprises/xyz/members/user_xyz/copilot).
• user_xyz: All Copilot Features are Disabled (confirmed at https://github.com/settings/copilot/features).

The following screenshot was taken last month from https://github.com/settings/copilot/features

[adcloeshelle]

Is there a way to grant access to individual repos to these Enterprise teams? We would especially like this for Personal Repos - someone in the company creates a POC repo that we don't want in our main Organization, but we also want everyone on the team to easily have access to view it.

[raymondtiu]

@adcloeshelle not exactly what you are looking for but we launched the ability to assign enterprise teams to organizations this week. https://github.blog/changelog/2025-10-23-managing-roles-and-governance-via-enterprise-teams-is-in-public-preview You still need to have the POC repos in a separate org in the enterprise account and you are able to find enterprise teams when you grant access to a repo in the enterprise (just like org teams).

[jmaixl]

Is there any way of disabling notifications when switching to enterprise teams? During a test run, users saying they got emails when adding the enterprise assignment and emails when removing the org-level assignment which was a bit confusing.

[raymondtiu]

Unfortunately we don't have a way to turn off that notification currently. Assignment & unassignment are automatic product emails, and they are not designed to be turn off. I will keep that feedback and see if we can improve this experience in the future.

[omre-cnsp]

Hi,

we use github copilot for Enterprise team, and now, we cannot access to the github copilot plugin. It said disable by admin but we already enable all.

It's a bug of github copilot plugin in IDE (visual studio / intellij) without organisation?

we're blocked and cannot do anything.

Please fix it!!!

[raymondtiu]

@leimerp, is that user member belong to any organization that have Copilot Chat disabled in org policy? You can see which entity is blocking the Copilot chat access from the Copilot page under user's setting.

[leimerp]

@raymondtiu In the user settings of the affected users, nothing indicates that they get blocked by a org policy.

[raymondtiu]

@leimerp You cannot assign Outside collaborators to Copilot business in an enterprise. You might need to first add them to an organization to complete this assignment.

[leimerp]

@raymondtiu Thanks for the information. This is not very intuitive, as you can add outside collaborators to an enterprise team and then assign a Copilot license to an enterprise team.
Due to company governance, it is unfortunately not feasible for us to add outside collaborators as organization members.

[raymondtiu]

Understandable & thanks for the feedback @leimerp. We plan to add some improvements based on your feedback here.

[turqTanza]

I would be happy if I could add the Enterprise Team to the Cost Center.

[affilho]

Is there a way to use these enterprise teams to manage access to GH pages without users consuming licenses?
We have users that will never contribute to any code in the organizations, but they do need read only access to GH pages hosted on those orgs. Currently they consume a license just to be able to view the pages. We are using the EMU instance

[tim-fitzgerald]

I want to surface some very troubling regressions this has introduced. Prior to this rollout all offboarding for Github was fully automated via SCIM. This regression now means that offboarding requires manual steps.

I strongly feel this is an unacceptable change for Github to introduce. Many orgs rely on automated offboarding from an identity provider as a control mechanism to satisfy compliance frameworks. The fact that GH have introduced this change without adequate notification to all administrators has created a huge controls gap.

Gh needs to immediately introduce a means to disable this "Feature" such that users are predictably removed from an Enterperise when they are removed from the child orgs, or introduce an immediate change of scope that allows for full SCIM provisioning at the Enterprise level without EMUs.

[makskustomer]

This is such a negative regression especially for something that can keep users around using a paid license and no way to automate their removal. Im struggling to see the benefits of this change.

[roncanepa-tufts]

This is a completely ridiculous change with poor perceived "benefit" and drastically increased downsides and risks, launched with basically no warning besides a small "aside" in a github blog from a month ago that not very many are likely to have read.

Why are we expected to implement our own automation to replace what SCIM usually did for us (and for very sane and desirable reasons)? You are forcing us admins to reinvent the SCIM wheel for no good reason.

Github needs to revert this immediately. This is poorly conceived, poorly implemented, and should have been vetoed when it was first suggested. Under no circumstances should this have launched as-is and under no circumstances should this be rolled out without the ability to change the setting and for the sane, secure option being the default for that setting.

[tasnyccbs]

I agree with all the frustration with this change that makes absolutely no sense at all. From the enterprise level I don't even think you can see "unaffiliated" users with a copilot license. Even if it did, this change should have never been pushed out especially on a Friday.

[mmacdo02-tufts]

This is a completely backwards change and negates why we are using SCIM provisioning and de-provisioning in the first place. GitHub, in my opinion, should really reconsider this change.

[raymondtiu]

Hi everyone,

We heard your feedback on this change and have rolled out a policy option today that restores the automatic removal behavior. You can now configure your enterprise to automatically remove users when they're removed from all organizations.

I know this has disrupted SCIM-based offboarding workflows and compliance processes you've built over time. We could have handled this rollout better.

The policy setting is available now under Policies > Member Privileges > Unaffiliated users in your enterprise settings. If you enable automatic removal, you'll also have the option to clean up existing unaffiliated users. Full details here: discussion post below

[rgembalik]

Honestly, this shouldn't be default behavior. If I added someone by inviting them to org, they should be removed by removing them from org. Right now we don't even have an option to remove those users from enterprise level UI, even though they are marked as Unaffiliated.

[raymondtiu]

Hi @rgembalik,

We've added a policy option today that lets you restore the automatic removal behavior. When you configure it to remove users automatically, you'll also get the option to remove existing unaffiliated users from your enterprise - so you can clean up the ones that are currently stuck there.

This week has been rough for users workflows that depended on the old behavior, and we could have done better with how we rolled this out.

The setting is under Policies > Member Privileges > Unaffiliated users in your enterprise settings. More details here: discussion post below.

[raymondtiu]

I saw you have an issue with removing the users in your account. I think I know what happened but I would need a support ticket so we can unblock your account.

[rgembalik]

I saw you have an issue with removing the users in your account. I think I know what happened but I would need a support ticket so we can unblock your account.

@raymondtiu Don't worry about it. We decided to cancel the enterprise subscription entirely and mange organizations separately.

[miguelgherrera]

This new “Enterprise Teams” model is a design mistake.

In the previous (and correct) model, removing a user from all organizations automatically removed them from the Enterprise. That behavior made perfect sense for enterprise governance as it ensured that offboarding was complete, auditable, and compliant by default.

Now, with this new design, users can remain inside the Enterprise as "unaffiliated members" even after being removed from every organization. So someone who’s left the company still exists in the Enterprise until someone manually removes them.

That’s not a minor inconvenience, it’s a governance and security regression.

It breaks the fundamentals of what an Enterprise product is supposed to guarantee:

• Automated, deterministic offboarding
• Least-privilege and identity lifecycle control
• Compliance (ISO 27001, SOC 2, DORA, etc.)

Offboarding isn’t “nice to have”, it’s one of the reasons we pay for an Enterprise subscription. Enterprises shouldn’t need to manually audit and purge users just to stay compliant. This change adds operational risk and undermines the whole purpose of SSO and SCIM integration: a single source of truth for identity.

Please, revert this behavior or at least make it optional. Offboarding should remain automatic when a user no longer belongs to any organization.

Whoever approved this clearly didn’t think about real-world governance requirements.

[raymondtiu]

Hi @miguelgherrera,

We heard this feedback and have rolled out a policy option today that restores the automatic removal behavior. You can now configure your enterprise to automatically remove users when they're removed from all organizations - the same way it worked before.

I know this change has impacted your offboarding processes this week, and we could have handled this rollout better.

The new policy setting is available now under Policies > Member Privileges > Unaffiliated users in your enterprise settings. Details on how to configure it are here: discussion post below

[rgembalik]

Did anyone figure out how to actually remove Unaffiliated users from the UI? Our enterprise owners do not have such option.

• The docs mention three dots dropdown menu on each enterprise user - we don't have it -,
• feature preview menu under my profile doesn't have anything that would allow us to enable this feature, so it doesn't look like some option is disabled by being in preview,
• the list of users in enterprise (including unaffiliated ones) have checkbox near each name without an option do do anything with them,
• the enterprise teams page just shows default screen that encourages to create new enterprise team

[rgembalik]

Huh, so that means only our enterprise is bugged? I'm listed as owner, so I doubt it's permissions issue.

[roncanepa-tufts]

Huh, so that means only our enterprise is bugged? I'm listed as owner, so I doubt it's permissions issue.

It could be, but that does seems strange. Are you using enterprised-managed users ("EMU")? The same popup mentioned to me that EMUs can't be removed. We're not using EMUs and so that might be one difference between our environments.

[rgembalik]

@roncanepa-tufts They were created outside of our orgs and invited to one of them. At no point they were added at enterprise level. We also don't have any auth integration. Unless I misunderstood what makes user an EMU, I doubt they are enterprise-managed. Not to mention, we cannot see this menu for any user.

[roncanepa-tufts]

@rgembalik EMUs are a whole specific thing, where Github vends the new account:
https://docs.github.com/en/enterprise-cloud@latest/admin/concepts/identity-and-access-management/enterprise-managed-users

So if the accounts existed previously and then were invited to join, it sounds like you don't have EMUs. Which means that, as weird as it seems, maybe your enterprise is somehow bugged or the rollout of the "preview feature" (ugh) is incomplete?

[raymondtiu]

@rgembalik would you mind to file a support ticket so we can take a deeper look at your account? I have already filed this as a potential bug and the team will investigate and see why you can't see the member options. If you already did, let me know and I can find that ticket from the system to attach to our bug report.

[jth0]

This introduces a security flaw, it is not a feature. If someone has a need for this and wants to enable it, build this so they can opt in. And you've forced all ENTERPRISE and BUSINESS, PAYING customers into this model, for a "Public Preview" feature? Insane.

I should not need to go write some utility to hit your API to restore functionality I had in place, and I really, absolutely should not need to add manual steps to my offboarding procedures.

WTH were you thinking with this change?

[raymondtiu]

Hi @jth0,

We heard this feedback and rolled out a policy option today that addresses it. You can now configure your enterprise to automatically remove users when they lose organization access - restoring the previous behavior.

I know this has been disruptive to your workflows this week, and we could have handled this rollout better.

Details on how to set it up are here: discussion post below

The setting is available now under Policies > Member Privileges > Unaffiliated users in your enterprise settings.

[chkp-roniz]

Enterprise Teams + Premium Request Budgets: Two Blockers for a GHCP-Only Enterprise

Hi! We’re using a GHCP-only enterprise (no orgs/repos) alongside a SCIM/EMU enterprise for GitHub (orgs/repos). Two related issues are slowing our rollout/merge:

---

1. Billing / Cost Controls for Premium Requests

What we need: Enable the "Premium request paid usage" policy for only specific cost centers, with a default-deny/catch-all that automatically blocks paid usage for everyone else (no scripts or manual updates).

Why: Only select cost centers are approved for paid premium-request spend; everyone else should be blocked by default. In a GHCP-only enterprise (no orgs), we’d love a team → cost center mapping so budgets follow membership.

Asks / Ideas:

• Allow scoping the paid-usage policy by cost center or enterprise team (allow-list), with a default block for all others.
• Add a first-class “catch-all budget” that automatically covers any user not matched by a more specific budget.
• In GHCP-only enterprises, support enterprise team ↔ cost center binding so budgets are automatic, not programmatic.

---

2. Managing Users at Scale (Enterprise Teams Limits)

We’re moving multiple estates into a new EMU enterprise. One legacy GHCP-only enterprise has over a thousand GHCP-only users who don’t need GitHub repos. We want to assign GHCP directly via Enterprise Teams as documented, but hit current limits.

Blocker: Enterprise Teams are limited to 50 teams per enterprise and 500 users per team. Sharding one identity group across many teams is operationally painful.

Asks / Ideas:

• Raise (or remove) the per-team member limit for licensing scenarios.
• Support assigning GHCP to an IdP group directly at the enterprise level (no team).
• Provide a “mega-team” or group-of-groups construct specifically for licensing at scale.

---

Open Questions

• For GHCP-only enterprises (no orgs), is there a supported “default block + allow by cost center” pattern without custom automation?
• Any timeline to increase Enterprise Teams limits for large rollouts?

Happy to share more details if helpful. Thanks!

[erikaxu]

Thank you for this feedback. I've already shared this internally to help inform the appropriate teams.

With regards to the Enterprise Teams limits, I don't have a good timeline for the next increase at this time. However, I did want to highlight that additional enterprise team capabilities released yesterday and that included a change in some of the limits. Enterprises can now have 100 enterprise teams with 500 users per team assigned cross 1000 organizations.

[raymondtiu]

Hi everyone,

Thank you for your feedback on those changes and the impact on your offboarding processes. We heard your concerns and have made updates to address them.

What we've done:
We've added a new policy option that gives you control over what happens when organization access is revoked and users become unaffiliated. You can now choose between two options:

1. Users remain in the enterprise as unaffiliated users (current default)
2. Users are automatically removed from the enterprise (previous default behavior)

For those of you who rely on organization removal to fully offboard users, setting this to option 2 restores the original automated behavior you had before.

How to configure this:

1. In the top-right corner of GitHub, click your profile picture
2. Depending on your environment, click Enterprise, or click Enterprises then click the enterprise you want to view
3. At the top of the page, click Policies
4. In the left sidebar, click Member privileges
5. Under "Unaffiliated user", choose your setting for the policy

Additional option:

When you select option 2 "Users are automatically removed from the enterprise", you'll also have the option to remove any existing unaffiliated users. This will remove them from enterprise teams and revoke their enterprise-level Copilot licenses.

We know this transition has been disruptive to workflows you've built and rely on. Our team is actively working on expanding user management capabilities at the enterprise level, and we appreciate your patience as we roll out these improvements.

[roncanepa-tufts]

@tasnyccbs So far so good for us here, although I don't know what our churn rate is, either, to know whether we're truly in the clear yet.

[raymondtiu]

@tasnyccbs, we noticed that in some situations, there's a timing issue when you remove a user from multiple org (almost) simultaneously. Our current logic checks if a user is still in any org and the timing issue causes the check to respond "yes the user still has other orgs" to all the org removal. We are working on an orchestrator to mitigate this timing issue.

[tasnyccbs]

A user is still lingering as unaffiliated and will keep it there to help troubleshoot.
I will have a much better idea if this works or not within the next 2 days .. that is if I survive the cuts...

[raymondtiu]

You can remove that unaffiliated user from the account on the People page, we have enough data points to help us troubleshoot. Sorry to hear that and 🫂.

[tasnyccbs]

Unfortunately we had many layoffs this past week and I just want to state that even though we have Unaffiliated users - Remove from the Enterprise set we are still getting Unaffiliated users (39 users) for some reason.
I can't confirm the total amount of users that had github accounts that should have been removed via Okta SCIM but it does seem like it was more than 39 users comparing our license counts.
I am not sure what variables are causing some to be fully removed and some to be placed as Unaffiliated users.
Is anyone else seeing the same issues we are?
We do NOT use EMU ( converting would have been a major headache with everyone having to regenerate ssh keys) and use Okta with SCIM enabled to remove the users from Github once they get removed from Okta.

Thank you

[Isychan1]

🆕 GitHub Enterprise Cloud now offers Enterprise Teams in public preview, streamlining enterprise user and Copilot license management experiences for businesses.

Enterprise owners can now:

• Add users directly to the enterprise without requiring organization access. These unaffiliated users do not consume a license by default.
• Create and manage groups of users in the enterprise account through Enterprise Teams.
• Enterprise accounts with Enterprise Managed Users can synchronize groups of users from their identity provider to Enterprise Teams via SCIM.
• Manage Copilot Business licenses for individuals or entire enterprise teams through the enterprise-level Copilot licensing page.

---

What Enterprise Teams enable ❓

In the coming months, enterprise owners will also be able to use enterprise teams to:

• Assign an enterprise role.
• Assign it to a number of organizations within that enterprise, granting organization membership.
• Empower organization and repository owners to assign roles to teams within their scope.

Unaffiliated users (non-EMU enterprises) 👀

For enterprises that do not use enterprise-managed users (EMU), enterprise owners can now invite unaffiliated users to their enterprise. These users will not have access to organizations or licenses by default, but can later be assigned to an enterprise team, an organization, or Copilot Business license.

If a user is removed from all organizations, they will remain in the enterprise as an unaffiliated user unless the remove from enterprise action is taken. Since users may not be automatically removed from your enterprise, we recommend reviewing your offboarding process to ensure it accounts for this change.

Copilot Business licensing updates 💼

Along with enterprise teams and unaffiliated users now being available to all enterprises, updates have been made to Copilot Business licensing. Enterprise owners can use a dedicated Copilot Business licensing page to assign users and enterprise teams. These updates provide more flexible and scalable license management for enterprises, including the ability to assign Copilot Business to users without also requiring a GitHub Enterprise Cloud license.

Join us in the comments below to share your feedback and ask questions. 👇

Learn more

To learn more, check out our documentation on Enterprise Teams, unaffiliated users, and Copilot Business licensing. If you have feedback about these new features, join us on this discussion.

⚠️ Disclaimer: The UI for features in public preview is subject to change.

[MeganCullins-grmn]

This is a great new feature that will really help my company manage our Copilot-only licenses versus the developer licenses needed. Currently, however, it appears that the Copilot policy shown in the attachment does two things:

1. It is necessary for the Enterprise Teams to assign licenses in the first place
2. Makes the default policy enabled for all Copilot policies otherwise not explicitly denied.

This causes issues when, for security purposes, my company likes to enable new policies in a "testing" Organization under our Enterprise and test them before rolling them out to the wider company. Tying these two enabled functions together means that we are no longer able to enable other policies (IE "Spark", "MCP servers in Copilot", and any newly rolled out feature before we can change the policy from "No policy") at an Organization level for testing and disable for the Enterprise Teams.

The ask: Would GitHub be able to separate the “Enterprise-assigned users receive licenses directly from enterprise, not through organizations” part from the “If enabled, enterprise-assigned users default to enabled for any policies set to ‘No policy’” part?

[raymondtiu]

I am trying to understand your use case so please let me know if I am reading it wrong.

The objective of this policy "Policies for enterprise-assigned users" is to fill the gap when the enterprise level set a policy to "No policy" and enterprise level assignments won't have any organization policy to defer to.

In your example, are you looking for 4 options for every single policy in the enterprise setting instead of having this one to default to all cases? Something like,

1. Enable for the entire enterprise, including enterprise level assignment
2. Disable for the entire enterprise, including enterprise level assignment
3. Enable for enterprise level assignment. Organization level assignment will defer to the respective org policy.
4. Disable for enterprise level assignment. Organization level assignment will defer to the respective org policy.

[raymondtiu]

Would GitHub be able to separate the “Enterprise-assigned users receive licenses directly from enterprise, not through organizations” part from the “If enabled, enterprise-assigned users default to enabled for any policies set to ‘No policy’” part?

Makes the default policy enabled for all Copilot policies otherwise not explicitly denied.

To clarify, this policy will only apply when a certain policy is set to "No Policy". If you enable a policy at the enterprise level, any Copilot users will be allowed to access that feature and the "Policies for enterprise-assigned users" won't apply.

[MeganCullins-grmn]

Not necessarily 4 options for every single policy, no. Instead, 2 Enterprise level policies:
Policy 1:

1. Enable Enterprise level Teams Copilot license assignment
2. Disable Enterprise level Teams Copilot license assignment
   Policy 2 (which is what the policy wording says the purpose is today):
3. When the Enterprise level sets a policy to "No policy" default the Enterprise level Teams to "Disabled"
4. When the Enterprise level sets a policy to "No policy" default the Enterprise level Teams to "Enabled"

This is because currently the Enterprise level Teams will NOT assign/activate a Copilot license AT ALL unless this SPECIFIC policy also defaults to Enabled. If this current policy is Disabled, users in the Enterprise Team do not have Copilot functionality and receive the attached error. To also confirm, the policy for GitHub in the UI is "Enabled everywhere", not "No policy", so it is expected that users in Enterprise level Teams WOULD be able to use GitHub in the UI, however they are not able to.

[MeganCullins-grmn]

Just an update. I see that this feature is now in GA. Due to that, I went and attempted to re-create the issue I reported here, experienced originally on Oct. 20th. Today, it does NOT seem to occur any longer, so I retract my previous suggestion. This now appears to be working as desired for my Enterprise.

[raymondtiu]

@MeganCullins-grmn thanks for reconfirming!