GitHub is scheduled to retire the macOS 14 images used by GitHub Actions on November 2, 2026. The change affects workflows that request macos-14, macos-14-large, or macos-14-xlarge. Teams should identify those references, select a supported macOS arm64 image, and test their builds before the retirement date.
The migration is not necessarily a drop-in image replacement. GitHub’s published runner-image documentation shows differences in operating-system versions, Xcode, language runtimes, compilers, SDKs, and other installed tools between available macOS images. Those differences can affect builds even when the workflow file itself needs only a label change.
What changed in GitHub Actions
According to GitHub’s retirement announcement, the macOS 14 GitHub-hosted runner image will be retired on November 2, 2026. The affected labels are:
macos-14macos-14-largemacos-14-xlarge
GitHub has also announced eight brownout periods before retirement. Jobs using the affected labels may temporarily fail during these windows:
- October 5, 2026
- October 12, 2026
- October 16, 2026
- October 19, 2026
- October 23, 2026
- October 26, 2026
- October 29, 2026
- October 30, 2026
Each brownout is scheduled to begin at 14:00 UTC and end at 00:00 UTC the following day. GitHub may also reduce macOS 14 capacity before retirement, which can increase queue times for jobs using the affected labels.
Which runner labels can replace macOS 14?
GitHub lists macos-latest, macos-15, macos-latest-xlarge, and macos-15-xlarge as macOS arm64 replacement labels. The retirement announcement identifies macos-latest as macOS 26 and macos-latest-xlarge as macOS 26-xlarge.
That means teams have a choice between labels that track the latest supported image and labels that name a specific macOS version. The supplied announcement does not establish that any replacement is compatible with every existing workflow, so the right choice depends on the tools and dependencies used by each build.
The actions/runner-images repository is the maintained reference for available images, image releases, installed software, and support information. Its image-specific documentation should be checked before and during migration because the listed software versions are snapshots that can change as images are updated.
Why the migration requires testing
The available arm64 images do not contain identical environments. In the supplied documentation snapshot, the macOS 15 arm64 README documents macOS 15.7.9, Node.js 22.23.2, Python 3.14.7, Ruby 3.3.12, and Xcode 16.4 as the default Xcode version.
The macOS 26 arm64 README documents macOS 26.6.2, Node.js 24.20.0, Python 3.14.7, Ruby 3.4.10, and Xcode 26.6 as the default Xcode version in its supplied snapshot. The documentation also shows differences involving tools such as Clang or LLVM, OpenSSL, Xcode, and the default macOS SDK.
These differences demonstrate that a runner-image change can alter the build environment, but they do not prove that a particular workflow will fail. The impact will depend on the workflow’s dependencies, compiler and SDK requirements, Apple-platform build configuration, signing process, and use of preinstalled tools. The supplied sources do not provide compatibility guarantees for individual projects.
How to find affected workflows
Start by searching workflow files for the three retiring labels: macos-14, macos-14-large, and macos-14-xlarge. Review reusable workflows and repository-specific workflow files wherever runner selection may be defined.
GitHub’s workflow REST API reference can list workflows for a specified repository and return metadata such as workflow names, file paths, states, and timestamps. That endpoint is useful for enumerating files that need review, but it does not itself search workflow contents or identify every macOS 14 label across an organization. Additional repository inspection is required.
Administrators managing multiple repositories should therefore treat workflow enumeration and content search as separate tasks. Finding every affected reference may require reviewing each repository’s workflow files rather than relying on the workflow-list endpoint alone.
What you should do before November 2
- Inventory runner labels. Search workflow files for all three macOS 14 labels, including workflows that may be maintained in repositories outside the primary application repository.
- Choose a replacement deliberately. Select from the labels listed by GitHub, such as
macos-15,macos-latest,macos-15-xlarge, ormacos-latest-xlarge, based on the workflow’s compatibility and capacity requirements. - Compare the image contents. Check the current runner-image README for the selected image, paying particular attention to Xcode, SDKs, language runtimes, compilers, package managers, and other tools used by the build.
- Run the workflow on the replacement image. Validate installation, compilation, tests, packaging, signing, and any deployment-related steps that depend on the runner environment. Do not assume that an image label change alone proves compatibility.
- Test before the brownouts. Complete validation before the October brownout dates so that intermittent failures or longer queues on macOS 14 do not become the first indication of an incomplete migration.
- Track image changes. Continue checking the runner-images repository for updated image contents and releases after the initial migration.
Availability and remaining uncertainty
The retirement is an announced future change; it is not described as having already occurred. Jobs using the affected labels may fail during the October brownouts, and reduced capacity may increase queue times before November 2.
GitHub’s supplied announcement and supporting documentation do not specify the exact error or failure behavior for every workflow that still references macOS 14 after retirement. Workflows that remain on those labels may no longer run as expected, but the precise post-retirement behavior is undocumented in the available material.
The documented differences between macOS 15 arm64 and macOS 26 arm64 are also not a complete migration checklist. They indicate why testing is necessary, not that a particular dependency, signing configuration, or community action will fail. No supplied source establishes plan eligibility, billing effects, or a specific security impact from this image retirement.
