GitHub Enterprise Server 3.22: Copilot CLI for Air-Gapped Environments and More

GitHub Enterprise Server (GHES) 3.22 is now generally available as of September 8, 2026. The release brings Copilot CLI support for air-gapped (disconnected) enterprise environments, promotes enterprise teams to general availability after a public preview period, and adds more granular ruleset bypass controls, required reviewer rules, and several developer workflow improvements across repositories and issues.

What happened

Feature	Status in 3.22
Copilot CLI for air-gapped environments	Technical preview
Enterprise teams	Generally available (was public preview)
Ruleset bypass by individual user	Generally available
Required reviewers ruleset rule	Generally available
Secret scanning request sorting by date	Generally available
Release status badge in issue sidebar	Generally available
Contributor role labels in PR list view	Generally available (public repos)

The headline feature: Copilot CLI in disconnected environments

Many regulated industries run GitHub Enterprise Server in air-gapped setups, where servers have no outbound connection to GitHub Cloud. Until now, Copilot CLI simply did not work in those environments. With 3.22, an administrator can configure a model provider once inside GHES, and every user across the enterprise can then run Copilot CLI with their existing GHES credentials, no cloud connectivity required.

The catch: this is a technical preview, meaning the interface and behavior can change before it reaches GA. Teams that depend on it for production workflows should treat it accordingly and watch the release notes closely.

Enterprise teams: centralized access management is now GA

Enterprise teams graduated from public preview to general availability. The feature lets enterprise owners build a single team structure that spans every organization and repository inside the enterprise. Previously, access management had to be handled organization by organization, which created overhead as the number of orgs grew. A centralized team hierarchy cuts that repetition significantly.

What changed for repository rulesets?

Two ruleset improvements ship in 3.22 that give administrators finer control without forcing them to create extra roles or teams.

• Bypass by individual user. Administrators can now add a single service account (or any specific user) to a ruleset bypass list. Before this, bypass permissions required creating a dedicated role or team just to cover that one account.
• Required reviewers rule. Organization owners and repository administrators can now mandate sign-off from specific teams on targeted branches, files, or folders using pattern matching. For example: require the data platform team to review every *.sql change, or require the security team on the default branch. The rule works alongside existing CODEOWNERS files and sets a minimum number of reviews per team.

This is useful for teams where QA, security, or design need a formal sign-off that sits outside the usual code ownership model. For teams managing web development projects at scale, this kind of enforced review structure reduces the chance of sensitive changes slipping through without the right eyes on them.

Smaller but practical quality-of-life changes

Secret scanning sort order. Security analysts reviewing push protection bypass requests or alert dismissal requests can now sort those queues by date, ascending or descending, at the repository, organization, or enterprise level. Previously the sort order was fixed, making it hard to prioritize when volumes were high.

Release status in the issue sidebar. When a pull request linked to an issue has been included in a release, the issue sidebar now shows a “Latest release” or “Pre-release” badge. Developers no longer have to leave the issue to confirm whether a fix has actually shipped.

Contributor role labels in PR list view. Public repository maintainers can now see labels like “First-time contributor,” “Contributor,” or “Member” directly in the pull request list, without opening each PR individually. It is a small change, but it saves real time for busy open-source maintainers.

Why it matters

Copilot CLI in air-gapped environments is the most significant addition for enterprise teams in regulated sectors (finance, government, healthcare) that cannot connect internal tooling to external cloud services. It extends AI-assisted development to environments that were previously excluded entirely.

The ruleset improvements matter for any team trying to enforce compliance or quality gates without ballooning their team and role structures. Combining bypass by user with required reviewers gives administrators a precise toolkit rather than blunt, org-wide controls.

For teams already using GitHub Enterprise, the upgrade path is available now. If you are exploring how AI coding tools fit into your broader AI integration strategy, Copilot CLI in air-gapped mode is worth tracking even at technical preview.

Our take

The air-gapped Copilot CLI feature is the kind of unglamorous, hard-to-demo work that actually matters in enterprise software. Most organizations we talk to that run self-hosted GitHub do so precisely because they cannot or will not send code to external services. Blocking Copilot entirely was a real cost. Technical preview is an honest label, though: we would wait for GA before building a workflow dependency on it.

The required reviewers ruleset rule is genuinely useful and fills a gap that CODEOWNERS alone could not cover. Being able to target *.sql files or feature branches with a minimum review count, without creating shadow teams just for enforcement, is the kind of specificity that makes governance practical rather than performative.

If you are evaluating whether GHES fits your team’s workflow or want help thinking through an upgrade, the Lumien team is happy to talk through the specifics.

Source: GitHub Changelog