Omarchy: Linux for Developers Using AI Agents

A new machine sits on the desk and the project has to keep moving on Monday. What follows is familiar to anyone who builds their own workstation: install Arch, configure Hyprland, sort out fonts, shortcuts, clipboard, screen lock, then Docker, then the three agent CLIs that have quietly become as essential as the editor. None of it is hard. All of it takes time.

Omarchy aims straight at that gap — and goes one step beyond the usual dotfile collections: the AI agents are not bolted on afterwards, they are part of the system, with their own place in the bar, a default agent you choose yourself, and their own diagnostic skill. The question is not whether that photographs well, but whether it holds up on your hardware, with your data, in your working style. What follows is a documentation- and source-based analysis as of 3 September 2026 — not a multi-week hands-on test on real hardware, but a foundation for your own decision.

Key takeaways

• Omarchy is a free, open-source system by David Heinemeier Hansson built on Arch Linux and the Hyprland window manager, using Quickshell as its interface layer since version 4.0. You skip rebuilding a keyboard-driven desktop from scratch — you do not skip the learning curve of tiling and rolling releases.
• The real difference is the agent layer: per the AI manual, ten prepared agent CLIs, a default agent you set yourself via a command or in setup, a widget for provider and limit status, and a skill for crash diagnosis. Agents are system citizens here rather than add-ons.
• The way back is built in, but narrower than it sounds: snapshots are created automatically before updates, and you roll back through the Limine boot menu. This is documented for root only — not for /home.
• Hardware decides first: x86-64 PCs and Intel Macs are documented (as of 3 September 2026), while no official ARM or Apple Silicon support was findable. Encryption is the default, the installer docs require Secure Boot and/or TPM to be disabled — only a Bluetooth keyboard fails at the boot passphrase; wired or a 2.4GHz dongle both work.
• Maturity is the open flank: versions 4.0.1 and 4.0.2 closed real, documented security holes, including agents running with a full bypass instead of auto-review. A security team and responsible disclosure exist; long-term stability in professional use is not yet demonstrated.

What Omarchy does differently from a hand-built Arch setup

Omarchy is not a new kernel world, it is an opinion shipped as a finished system: Arch Linux underneath, Hyprland as window manager, Quickshell since version 4.0 for the bar, menus and widgets — preconfigured, encrypted, built for keyboard control throughout. Assemble the same combination yourself and you end up somewhere similar: the difference is curatorial, not technical.

The opinion is the product. In a self-built setup you negotiate every detail individually — launcher, notification daemon, terminal, shortcuts. Omarchy answers all of it in advance and consistently. The gain is time and coherence; the price is finding your way around someone else’s decisions before you can meaningfully change them.

The version numbers are young. Release 4.0.0, named Quattro, is dated 14 August 2026; the currently verified state, 4.0.2, is dated 31 August 2026 (as of 3 September 2026) — with several releases containing documented security fixes in between. A project in active motion, not a system with years of field service; what that means for the security record follows below.

Because claims and evidence blur quickly around a project with a famous name, here is the separation up front:

What actually changes in an agent-driven day

The difference between “the AI CLIs are installed” and “agents are system citizens” shows up in four places: a new machine, several subscriptions, crashes, and system configuration. In each, Omarchy replaces several moves with one — with a boundary worth knowing.

One machine, one install run. Instead of installing Arch, Hyprland, the bar, fonts and every agent CLI one by one — realistically one to two evenings, mostly corrections rather than installing — you boot an ISO and end up with a system that already fits together. Accounts, API keys, SSH keys, Git identity and your own dotfiles remain your job, unchanged: Omarchy shortens the system layer, not your identity layer.

Several agent subscriptions, one glance. If you work with several agent CLIs in parallel, you know the problem: several providers, several consumption views, usually checked only after a limit has already bitten. Omarchy pulls provider and limit status into a single widget in the bar: per the AI manual it covers Claude Code, Codex and Fireworks out of the box. The display refreshes every 15 minutes and, per the documentation, can merge status across multiple machines. The boundary: a widget displays consumption, it does not govern it — billing and spending caps stay with each provider.

Hand off crashes instead of dissecting them. Classically, crash analysis runs through coredump and debugger: locate the dump, keep symbols matched, read the backtrace, form a hypothesis. Omarchy provides its own diagnostic skill that watches systemd-coredump: a crashed application can be handed to your default agent — the one you set yourself via omarchy default agent <name> or under Setup > Defaults > Agent; a fresh install asks once. The result is a read trace and a reasoned guess, faster than manual debugging, but without matching debug symbols it stays a hypothesis. It does not replace verification, it accelerates it.

Letting an agent rebuild your desktop. Hyprland and Quickshell are configured through files — powerful and tedious. Omarchy provides a skill, labelled experimental, that lets the agent change desktop settings itself. Take that seriously: a language model is writing into your system’s configuration. Two guardrails make it workable: have it plan first and read the plan, and keep a way back — version control or a current snapshot. Anyone granting write access should understand how prompt injection against AI agents works: reading foreign content plus permission to change the system are exactly the two properties real incidents are made of.

Across the whole life of a machine, the picture looks like this:

What the working day feels like with tiling and Hyprland

This is exactly where the title’s promise meets the everyday: an agent needs a visible terminal while you keep working on something else — in a tiling window manager the two share the screen instead of covering each other. In Omarchy that comes preconfigured: you say what goes where with a key combination instead of dragging things with the mouse.

In practice a morning looks like this: workspace one holds editor and terminal side by side, workspace two the browser with the test environment, workspace three the agent working through a refactor with its output running in the terminal — the terminal is the default surface where agents get started, watched and interrupted. Switching is a keystroke, not a hunt through a taskbar.

The price comes in three parts: the muscle-memory phase with slower first days, edge cases with applications that resist fixed tiles — video calls, some Electron and Java programs — and Wayland quirks, screen sharing above all. None of this is disqualifying, but these are exactly the points that sting on a Tuesday morning with a client call booked.

Installation, updates and the way back

The installer offers two routes: the entire disk, or — since the Quattro release — free space alongside an existing system. Encryption is the default, and the installer documentation requires Secure Boot and/or TPM to be disabled.

The keyboard is a genuine trap. An encrypted system asks for its passphrase before the operating system runs — and therefore before the Bluetooth stack exists. A Bluetooth keyboard cannot type that passphrase; a wired keyboard or a 2.4GHz dongle works fine instead. Settle that before installing, not after.

Updates arrive rolling, the snapshot arrives automatically. Arch as a rolling release delivers updates continuously — that’s why the system stays current, and why an update could in principle break something at any time. Omarchy creates a snapshot automatically before every update: if something goes wrong, you pick the previous state from the Limine boot menu at restart, instead of hunting down a live USB and chrooting in.

The boundary you must know: rollback is documented for root, not for /home — backing up your own data stays a separate job. Important: this rollback capability depends on Limine — it isn’t available with GRUB or systemd-boot as the bootloader. The standard dual-boot setup therefore relies on Limine; limine-scan adds a system installed alongside to the boot menu, which does not make it rollback-capable. Dual-booting with Windows additionally requires BitLocker to be switched off first.

And when the machine moves on: for handing hardware to someone else, Omarchy provides a factory reset that returns the machine to a delivery state — documented only for installs freshly set up with Quattro, not for systems migrated later. For fleets, Omarchy also documents unattended initial installation from a configuration image, for example across VMs. An ongoing central management console, multi-user provisioning or a device inventory are not documented — if you need to manage fifty machines centrally, this does not solve that problem.

Security and maturity: what the fix history tells you

The most informative thing about Omarchy sits in the release notes for 4.0.1 and 4.0.2. Between Quattro and 4.0.2 lay 17 days, in which real security holes were closed — agents running with a full bypass instead of automatic review, a shell injection, an SSH hardening pass and signed packages.

The good signal: the holes were found, disclosed, fixed and named. There is a security page, a security team and a route for responsible disclosure. A project that documents its own failures in plain language is more predictable than one whose release notes only celebrate features.

The uncomfortable signal: those holes shipped in a released version — in the agent layer of all places, where automated processes execute commands on your machine. The gap between auto-review and full bypass is exactly the gap between an agent that asks and one that acts. Two releases with security fixes in such a short span signal both responsiveness and youth.

The most expensive misconception: “local” does not mean “my data stays here”. An agent that runs on your machine but thinks through an external provider’s API sends code and error output outside — the same trade-off we set out in our piece on local AI versus cloud models. For teams, the same guardrails apply as for AI agents at work: minimal permissions, approval for critical actions, logging.

Who should switch — and who should not

Suitability comes down to three things, in this order: does it run on your hardware, can you live with rolling releases and tiling, and is the machine replaceable if an update takes it out for two hours? A no on the first ends the discussion immediately.

Two rows deserve an explanation. The single machine as main device is the critical case: an expensive bet assuming a rehearsed rollback and a separate backup. The beginner underestimates that preconfiguration covers the desktop, not the OS: once a package misbehaves, you’re in Arch, and the answer lives in the Arch wiki, not the Omarchy manual.

A low-risk first test

If this article left you curious, the next step is not “rebuild the main machine”, it’s a bounded trial with abort criteria fixed in advance:

• Pick hardware whose failure costs you nothing: a spare machine, an old SSD, a retired x86-64 laptop.
• Put a wired keyboard or 2.4GHz dongle on the desk — Bluetooth fails the first encrypted boot.
• Settle which changes to Secure Boot and/or TPM and any second system are required before the installer runs.
• Rehearse the rollback deliberately while nothing is broken — a recovery path you’ve never walked is an assumption.
• Move a week of real work onto it rather than a demo hour: the gap between “looks great” and “holds up” appears on day three.
• Write your criteria down beforehand: do the shortcuts sit after five days? Do you use the limit widget? Has the diagnostic skill saved time?

Ask those questions afterwards and you’ll answer them with your gut.

The bottom line

Omarchy sells time saved but demands systems competence — an uncomfortable combination. Anyone who knows Arch and Wayland well enough to repair things under pressure could, at a push, have built this system themselves. Anyone who doesn’t gets a beautifully arranged desktop and, at the first real fault, a problem the preconfiguration has no answer for. The honest value sits exactly in between: for people who could do it, but would rather spend their evenings on their own projects.

The genuinely interesting point, though, is not the desktop but the assumption underneath it. If AI agents are a permanent part of the toolkit, then they belong in the operating system — with a fixed place, visible limits, clear permissions and a diagnostic path that isn’t reinvented per vendor. That shift is happening whether Omarchy prevails or not. The only open question is which permission model arrives with it — and whether you can say what the agent on your machine is allowed to do.