GitHub Code Quality Gets Organization-Level Enablement

GitHub added organization-level enablement for GitHub Code Quality on June 16, 2026. Engineering and platform teams that manage multiple repositories can now enable or disable Code Quality across an entire organization from a single settings page, rather than configuring it per repository. The feature is available in public preview for GitHub Enterprise Cloud and GitHub Team plans.

Source: GitHub Changelog, June 16, 2026. Published June 18, 2026.

What Changed

A new “Code quality” section is now available in GitHub organization settings under Security. From this page, organization administrators can turn GitHub Code Quality on or off for all existing repositories in the organization in a single action. Previously, enabling Code Quality required configuring it per repository.

According to GitHub, the feature is currently in public preview for GitHub Enterprise Cloud and GitHub Team plans. It is not available for GitHub Enterprise Server.

What This Changes in Practice

For engineering teams managing more than a handful of active repositories, per-repo configuration of Code Quality creates the kind of inconsistency that compounds over time: some repos are covered, some are not, and gaps get discovered during pull request review rather than earlier in the development process. New repositories often start without Code Quality enabled because it is an extra step that gets missed in setup.

Org-level enablement removes that category of setup gap. An admin can apply a consistent baseline to all existing repositories in one action. That is most useful for teams where Code Quality is already part of the engineering standard and the goal is coverage completeness — not piloting the feature on select repos for the first time.

If your team is also evaluating GitHub’s AI-powered tooling, see our overview of GitHub Copilot’s individual plan structure for recent changes to per-user AI usage billing.

Before Turning It On Organization-Wide

The ability to enable Code Quality across all repositories in one action is also the reason to think before doing it. A few steps worth taking first:

• Verify eligibility and preview status: Confirm your plan is GitHub Enterprise Cloud or GitHub Team. Because this is in public preview, behavior may still change.
• Audit your repository inventory: Not all repos benefit equally. Generated-code repositories, archived projects, prototypes, and legacy codebases may produce noisy findings that obscure more relevant signal in active production services. Consider whether org-wide enablement makes sense or whether a subset of repositories is a better starting point.
• Define triage ownership before findings appear: Enabling Code Quality across many repositories at once can surface a large volume of results in pull requests. Decide in advance which findings block work, which are advisory, and who handles disputes about false positives or low-priority issues. Spreading findings without a triage process adds review overhead without improving code quality outcomes.

Who Should Care

Organization administrators on GitHub Enterprise Cloud or GitHub Team plans who already use or are actively planning to adopt GitHub Code Quality, and who manage several active repositories, will find this the most immediately useful. For those teams, it replaces a manual rollout process with a single admin action and reduces the chance of uneven coverage across the codebase.

Solo developers, teams with one repository, and engineering teams already running code quality analysis through a separate CI pipeline or static analysis stack can likely skip this update. Organizations on GitHub Enterprise Server do not currently have access to GitHub Code Quality at all.

See also: Best AI Coding Agents for Small Teams: Practical Picks for Solo Builders.