We audited Omarchy, the “OS for the age of agents”. Here is what is actually inside

A technical review of Omarchy 4.0.4 — installation, the architecture of its AI agents, a security audit, and an uncomfortable question about where artificial intelligence actually lives in an operating system.

---

When the creator of Ruby on Rails ships an operating system and calls it “the malleable OS for the age of agents”, the industry pays attention. Omarchy has spent months collecting headlines: ten AI agents pre-wired, installation in under two minutes, a desktop that promises to change how you write software.

We did what you do with any piece of software before letting it near production. We installed it, opened it up and looked inside.

This article is the result. It is not a review of impressions. Every claim below is backed by a command run against a clean Omarchy 4.0.4 install, and every one of them is reproducible in ten minutes by anyone who wants to check our work.

Here is the conclusion up front, because articles that make you wait for it are wasting your time: Omarchy is a far better piece of engineering than its marketing suggests, and it contains far less artificial intelligence than its name promises. Both things are true at once, and explaining why is the point of this piece.

What we audited, and how

A clean virtual machine on VirtualBox 7.2.2: 6 GB RAM, 4 CPUs, 40 GB disk, UEFI boot. The official omarchy-4.0.4.iso, 5.8 GB, SHA-256 verified before installing. Default installation with LUKS disk encryption enabled, not a single advanced option touched.

In other words: exactly what anyone downloading Omarchy this afternoon would get.

Installation: fast, with a trap that is not its fault

The “under two minutes” claim holds up. The installer asks five questions and gets out of the way. At a time when installing Arch Linux remains a rite of passage, that is a genuine achievement and deserves to be said.

But the first time we booted, we could not get in.

The encrypted disk password contained an @. Typing it at boot, the system refused it. The password was fine. The keyboard was not.

LUKS unlocking happens inside the initramfs, the minimal image the kernel mounts before the real system exists. No keyboard layout is loaded at that point: it is always US, regardless of what you chose during installation. The @ symbol, which on a Spanish keyboard is AltGr+2, is Shift+2 there.

This is not an Omarchy bug — it happens on Ubuntu, on Fedora, on anything with an encrypted disk. But it is exactly the kind of detail that turns a two-minute install into a lost afternoon, and no article about Omarchy mentions it. If you encrypt your disk, either pick a password without symbols or know where they live on a US layout.

The second wall: everything at double size

First boot into the desktop, and the terminal fills the screen with twenty lines of text. Unusable.

The cause sits in ~/.config/hypr/monitors.lua:

local omarchy_gdk_scale = 2
local omarchy_monitor_scale = "auto"

Omarchy assumes high-density displays — the expensive laptops its author works on — and doubles system scaling by default. On a 1280×800 monitor that leaves nothing readable. The fix is two numbers:

local omarchy_gdk_scale = 1
local omarchy_monitor_scale = 1

It is worth pausing here, because it explains a lot about Omarchy: it is calibrated for the hardware of the person who wrote it. That is not a flaw; it is a legitimate, deliberate product decision. But it is worth knowing before installing it on anything that is not a high-end laptop.

The real question: where is the artificial intelligence?

This is where the audit gets interesting.

Omarchy advertises ten pre-wired AI agents. We found them, sure enough, on the user’s PATH:

claude, codex, gemini, copilot, opencode, crush, cursor-agent, pi, hermes, grok

However: nine of those ten files weigh between 111 and 153 bytes. The tenth, hermes, reaches 1,463. This is the entire contents of claude, and it is four lines:

#!/bin/bash
export MISE_MINIMUM_RELEASE_AGE=0
mise use -g --quiet "claude" || exit 1
exec mise x "claude" -- "claude" "$@"

They are wrappers. Four lines that, the first time you invoke them, download the actual agent from the internet through mise, a developer tool version manager.

This needs to be stated precisely, because it is easy to be unfair in either direction. The agents do not ship installed. They ship wired. The wiring is real and it has value — resolved PATH, managed versions, centralised updates — but with no internet connection there is no agent on that machine. And none of them is a component of the operating system: they are command-line programs that work identically on Debian, macOS or Windows.

This is not a scandal. It is, quite simply, the only architecture available. And the reason deserves its own section.

Why no operating system has AI “inside”

It is tempting to picture an operating system with a language model woven into its core, servicing system calls intelligently. It is also technically impossible, and understanding why dismantles the marketing pitch of an entire product category in one move.

An OS kernel lives under constraints that do not negotiate:

• It cannot crash. A failure in userspace kills a process and the system carries on. A failure in the kernel is a panic: the whole machine goes down.
• It has no abundant, dynamic memory. The most modest language model worth running needs several gigabytes and, realistically, a GPU.
• It must be deterministic. A CPU scheduler that sometimes makes a different decision given identical input is not a scheduler. It is an outage waiting to happen.

A language model is the exact opposite of all three: heavy, slow and probabilistic. Putting it where an error powers off the server is not innovation. It is negligence.

So when Ubuntu, Windows or Omarchy announce “AI in the operating system”, all three mean ordinary programs running in userspace, the same as a web browser. The difference between them is not technological. It is curation: what they choose to install for you, and what they stitch around it.

And at that, it must be said, Omarchy does a notable job.

What Omarchy genuinely did integrate

Against the 154 bytes of those wrappers, the system ships 446 commands of its own in /usr/bin, all provided by a signed package (omarchy 4.0.4-1). That is not a loose script. That is a distribution with a point of view.

The crown jewel is the crash watcher. When a process dies, omarchy-crash-watch catches it and offers to diagnose it with an agent. The mechanism is elegant: rather than watching dump files, it follows the system journal filtered by the message ID that systemd-coredump emits on every crash, which yields structured fields instead of filenames.

The code is, plainly, well written. Two details give it away:

Crash-loop deduplication. A process crashing in a loop produces hundreds of dumps a minute. The watcher announces each program at most once per window — and, a fine touch, only starts that window if the notification was actually delivered, because a failed send that counted would suppress the rest of the loop.

Defence against hostile process names. Crash details are passed as discrete argv words, never interpolated into a shell string. A process named ; rm -rf / stays a name instead of becoming a command. That is the kind of care that separates professional software from a weekend script.

The diagnosis instructions are replicated across all five main agents, so it works with whichever one you picked. That is real integration, not a marketing label.

The same holds for VoxType, the offline Whisper-based voice dictation: it exists as an official package in Omarchy’s own repository, with five dedicated commands to install it, configure it and pick a model. Necessary precision: it does not ship installed. You have to ask for it.

Security audit: what happens if you make it a server

Omarchy is a desktop and claims to be nothing else. But the temptation to leave a service, a container or an overnight agent running on it is obvious, so we audited it on those terms.

What is right, and it is more than we expected:

Area	Status
Firewall	ufw active, default incoming policy deny
Disk encryption	LUKS across the whole root volume
AUR packages	Zero. Everything comes from signed official repositories
Snapshots	Btrfs with Snapper: rollback after a broken update
Privilege escalation	NOPASSWD rules tightly scoped with strict regular expressions

That “zero AUR packages” deserves underlining. Arch’s community repository is the standard entry point for unaudited code in that ecosystem. An Arch-based distribution that does not depend on it has made a serious and uncommon security decision.

What is not right:

Finding	Risk
SSH with PasswordAuthentication yes and no fail2ban	Brute force with no brakes
No update timer of any kind	A rolling release with no automatic patching: the worst of both worlds
No AppArmor or SELinux; kernel.kptr_restrict = 0	No mandatory access control at system level
CUPS, Avahi and Bluetooth enabled by default	Unnecessary attack surface outside a desktop

A required precision on the third point: kernel security modules are loaded (lockdown, capability, landlock, yama, bpf). Landlock is present, and it matters. But Landlock only protects where each application sandboxes itself voluntarily; it is not a system-wide policy an administrator imposes. Reasonable for a desktop. Not sufficient for a server.

The second finding is the most serious and the least visible. A rolling release receives security patches constantly, which is an enormous advantage — provided somebody applies them. Omarchy schedules no automatic updates whatsoever. The only active timer on the system updates the file-search database. A server built this way accumulates known vulnerabilities until a human remembers to type pacman -Syu.

The most interesting gap is in the kernel

Omarchy compiles its own kernel (7.2.5-3-omarchy), and does so with one option that stands out:

CONFIG_SCHED_CLASS_EXT=y        → sched_ext compiled in
/sys/kernel/sched_ext/state     → disabled
Tooling installed               → none

sched_ext is the feature that lets you write the system’s CPU scheduler as an eBPF program and load it live, without recompiling the kernel or rebooting. It is, as of today, the only place in the system where custom logic can run inside kernel space.

Omarchy compiles it in, leaves it disabled, and installs not a single tool to use it. No scx_rusty, no scx_lavd, not even bpftool to inspect it.

Leaving it disabled by default is the correct call for a general-purpose desktop: an experimental scheduler is not what you want underneath your editor. But the result carries its own irony: the operating system marketed for the age of agents ships with the one door boarded up through which intelligence could actually reach the kernel.

That, and not the bash wrappers, is where the interesting work of the next few years lives.

The numbers

Measured on the virtual machine described above, desktop booted and idle:

• Userspace to usable desktop: 5.47 s
• Idle RAM: 966 MB with 276 processes and the full graphical environment
• Installed packages: 949, none from AUR
• Versions: Python 3.14.7, systemd 261.2, Mesa 26.2.2, Docker 29.7.2, Hyprland 0.56.2

Under a gigabyte at idle for a complete desktop is an excellent figure, and the credit goes to Hyprland and a restrained package selection.

One note of honesty about boot time: the total was 45 seconds, of which the kernel took 33. That number is an artefact of measuring inside a virtual machine with an encrypted disk and does not represent behaviour on real hardware. The valid figure, and a good one, is userspace: 5.47 seconds.

Verdict

Omarchy makes sense if you write software on a modern laptop, want a curated development environment without spending a weekend assembling it, and consider maintaining a rolling distribution a fair price for always having the latest version of everything. The curation is good, the code is good, and the experience is considered. The 446 commands it ships are not filler: they are decisions made on your behalf by someone who knows what they are doing.

Omarchy makes no sense if you want a server. It was not designed for that, does not claim to be, and the absence of automatic updates on a rolling distribution is a combination no systems administrator should accept in production.

And on the promise that gives the whole category its name, the honest answer is this: Omarchy’s artificial intelligence is not in the operating system, because it cannot be in any operating system. What Omarchy genuinely offers — and it is not nothing — is not having to decide what to install yourself.

Whether that is worth the cost of maintaining Arch Linux is an engineering decision, not an article of faith. And like every engineering decision, it depends on what for.

---

Appendix: the same thing, on Debian

The central claim of this article is that the integration is replicable. So we replicated it: we ported Omarchy’s crash watcher to Debian, in two scripts and a systemd unit.

The mechanism is identical, because systemd-coredump is standard and has nothing Arch-specific about it. The changes are matters of judgement, not technology:

• Omarchy ignores crashes that do not belong to the logged-in user. Correct on a desktop. On a server, the daemon dumping core is precisely what you need to know about, so we watch every UID.
• The desktop notification becomes a report in /var/log. The original waits for someone to click. A server at three in the morning has nobody in front of it.
• The deduplication window goes from 60 to 300 seconds. On Omarchy a notification is free; here every diagnosis is an API call that costs money.

One detail worth knowing if you replicate this: Debian does not install systemd-coredump by default. Without it the kernel writes cores according to core_pattern and the journal has nothing to read. It is the most common reason a setup like this appears to work while doing nothing at all.

The code is published alongside this article and runs to about 80 lines. With one disclosure that is owed: it is written and reviewed, but we have not yet run it on a production server. Calling it tested without having executed it would be precisely the kind of unverified claim this article holds against others.

Which is, in the end, the precise measure of the distance between “operating system with built-in AI” and “an ordinary server with an agent installed”: eighty lines of bash and one apt install.