macOS 14 Runners Retire and Intel Is Missing

GitHub published the macOS 14 runner image retirement notice on 1 October 2026. Three labels go away: macos-14, macos-14-large and macos-14-xlarge. The stated reason is the standard one — the runner-images project supports the latest two macOS versions, and macOS 26 and 15 are both GA.

The retirement is routine. The migration advice has a hole in it.

The replacement list is arm64 only

Here is what the changelog tells you to move to, verbatim: "Update your workflow files to use one of the following macOS arm64 labels: macos-latest (macos-26), macos-15, macos-latest-xlarge (macos-26-xlarge), or macos-15-xlarge."

Four labels, all arm64, and the word x64 does not appear anywhere in the entry. But of the three labels being retired, one is Intel. The -large suffix on GitHub's macOS runners means x64, not simply "bigger" — which is itself a naming decision worth complaining about, and the reason this gap is easy to walk into.

GitHub's workflow syntax reference documents macos-15-intel and macos-26-intel as x64 images, and the runner-images repository lists both as GA alongside their -large aliases. So Intel macOS builds are not going away on 2 November. The people most at risk are the ones who do exactly what the notice says.

Why a silent arch switch is worse than a failure

If your job just compiles Swift and runs tests, moving from x64 to arm64 costs you nothing and probably runs faster. Plenty of macOS CI is that simple, and for those repos this whole article is a two-character edit.

The problem is the jobs where architecture is the point. A release workflow that produces an x86_64 binary and ships it. A Homebrew bottle build. Anything that prebuilds native Node modules, Python wheels or Rust artefacts for Intel Macs. A test matrix whose entire purpose is to prove the product still works on Intel hardware. Any of these can migrate to an arm64 label, pass green, and produce the wrong artefact — or stop testing the thing it was built to test — without a single red check to tell you.

A build that breaks loudly is a ticket. A build that quietly changes what it produces is a support thread three weeks later from a user on a 2019 MacBook Pro. If you ship binaries to end users, go and read the runs-on line in your release workflow before the first brownout, not after.

The brownouts are the real deadline

2 November is when the labels stop working. October is when they stop working intermittently, which is harder to diagnose and starts in two days. The changelog lists eight windows, each running 14:00 UTC to 00:00 UTC the next day:

Note the last two are back to back, so the end of the month is effectively a continuous outage for these labels. Note also that 14:00 UTC is mid-morning in the US and early evening in India, which means for a lot of teams the brownout lands squarely on the working day rather than on an overnight cron. If you run scheduled nightly jobs in UTC, they may sail through every window and give you false confidence until 2 November.

If you need Intel for the long run, plan for it

The two-version support window is the thing to internalise. macOS 14 is being retired because 26 and 15 are both GA; when the next macOS reaches GA, macOS 15 goes the same way, and macos-15-intel goes with it. At that point your x64 capacity depends entirely on GitHub continuing to publish an -intel image for each new release.

GitHub documents that image for macOS 15 and macOS 26. It has not committed to one beyond that, and nothing in the retirement notice suggests it intends to discuss the subject. Treat hosted Intel macOS as a supported-today, unplanned-tomorrow dependency.

Practically that means two things. First, write down why each Intel job exists, in a comment on the runs-on line, because in a year the person reading it will not know whether the label was a requirement or an accident. Second, if shipping x86_64 Mac binaries is load-bearing for your product, start pricing a self-hosted mac mini or a managed macOS CI provider now, while it is a planning exercise rather than a migration under a deadline. Universal binaries built on arm64 solve this for some projects and not for the ones that need to run a real test suite on real Intel silicon.

Find every reference, not just the obvious ones

Grepping .github/workflows for macos-14 catches most of it and misses the awkward cases. Check reusable workflows in other repositories that your workflows call. Check composite actions you maintain. Check matrix definitions where the label is assembled from variables, which grep will not find. Check any runs-on value that comes from a repository or organisation variable.

Then decide per job, not per repo. The question is only ever: does this job care what CPU it runs on? If yes, move it to macos-15-intel or macos-26-intel and keep the architecture explicit in the label so the next person can see the intent. If no, take macos-latest and stop thinking about it.

This is the third Actions deadline in a short stretch, and they interact. ubuntu-latest is moving to Ubuntu 26.04 across a window that overlaps this one — we covered what breaks in the ubuntu-latest migration. The default block on pull_request_target in public repos lands in the same stretch, which we wrote up in the pull_request_target change. If you are touching workflow files anyway, do all three in one pass rather than three separate incidents.

While you are in there: the -large labels are billed differently from the standard ones, so a migration is also a cost change. Working out whether a build genuinely needs the paid tier is the kind of thing worth an afternoon. Our guide to comparing developer tools applies to runner tiers as much as to products, and the cloud and DevOps category has the alternatives if you are weighing self-hosted macOS capacity instead. For the mechanical parts — diffing two workflow files, checking YAML — the text diff checker and YAML to JSON converter are free and in the browser.

FAQ

Are Intel macOS runners being removed?

No. macos-14-large is x64 and it is being retired, but macos-15-intel and macos-26-intel remain available and are documented as GA. The retirement notice simply does not list them among the recommended replacements.

What does macos-latest point to now?

macos-26, which is arm64. macos-latest-xlarge maps to macos-26-xlarge, also arm64. If you need x64 you have to name an Intel label explicitly; no "latest" alias will give it to you.

What happens during a brownout?

Jobs targeting the retiring labels fail for the duration of the window, then work again. Each window runs roughly ten hours, from 14:00 UTC to 00:00 UTC the following day. The purpose is to surface the dependency before the hard cutoff.

When exactly do the macOS 14 labels stop working?

2 November 2026, per GitHub's changelog. The eight October brownout windows are scheduled before that: 5, 12, 16, 19, 23, 26, 29 and 30 October.

Will my build break if it moves from x64 to arm64?

Often not, and that is the risk. Compile-and-test workflows usually just work. Jobs that produce distributable binaries, prebuild native modules or exist specifically to test Intel compatibility can pass green while producing the wrong output.

Why is macOS 14 being retired at all?

The runner-images project states it supports only the latest two macOS versions. With macOS 26 and macOS 15 both GA, macOS 14 falls out of that window and is marked deprecated ahead of removal.

Dates and labels taken from GitHub's 1 October 2026 changelog, the Actions workflow syntax reference and the runner-images repository, checked on 3 October 2026.