I Put Omarchy on an M1 MacBook Pro

TL;DR: I’m a few days into running Omarchy — a Hyprland-based, opinionated Linux setup — on an M1 MacBook Pro, dual-booting macOS. There’s a purpose-built path for this: omarchy-mac puts Omarchy on Apple Silicon via Asahi Alarm in about one command. Installing it is the easy part, and it’s documented well. What isn’t documented is the layer underneath — where the install still breaks, and what daily life costs once macOS isn’t there anymore. The surprise: thirteen coding agents come pre-wired, the OS hands segfaults to whichever one you’ve set as default, and configuring the machine by asking an agent is the designed path rather than a workaround. I don’t know yet if I’m keeping this. Field report, not a verdict.

Why this exists

macOS is still on the disk right now, dual-booting. A few days ago I put Omarchy on this machine using omarchy-mac, which pairs Asahi Alarm with Omarchy and does most of the work in a single command.

The install is the well-trodden part. omarchy-mac has been around since mid-2025, it’s actively maintained, and the README walks you through it properly. What I couldn’t find much of was the next layer down: what still breaks on the way through, whether a working dev setup actually survives the move, and what you give up day to day once macOS isn’t underneath anymore. That’s the gap this post is trying to fill, and it’s why I’m publishing now instead of waiting three months to have a settled opinion.

I want to be upfront about what this post is not. It’s not a recommendation. It’s not a “why I switched” essay — I haven’t switched. macOS is still on the disk. It’s a status report from someone a few days into an experiment who doesn’t know how it ends.

The install path

Two steps. First the Asahi Alarm bootstrap, run from the macOS terminal — it partitions the disk and puts Arch Linux ARM on the machine alongside macOS. Then, booted into that fresh Arch, the omarchy-mac setup command, which installs Omarchy itself.

Asahi is the project that ports Linux to Apple Silicon in the first place; Asahi Alarm is its Arch Linux ARM flavor. omarchy-mac is the layer that takes that base and makes it an Omarchy machine. None of this is exotic territory anymore.

It still broke.

Where it broke: aquamarine

Omarchy’s installer failed partway through, trying to install aquamarine — the rendering backend library that Hyprland depends on (maintained by the Hyprland team, source at hyprwm/aquamarine). The version the installer tried to pull was too new, and it wouldn’t install. I didn’t save the error.

The fix was to downgrade to an older aquamarine build out of the local pacman cache rather than take whatever the installer wanted to pull fresh. That got the install moving again. Worth being clear about what this wasn’t: not an architecture problem. omarchy-mac is built for M1/M2 specifically. This is the ordinary rolling-release failure mode — a dependency moves faster than the thing consuming it, and you land on the wrong side of a version for a few days. Arch does this. It’s the price of current packages, and it’s as true on x86 as it is here.

What’s actually good

Once it was up, the parts that are working are working well:

Hyprland’s tiling and the keyboard-driven flow. Window placement, workspace switching, everything stays on the keyboard, and that’s the thing I notice most hour to hour.

Speed. This is the same M1 hardware I was running macOS on, and it feels fast. Not a benchmark claim — just how it feels day to day on identical silicon.

Opinionated defaults. Omarchy makes a lot of choices for you — theming, keybindings, the tool selection — and I haven’t had to configure much of anything. Someone already decided, and mostly I agree with the decisions.

The agent stack isn’t ported. It’s built in.

I’d budgeted a day for getting my agent setup working again. I didn’t need it, and the reason turned out to be the most interesting thing I’ve found so far.

Omarchy’s own manual opens its AI chapter with this: “Omarchy treats AI coding agents as first-class citizens, but it doesn’t pick a favorite for you.” That is not marketing copy bolted onto a Linux distribution. It describes how the system is wired.

Thirteen agent CLIs come pre-wired as lazy-loaded launchers — claude, codex, opencode, grok, copilot, crush, pi, omp, agy, ori, hermes, muse, cursor-agent. They’re mise-managed stubs in ~/.local/bin/, so nothing actually downloads until the first time you run one. You pick a default with omarchy default agent <name>, and a fresh install prompts you to choose. Super + Shift + Ctrl + A opens it in a dedicated terminal. omarchy agent prompt "Review this project" launches it straight into a task — unattended, in its don’t-stop-to-ask mode.

My Elixir/Erlang toolchain came across without special handling too, but that part I expected. Toolchains are portable. The rest of this isn’t a toolchain, it’s a set of assumptions.

Two features make the assumption concrete. The top bar grows an agents panel the first time it sees AI coding usage on the machine — your plan, how much of the five-hour and weekly limits you’ve burned, tokens by day and by model. Usage tracking for coding agents, in the OS status bar, next to the clock.

The second is better. Omarchy watches systemd-coredump, and when something segfaults you get a “Process crashed” notification. Click it and the crash is handed to your default agent along with a diagnose-crash skill that walks it through reading the core dump and deciding whether the thing is worth reporting upstream. The operating system’s answer to a segfault is to hand it to your coding agent.

There’s also a skill for configuring the machine itself — Hyprland, the bar, themes — symlinked into ~/.claude/skills, ~/.codex/skills, ~/.pi/agent/skills and the generic ~/.agents/skills, so most harnesses find it without being told. In practice this has been the fastest way to fix things on this machine, including things unrelated to writing code. Worth repeating the project’s own warning though: it labels that skill experimental, suggests running plan mode first, and points at omarchy reinstall configs for when the agent makes a mess. That matches my experience — it’s very good and you should still watch it.

Most of what I do is a terminal, a browser, and an agent loop. I assumed that stack would be indifferent to the OS underneath it. On this one it isn’t indifferent — agentic work is the assumption the desktop is designed around, which is a different thing from an OS that merely stays out of your way.

Has the Apple Silicon hardware actually held up?

So far, yes, in the narrow sense that nothing has broken — but I want to be precise about what that does and doesn’t mean. I haven’t hit any hardware gaps in the time I’ve been on this. I’m not claiming external display, sleep, or the webcam work — I haven’t specifically tested or stressed those. I’m also not claiming any of them are broken. Nothing has bitten yet, and it’s only been a few days.

That distinction matters more than it sounds like it should. A few days of normal terminal-and-browser use doesn’t exercise the parts of a laptop that tend to be the hard problems on a reverse-engineered hardware port — sleep/wake cycling, external display timing, camera and audio pipelines. Asahi’s own project documents an ongoing, per-chip hardware feature support matrix for exactly this reason; I haven’t gone looking for where my specific gaps are yet, because I haven’t needed to. Take my “nothing’s broken” as “no news,” not as a clean bill of health.

The container caveat

This is the sharpest technical finding so far, and it’s worth real space because it’s the one that actually shapes what I’d tell someone else considering this.

Container images build fine locally on this arm64 machine. They don’t work on GCP, because of the architecture mismatch — arm64 built locally, x86_64 expected on the other end.

buildx plus QEMU does get you cross-arch builds that work. But those cross-arch builds run 3-5x slower than the same builds on macOS — and those builds were already fairly slow to begin with. Getting QEMU installed and working in the first place was itself a chore — not as straightforward as you’d hope.

If your workflow involves building containers locally that need to run on GCP’s standard x86_64 infrastructure, I don’t think this current setup serves you well. You’d be better off on a Dell XPS or some other native bare-metal x86 install where the build target matches the build machine and you’re not paying a QEMU emulation tax on every image. Worth noting that “just buy another machine” is a more expensive answer than it was a year ago.

What the walled garden actually costs

It’s hard to leave the Mac walled garden. Omarchy is pulling me toward leaving it, but that pull isn’t free — there’s real, daily friction from missing creature comforts I didn’t think about until they were gone.

iMessage has no usable path on Linux. iCloud Drive, Photos, and Keychain sync don’t follow you off macOS — they just stop. I use both Proton Mail and Proton Drive, and neither has an Arch Linux install, which forces me back onto their web clients — not the ideal experience for either. Backblaze is the same story: I haven’t found a Linux equivalent that fits how I was using it on macOS.

None of this is a dealbreaker on its own. It’s a daily tax — small friction, repeated every day, that adds up in a way a single dramatic failure wouldn’t. A crashed install is a bad afternoon and then it’s over. A missing sync feature is a bad moment every single day, indefinitely, and those compound differently than a one-time failure does.

Where it stands

I’m still dual-booting. macOS is still on the disk, and I’m not deciding anything yet. The tiling, the speed, the opinionated defaults, and the fact that my actual dev and agent workflow just works are real points in Omarchy’s favor. The container-to-GCP story and the daily walled-garden tax are real points against it, at least for how I currently work.

What would actually decide this for me: whether the container workflow gets less painful, and whether the macOS creature comforts I’m missing stop mattering as much as they do right now. I don’t have a timeline on either of those, and I’m not going to pretend I do. For now, this is where it stands — an open experiment, not a verdict.

If you’re weighing a build-target decision like this one — where the machine, the toolchain, and the deploy target all have to agree — that’s a conversation I have with clients regularly. Reach out if you want to think it through together.