Hosted-runner usage on GitHub Actions is no longer an implicit allowlist at the organization level. Per the June 25 changelog, admins can now disable the standard labels for hosted runners such as ubuntu-latest, and add macOS runners to runner groups with access, concurrency and routing controls. For platform teams, the operational consequence is concrete: the default runner pool stops being something workflows can fall through to by accident.

The release pairs two separate controls under one banner. The first is a new "Standard hosted runner setting" with a "Disable for all repositories" checkbox, which switches off the default labels at the org level. The second is a set of group-level controls aimed at macOS: limits on which organizations, repositories and workflows can reach a macOS runner, concurrency caps on macOS jobs, and routing by referencing runner groups by name in workflow YAML. The macOS half is restricted to Team and Enterprise plans, per the post.

What disabling ubuntu-latest actually does

Before this change, a workflow that wrote runs-on: ubuntu-latest would always find a runner. The label is the GitHub-managed catch-all that points at whatever the current default Ubuntu image is. After the toggle, that label stops resolving at the org level. A workflow that asks for it gets nothing, and the platform team decides what runners are reachable instead. The intended replacement is a curated pool, whether that is GitHub's larger runners, custom images, or a runner group reference.

The admin surface lives in Settings, under the hosted runner controls. The changelog ties this to the existing runner-groups documentation rather than introducing a parallel concept.

The catalogue becomes the policy

A standard-label allowlist is the kind of switch platform teams have been simulating with policy bots and merge-time YAML scans. None of those handle the failure mode that actually matters: a developer writes runs-on: ubuntu-latest and bypasses whatever hardened image the platform team has been investing in. Once the label is off at the org, the path of least resistance changes. Workflows have to name a runner that exists in the org's catalogue, which makes the catalogue itself the policy.

Rollback is shallow. The checkbox flips back, and ubuntu-latest resolves again. The toil cost lands earlier, in the catalogue. Every job that previously implied a default now has to declare a runner the platform team is willing to vouch for, and somebody has to keep that list alive.

Caveats in the release text

Two caveats sit in the post itself. The macOS controls are gated to Team and Enterprise plans, so smaller organizations do not see them. Network configurations are not supported for macOS runners at this time, per the changelog, which leaves macOS jobs out of the egress-controlled networking story that other hosted runners can join.

The release does not enumerate which other standard labels the toggle covers, and it does not name a default state for organizations that ignore the setting. The screenshot example names ubuntu-latest. The prose says "such as," and stops there. Treating anything beyond that as undocumented is the safer read until the docs catch up.

What lands on the platform team's plate

The work after this rolls out is the unglamorous part: an audit of every workflow that hard-codes ubuntu-latest, a migration plan to a named runner pool, and a deprecation window before the toggle flips. The lever now exists. The catalogue still has to be built.