Still shipping an Intel build

The last macOS for Intel.

Apple moved the Mac to its own chips in 2020, and the Intel line has been winding down since. In June 2025 the date became concrete. As PetaPixel reported from WWDC, “macOS 26, also known as macOS Tahoe 26, will be the last release that supports Intel-based Macs.”

In April 2026 The FPS Review put it more bluntly: “Apple is ditching support for its Intel-based machines as of next year's OS release.” The Intel Macs that got Tahoe at all were a short list, including the 16-inch MacBook Pro from 2019 and the 27-inch iMac from 2020.

Then it happened. Apple's page macOS 27 Golden Gate is compatible with these computers lists only Apple silicon models and says: “If you have a Mac with Apple silicon, you can upgrade to macOS 27.” On 14 September 2026, The Eclectic Light Company reported the release: it “requires an Apple silicon Mac, including the MacBook Neo, and still includes Rosetta 2”. The same day Tahoe went to 26.7, “starting its first two years of security-only support”.

Old Macs still write code.

An Intel MacBook Pro from 2019 does not stop compiling when Apple stops shipping it new operating systems. Plenty of developers keep one as a second machine, a build box, or simply their laptop. Luminair runs agents on the Mac you already have, so dropping Intel would mean telling those people to buy a new computer to use a chat window.

So the download page still has two Mac buttons. The site's download script lists an Intel row with the note Older Macs, next to Apple Silicon, and when the browser reports an x86 processor it switches the main Mac button to the Intel file for you.

Keeping a second architecture costs more than a second button, though. Every release has to produce a second signed, notarized app, and every piece of native code inside it has to be the right kind. Luminair bundles real programs, not just JavaScript: the Claude and Codex command-line engines, a terminal library (node-pty), a clipboard helper. Each has a separate build for arm64 and for x64. Put the wrong one in the box and the app opens fine, then fails the moment you ask it to do anything.

npm did exactly what it was told.

Luminair's release workflow was redesigned on 3 September 2026 around one rule, written at the top of the file: “Intel builds on an Intel runner, Apple Silicon on arm64. No cross-arch force-installs.” GitHub's hosted Intel Mac runner built the Intel app, and GitHub's hosted Apple silicon runner built the other.

Hosted Mac runners are expensive, though. The workflow's own input description says forcing the Mac lanes onto them “costs 10x minutes”. We also had a Mac of our own, registered as a self-hosted runner. So at 06:41 on 6 September, commit 9a6e5ab2 sent both Mac lanes to that Mac when it was online: “arm64 native, x64 via Rosetta; 0 hosted minutes”.

That Mac was Apple silicon. Here is what happened next, step by step:

That probe was added on 1 September for a different bug: in a packaged app, turns on an in-app sign-in had died with “spawn ENOTDIR”. It was written for that failure, and it caught this one.

The fix landed 39 minutes after the change that caused it. It keeps the gate on the host's native modules, then reinstalls the tree for the target machine before packaging:

if [ "$(uname -m)" = "arm64" ]; then
  # The gate above ran on the host's native (arm64) modules. The PACKAGED app must carry the x64
  # variants of every platform-specific optional dependency, or the Intel app has no bundled engines.
  npm ci --prefer-offline --no-audit --no-fund --os darwin --cpu x64
  [ -f node_modules/@anthropic-ai/claude-agent-sdk-darwin-x64/claude ] || { echo "::error::x64 Claude engine package not installed"; exit 1; }
else
  echo "native x64 host: nothing to do"
fi

npm's own documentation describes the two flags plainly. --cpu will “Override CPU architecture of native modules to install”, and --os does the same for the operating system. They were always there. We just had not needed them while every build ran on a machine of its own kind.

The verify step also checks the target's Claude engine by path, and the app's main binary and our deskctl helper with lipo, so a wrong slice fails by name. And the release runner's self-heal notes, which map known error lines to an action, list the probe message with the action escalate and zero automatic retries: “if it recurs the workflow regressed”. A retry would only build the same broken app again.

Build one Mac, carry the other.

The same morning, at 07:58, commit af33c833 added a mac_arch input to the release workflow with three choices: both, arm64 or x64. It sounds like a small convenience. It exists because the two Macs no longer fail the same way, so we need to be able to rebuild one without touching the other.

Carrying forward is not free of checks. A later fix (38ada81c, 7 September) recomputes the carried update feed's digests from the carried bytes, because older feeds were written before the DMG was notarized and stapled, and stapling makes the file slightly larger. The release only goes public when the finalize job has matched every expected file.

The build Mac choice got smarter too. Later on 6 September, our menu-bar release controller learned to send each lane to the Mac that fits it. From its routing code: “arm64 needs an Apple Silicon Mac. x64 goes native to an Intel Mac when one is on, else to any free Mac (Rosetta cross-build).” So the Intel app is built on an Intel Mac whenever one is online, and the cross-build with its reinstall step is the fallback, not the plan.

An installer that said Completed.

On 24 September we tested an ARM64 Windows installer on a virtual machine. It finished without complaint. The app was not there: no Luminair.exe, no DLLs, no engine binaries. Every ARM64 program in the package, 36 files, had been skipped.

The cause had nothing to do with npm this time. Windows installers built by electron-builder pack the app into a 7-Zip archive that an NSIS plugin unpacks on the user's machine. 7-Zip 24 compresses ARM64 programs with a special ARM64 filter. The NSIS 7z plugin cannot decode that filter, and when it meets a file it cannot read, it skips it without an error.

The fix, in commit 40af468d, sets ELECTRON_BUILDER_7Z_FILTER=BCJ in the pre-pack hook, which makes 7-Zip use the plain filter the plugin can read. The next day, commit 7463aa37 widened it from ARM64 builds to every Windows build, so there is one archive format to reason about.

The same day as the ARM64 discovery, an unsigned test build on Windows 11 had reported “Completed” while antivirus removed every .exe and .dll, a separate cause with the same symptom. Release 1.0.210, shipped that evening, added a guard that catches either cause: the NSIS script now confirms that Luminair.exe, ffmpeg.dll, app.asar and the bundled Claude engine exist after install, and fails with a clear message if they do not. The release workflow runs a real silent install that must keep every bundled binary.

The pattern is the same as on the Mac. A step that skips what it does not understand will never tell you. The only defence is to check the result against a list of what must be there.

Which Mac do you have?

1. 1Open the Apple menu and choose About This Mac. If the chip line says Apple M-something, you want Apple Silicon. If it says Intel, you want Intel.
2. 2On luminair.io/download, pick the matching row: Apple Silicon or Intel (Older Macs). The main button tries to pick for you from what your browser reports.
3. 3After that, updates follow the app you installed. Each Mac architecture has its own update feed, and the app picks the feed from the processor it was built for, so an Intel copy is only offered Intel updates.

Checked, and not claimed.

Sources

• PetaPixel · 10 June 2025macOS 26 Tahoe is the end of the road for Intel Macs
• The FPS Review · 22 April 2026Apple to drop support for Intel-based Macs following “Tahoe” macOS 26 release
• Apple SupportmacOS 27 Golden Gate is compatible with these computers
• The Eclectic Light Company · 14 September 2026Apple has released macOS Golden Gate, and security updates to Tahoe 26.7, Sequoia 15.8
• npm Docsnpm config: cpu and os

For another release story where one change reached everyone at once, read The deploy that closed every Mac's socket for four hours.