Omarchy for AI Developers: What Is Stable and What Is Still a Preview

As of 3 November 2026. This assessment is based on release notes, the manual and source code. It is not a hands-on test on our own hardware.

Omarchy is a Linux distribution built on Arch Linux. Hyprland and Quickshell provide its desktop foundation: tiling automatically arranges windows next to each other. The desktop, tools and launchers come preconfigured. That can appeal to developers moving between an editor, a browser and several AI agents. This preconfiguration also creates a second job: understanding which decisions the project has made on your behalf.

Much has changed since our first assessment, including further security fixes, more agent integrations and a larger redesign in preparation. The central question is now: Which version are you installing, and what authority does an agent receive when you launch it conveniently from the desktop?

Key takeaways

• Omarchy combines a configured desktop with developer tools. Linux knowledge remains valuable when something goes wrong.
• The stable working environment and the preview of the next feature release need separate assessments.
• Agent approvals, system privileges and data protection are three distinct decisions. A convenient interface does not make them for you.
• A useful trial checks your actual workflows and your recovery route. An attractive desktop alone cannot establish suitability.

Two development tracks, two decisions

RC3 lists an Apple Silicon installer for M1, M2, M3 and Neo, an aarch64 ISO, 50 interface languages and the F1 installer. This preview establishes neither stable availability nor suitability for every ARM device.

There is another complication: the continuously updated manual already describes preview features. Read instructions alongside the relevant version and channel. A menu entry on today’s documentation page may not exist on an older installation. Nor is a processor-family name enough information for a purchase: check the particular model and the functions you cannot work without.

What changed in the stable system

Omarchy is more than a collection of desktop settings. Since 4.0.4, its own linux-omarchy kernel has been the default. Project maintenance therefore matters beneath the visible interface too. Release-note claims about responsiveness or hardware improvements remain provider claims until evaluated on your hardware.

The agent layer has also grown. 4.0.3 added integrations including Hermes and OpenClaw. 4.0.5 changed how they update; 4.0.6 fixes problems with the OpenClaw migration and locking before suspend. If you previously installed OpenClaw yourself, read the version-specific note before applying a generic repair command.

The practical point is that an operating-system update and an agent update are not always the same event. In the 4.0.6 default-agent selector, Hermes and OpenClaw have their own installation paths; other tools are integrated through mise. A separately installed CLI may exist alongside them. When a command behaves differently from yesterday, its installation source and the version actually launched belong in the investigation.

Look closely at the agent launcher

The 4.0.6 launcher deliberately starts different agents with different automatic approval modes. These range from automated review to bypass modes; they do not mean that a person confirms every step. A mode’s name also does not establish which sandbox the particular tool uses.

Keep three layers separate when assessing a workstation:

This is a review framework, not a shared security architecture for all the available agents. A tool can ask few questions while remaining technically constrained. Another may have extensive access to files belonging to your user account. The specific combination matters.

Passwordless sudo reaches further. The 4.0.6 implementation explicitly warns that, while enabled, any process running as your user can execute administrative commands without a password. The grant is not reserved for the agent you happen to trust. Ordinary project work should not casually acquire this extra authority.

Consider a hypothetical task: an agent needs to fix a bug in a local web project. It needs the relevant project files and appropriate test commands. Access to private documents or system-wide changes does not automatically follow. A well-defined task and a bounded working environment make its results easier to assess. Our guide to prompt injection explains the wider issue.

Security fixes are evidence, not a blanket assurance

Development since September includes concrete hardening work. 4.0.3 restricts plugin access to authentication services, among other changes. 4.0.5 removes unsafe automatic PATH changes in project directories and corrects handling of root password hashes during factory reset.

Two reasonable conclusions follow: older installations deserve attention, and the project identifies security-related changes. Neither establishes that every Omarchy machine is unsafe or that the newest release has passed an independent security certification. Likewise, a preview’s fix list does not tell you which stable installations are affected without examining the relevant code.

For teams, this is a practical governance question. Omarchy curates the kernel, packages and agent launch behaviour. Adopting those choices means deciding who approves updates, records deviations and restores a workstation when something fails. Open source makes inspection easier; it does not carry out these operational responsibilities.

Updates: a separate channel and a limited way back

The update manual describes Stable as using its own Arch mirror roughly a month behind current packages. RC, Edge and Dev serve different purposes. Being based on Arch therefore does not mean every machine always receives the same newest packages as an unmodified Arch installation.

Use the intended Omarchy updater so packages and migrations run together. Its 4.0.6 implementation attempts to create a snapshot first, but can continue with a warning if that fails. A completed update is therefore not proof that a recovery point exists.

The documented snapshot rollback requires Limine and restores root, not /home. Personal configuration under ~/.config remains in place too. After a rollback, an older application may encounter newer user configuration. That matters if you expect absolutely everything to return to its previous state.

A dependable recovery route has three separate parts: an existing system snapshot, a way to reach recovery, and an independent backup of working data. Practise while a failure would not jeopardise a deadline or client work. The installation guide covers preparation for the stable x86 route.

How to assess it for your workstation

Use a machine whose failure you can absorb, with your data backed up. Choose a small but representative workflow: open a project, set up its dependencies, run tests, debug in the browser, make a video call with screen sharing, then suspend and resume. On a laptop, include an external display, audio and network changes where relevant.

This is a suggested evaluation plan, not a hardware test we have performed. Its purpose is to make your decision depend on the things that determine your working day. If an essential tool is missing or the recovery route fails, the trial can end even if you like the rest of the desktop.

Then assess two questions separately: Does the environment suit your work? Can you maintain it? Tiling may improve window organisation, but it has to fit your applications and habits. Preconfigured agents may shorten workflows without justifying unconsidered access rights.

For an experienced Linux user with clear requirements, Omarchy is a working environment worth evaluating. Someone with an existing, reliable setup needs a specific reason to switch. And anyone waiting for a new hardware platform should treat a promising preview as an invitation to test, rather than a proven replacement for their main machine.

Sources and limits

Checked on 3 November 2026. Release status and code references below are pinned to versions; the manual changes continuously. Performance claims were not confirmed through our own measurements.

• Technical foundations in 4.0.6
• Stable 4.0.6 and 4.5.0-rc3
• 4.0.3, 4.0.4 and 4.0.5
• Agent launcher, agent selector, sudo grant and updater, all at 4.0.6
• Update channels and snapshot boundaries