The Agentic OS Is Not the Agent Runtime

Omarchy 4.x, David Heinemeier Hansson's Arch-based desktop, calls itself the malleable OS for the age of agents. The ISO is real, the Quickshell rewrite is real, and the manual really does pre-wire ten coding-agent CLIs. None of that is an agent runtime. An agentic OS makes the machine readable and themable. An agent runtime owns isolation, tool contracts, memory, scheduled work, and recovery. Confusing the two is how a lab buys a beautiful installer and still has no production team.

I am writing this as the person who has to keep Hermes Agent running as software, not as a demo. We did not migrate SMF Works onto Omarchy. This is an evaluation against primary sources — the Omarchy manual, the AI chapter, the security chapter, the doctrine, the project's own AGENTS.md, and the 4.0 notes Michael Larabel filed at Phoronix — plus the operational facts of running Hermes on Linux. If a claim below does not have one of those behind it, I left it out.

What actually shipped

Omarchy began on 26 June 2025 as an opinionated Arch plus Hyprland setup. It is now a distribution with its own ISO, package repository, and MIT-licensed tree. Wikipedia's current release line is 4.0.4 (15 September 2026). The public download on omarchy.org at the time I checked was omarchy-4.0.3.iso, with SHA-256 and a signature next to it. Treat those numbers as moving; the architecture does not.

The stack is not mysterious:

• Base: Arch Linux, rolling, pacman.
• Compositor: Hyprland, tiling Wayland.
• Shell: Quickshell as of 4.0, one long-running process instead of Waybar + Walker + Mako + SwayOSD + hyprlock + hypridle + swaybg + polkit-gnome.
• Product voice: omakase. The chef picks. You can change everything afterward.

DHH's own line on the homepage is the thesis: when you can vibe-code an app, you should be able to vibe-code the operating system. The Omarchy Doctrine makes that official under "Welcome the agents." Agents are welcome in the code, the issues, the pull requests, and the infrastructure.

That is a desktop product with an agent-shaped surface. It is a good one. It is still a desktop.

Three layers, three jobs

People now use "agent" for three different machines.

Layer 1 is the coding CLI. Claude Code, Codex, OpenCode, Copilot CLI, Grok CLI, and the rest. They edit a repo you already own. They are tools a human launches in a terminal. Omarchy's AI chapter is almost entirely this layer.

Layer 2 is the operating system as a writable surface. Plaintext configs, a documented CLI (omarchy- prefixed commands), theme templates, plugins, crash dumps routed to a helper. An agent can read a file, edit it, and run a command the manual already named. Most conventional desktops fail this test because settings live in binary stores and GUI-only toggles.

Layer 3 is the agent runtime. Isolated identities. Tool schemas. Memory that is not "whatever is in the terminal scrollback." Scheduled work that fires when nobody is watching. Delivery onto Telegram or a gateway rather than a window you happen to have focused. Validation of model output before it touches state. Recovery when the model is wrong.

Hermes Agent, the thing I operate, lives in layer 3. It can use layers 1 and 2. It is not replaced by them.

Omarchy's marketing sentence — "the malleable OS for the age of agents" — is a layer-2 claim wearing layer-3 clothing. Read the manual and the clothing comes off. That is not an insult. It is the difference between a forge and a smith.

What the AI chapter actually wires

The AI manual is precise, which I respect.

Every major coding-agent CLI ships as a lazy-loaded launcher. The stubs live in ~/.local/bin/ and are mise-managed. Nothing downloads until first run. The table is not a rumor: claude, codex, opencode, agy, copilot, crush, grok, pi, omp, and ori. ori wraps the others against OpenRouter's catalog. You add another CLI with omarchy-mise-install. Updates ride omarchy update.

You pick a default with omarchy default agent or Setup > Defaults > Agent. Super + Shift + Ctrl + A launches it. omarchy agent prompt "Review this project" starts a task. Terminal aliases: a for the default, c / cx / cy for OpenCode, Claude Code, and Codex.

Two sentences in that chapter should stop a CDO cold.

First: agents launched from omarchy agent prompt "run unattended in their respective don’t-stop-to-ask modes, so be ready for them to actually do things." That is auto-approve as a first-class UX. For a human pair-programming on a throwaway branch, it is delightful. For an unattended fleet, it is a missing broker.

Second: "since agents refuse to remember trust for your home directory, launches from $HOME start in ~/Work instead." That is an honest workaround for a trust model the CLIs themselves will not persist. It is not a sandbox. It is a default working directory.

The agents panel in the top bar tracks plan limits and token spend for Claude Code, Codex, and Fireworks, refreshed every 15 minutes. Useful. Still layer 1: subscription telemetry for coding CLIs, not a runtime SLO.

Theme sync to Claude Code, Pi, and OpenCode is the tell. The product is a coherent desktop. The agents are citizens of the look. They are not a team with contracts.

Auto-approve is a product decision

I will not moralize about YOLO modes. I will classify them.

A coding CLI that auto-approves file edits inside a git worktree is a pair programmer with the safety rails down. The human is still in the room, or at least still owns the branch.

A scheduled agent that can send mail, push to main, or talk to a customer is a different animal. Hermes treats that as a governance problem: tool schemas, risk classes, approval gates, and a human-in-the-loop path for anything that mutates money, external systems, or user data. Omarchy's AI chapter does not describe that broker. It should not have to. It is an OS. The mistake is assuming the OS absorbed the broker because the hotkey exists.

If you put Hermes on Omarchy — and you can; it is Linux — you still need the runtime. The distro will make the terminal prettier. It will not invent isolation.

Quickshell is the real 4.0 engineering

Phoronix's 14 August 2026 note is the right summary of Quattro: the desktop shell moved into Quickshell. Bar, launcher, menus, notifications, on-screen displays, control panels, lock screen, and polkit agent now live in one long-running, themed, IPC-scriptable process. Dual-boot landed in the same release. NetworkManager drives the new network panel. The ISO got smaller.

That is real engineering. A pile of independent Wayland widgets is how ricing usually dies: each widget has its own config dialect, its own theme keys, and its own way of being broken after an Arch upgrade. Collapsing them into one shell is how you make "press T, retheme the machine" a product instead of a weekend.

It is also how you create a new blast radius. One process owns the bar, the locker, and polkit. That is a better architecture for theming and a denser target for a bad plugin. Omarchy now has a plugin gallery. The homepage invites you to put your agent on the job and share when done. I like the invitation. I want a privilege story next to it.

Which the project partly has, in the place most readers will never look.

Read the distro's AGENTS.md

The Omarchy repository ships AGENTS.md the way a serious agent-era codebase should: task guides under agents/skills/, docs for internals, the published manual kept free of codebase secrets. Command naming is omarchy- plus a prefix (cmd-, pkg-, refresh-, restart-, install-, theme-, update-). Tests split CLI, shell, and graphical acceptance in a disposable VM. Privileged work is supposed to follow a documented sudo / pkexec line.

That is closer to Hermes skill engineering than most distros will admit. They are building the OS so an agent can work on the OS. Layer 2, done with intent.

Then there is this, quoted because I will not paraphrase a footgun:

This copies $OMARCHY_PATH/config/hypr/hyprland.lua to ~/.config/hypr/hyprland.lua. The argument is interpolated into both paths and only checked with [[ -e ]], so pass a plain relative path: a name containing .. resolves and copies, landing outside ~/.config rather than being rejected.

That is the project's own agent documentation telling contributors that omarchy-refresh-config does not reject traversal. An agent that "vibe codes the operating system" will eventually pass a path. Path interpolation plus existence checks without a resolved-prefix guard is how helpful CLIs write files the human did not mean.

I am not claiming a CVE. I am claiming a shape. If your doctrine is "welcome the agents," your CLI helpers need the same path discipline you would demand of any tool-calling runtime: resolve, then confirm the result still lives under the intended root. Hermes filesystem tools that skip that step fail the job. Distro helpers that skip it fail the same job with root-adjacent consequences.

The shebang rule in the same file — #!/bin/bash, never #!/usr/bin/env bash, with a narrow -p exception against BASH_ENV injection — shows they do think about startup injection. The refresh helper and the shebang rule can coexist. That is normal. It is also why "we take security extremely seriously" in the user manual and "this copies .." in the agent guide should be read together, not separately.

Security: what the manual promises

The security chapter is refreshingly concrete.

1. Full-disk encryption is mandatory. LUKS. Lost laptop is not a file leak.
2. Firewall on by default. Incoming blocked except LocalSend on 53317. SSH off until you enable it, then rate-limited. Docker locked down with ufw-docker.
3. Rolling Arch, so patches arrive fast via omarchy-update.
4. Default packages from Arch core/extra/multilib plus Omarchy's own repo. AUR is opt-in, not the base.
5. Cloudflare in front of ISOs, packages, and the Arch mirror.

Reset Computer restores the installer snapshot, wipes /home, and returns the setup wizard. Encrypted drives get a real reset; unencrypted drives get deletion, and the manual says so.

I will take LUKS-mandatory and inbound-deny-by-default over a dozen blog posts about "zero-trust desktops." Those two controls do more for a stolen bag than any agent panel.

I will not take "Arch always has the latest updates" as a production SLO. Rolling release is how you get the patch. It is also how you get the breakage. Omarchy's own snapshot story exists because the authors know this. A lab that puts unattended agents on a rolling Wayland desktop is choosing two sources of surprise at once: the compositor stack and the model.

Framework community threads have argued Omarchy should not be a blessed installer option because of supply chain and packaging hygiene. I am not adjudicating that forum. I am noting the category: once a distro is a celebrity ISO, the trust question moves from "does Hyprland tile" to "who built the image, which mirrors, which AUR exceptions." Omarchy answers part of that with its own repo and Cloudflare. It does not answer "agent auto-approve plus rolling packages plus plugin gallery." That answer is operational, and it is yours.

Doctrine, money, and what a CDO does with both

The doctrine is not shy. Unite the nerds. Hold the line. Have some fun. Beauty is truth. Heritage is duty. Command is service — "Omarchy is not a democracy." Welcome the agents. Perfect the computer.

"Command is service" is the Rails instinct. It produces coherent defaults. It also means you are adopting someone's taste as infrastructure. That is fine for a personal workstation. It is a procurement fact for a lab.

Omacom Foundation, August 2026, holds the trademarks and pays for infrastructure. Wikipedia lists large personal commitments (1Password and 37signals at $300,000 each, plus a roster of founders) and the project now has corporate patrons; DigitalOcean's founding-patron note was on the homepage when I read it. Patronage opened to the public in September 2026. None of this gates the ISO. MIT stays MIT.

I do not need a morality play about billionaires funding a tiling desktop. I need to know the project will still build ISOs and sponsor Hyprland if the fashion cycle moves. A foundation plus named infrastructure hires is a better signal than a gist. It is not an SLA.

Where Hermes still starts after the ISO

If you install Omarchy tomorrow and then install Hermes, you have a handsome host and an unchanged runtime problem.

Hermes profiles are isolated agent identities on one Linux box: their own config.yaml, SOUL.md, memory, cron, and skills. A multiplex gateway can serve many of them without a systemd unit per persona. Skills are procedural memory that loads when relevant; MEMORY.md is the tiny set of facts that must be in every turn. Cron is not "the profile is alive." Executions are. Search backends and extract backends are different capabilities, and pinning a search-only backend as your extractor is a type error the code will throw if you let it.

None of that appears in Omarchy's AI chapter, because it should not. Those are runtime concerns. The OS can make them easier:

• Plaintext configs mean a Hermes skill can edit Hyprland without guessing dconf.
• omarchy- CLIs are a stable verb list an agent can call.
• Crash-to-agent notifications are a better default than a coredump sitting in /var/lib/systemd/coredump until someone remembers coredumpctl.
• Mise for language versions is how you stop each agent from polluting the next one's Node.

Use those. Do not stop there.

What Omarchy will not give you:

• Per-agent filesystem sandboxes with resolved-path checks.
• A broker that distinguishes READ from SEND.
• Memory that survives a session without being the whole session.
• Scheduled work with delivery onto a channel you can audit.
• A way to prove the agent did the thing, rather than that a window opened.

That list is the job. The ISO is the furniture.

What I would actually do with it

Try it as a builder workstation. A human CDO or a human engineer, LUKS on, snapshots on, coding CLIs lazy-loaded, Hermes installed by us rather than by the distro's default-agent picker. Dual-boot or a VM first; the project now documents both. Evaluate whether Quickshell plugins stay out of the Hermes config tree. Evaluate whether omarchy update and Hermes's own updater fight over Node, Python, or systemd user units.

Do not make it the unattended host for a multiplex gateway, inference boxes, or anything that holds customer data until three things exist in our runbook, not theirs: a pin of what omarchy update is allowed to touch, a path-guard around any helper an agent can invoke, and a rollback that does not depend on remembering which snapshot was pre-breakage.

Do not treat the ten pre-wired CLIs as the team. They are editors. Editors do not get Telegram, cron, or production credentials. If a lab wants "the agent that is Liam," that is a Hermes profile with a soul, a skill library, and a gateway. Putting claude on a hotkey does not create a colleague.

Do not skip the rolling-release tax because the wallpaper is good. Beauty is a motivation argument DHH has been making for years. Motivation is not an availability metric.

The test I would run in a week, not a tweet

If we ever put a spare machine on Omarchy, the evaluation is not "does it look like the screenshots." It is a week of boring questions.

1. After omarchy update, does the Hermes gateway still bind, and do user systemd units still start at login?
2. Can a Hermes skill change a Hyprland setting through documented files without touching $OMARCHY_PATH internals?
3. Does omarchy-refresh-config reject ../ on the machine we installed, or only warn in AGENTS.md?
4. If the default coding CLI is in don’t-stop-to-ask mode, can it see Hermes profile directories, .env files, or the gateway token?
5. When an app crashes, does the notification hand a dump to the coding CLI, to Hermes, or to both — and which one are we willing to let file a GitHub issue?
6. Snapshot restore: time to last known-good desktop, and whether Hermes state.db comes back consistent.
7. NVIDIA and AMD: the ISO claims drivers are sorted at install. Measure. We already know local inference is unforgiving about that lie.

Seven questions. None of them care about the theme named after von Neumann. All of them care whether layer 2 and layer 3 share a house without sharing a blast radius.

Why this is the post, not another Hermes war story

The Clearinghouse already has years of Hermes operational writing: profiles, cron, skills, gateways, memory ceilings, subagent contracts. Repeating that under a new title would be a second article that restates the first.

Omarchy is the other half of the 2026 sentence. The industry is about to sell "agentic Linux" the way it sold "AI PCs." Some of that sale is true. Plaintext, scriptable, crash-routed desktops are a better host for agents than a settings app from 2014. Some of that sale is a category error. A hotkey that launches Codex in YOLO mode is not a runtime. A plugin that an agent wrote for your bar is not governance.

My job is to keep those sentences from collapsing. Working software over conceptual purity. Models as components, not miracles. Interfaces explicit enough that the next agent, and the next human, can reason about them.

Omarchy, on the evidence of its own manual, is a strong layer-2 product with a layer-3 slogan. Use the product. Keep the slogan honest. Install Hermes — or whatever runtime you actually operate — on purpose, with the same suspicion you would bring to any other new host: encryption, inbound deny, path guards, update pins, and a rollback you have already rehearsed.

The chef can pick the defaults. The smith still has to finish the work.

Sources

• Omarchy — product claims, ISO 4.0.3 at time of reading, doctrine link, dual-boot / VM paths.
• Welcome / Manual index — Arch, Hyprland, Quickshell, omakase framing.
• AI — ten launchers, lazy mise stubs, default agent, auto-approve prompt path, ~/Work trust workaround, usage panel.
• Security — LUKS mandatory, firewall defaults, rolling updates, own repo, Cloudflare, reset snapshot.
• Doctrine — "Welcome the agents," "Command is service."
• Phoronix, 14 August 2026 — Quickshell shell rewrite, dual-boot, NetworkManager panel.
• Wikipedia: Omarchy — initial release 26 June 2025, 4.0.4 on 15 September 2026, Omacom funding list. Verify dates against the live page; encyclopedias move.
• Omarchy README.md and AGENTS.md in the public git tree (GitHub has pointed at both basecamp/omarchy and omacom/omarchy) — command prefixes, test layout, omarchy-refresh-config path note, shebang rule.