Omarchy 4: Pilot Quattro, Wait for the Security Fixes

Omarchy 4 offers a fast route from a blank PC to an opinionated Arch and Hyprland developer workstation. Its Quattro release replaces a collection of desktop utilities with one coherent Quickshell process, adds a signed package repository, preserves user configuration outside the project tree, and makes updates and system snapshots easier to operate as one workflow.

That is a meaningful product step. It is also the wrong moment to put the current stable image on a primary workstation.

On August 23, a public proof of concept demonstrated a two-action remote-code-execution path through Omarchy's Chromium video-download shortcut and its clickable completion notification. Upstream merged layered fixes for the download path and the general notification command mechanism, plus separate hardening that stops installed themes from running code. The official package repository then prepared 4.0.1rc1 with those backports. The stable channel still served 4.0.0 when checked on August 24, while the fixed release candidate was available only on edge.

The practical verdict is narrow: evaluate Omarchy 4 on spare hardware, but wait for an official stable release containing the August 23 security fixes before migrating an important workstation. Existing 4.0.0 users should avoid the Download Video shortcut and third-party theme installation or updates until the fixed stable package arrives.

This is a researched technical analysis of Omarchy 4.0.0, its current quattro branch, official package repositories, documentation, security-related pull requests, and public project state observed on August 24, 2026. OpenSourceChoice did not install Omarchy, reproduce the exploit, benchmark the shell, or validate hardware compatibility. Maintainer claims and our editorial inferences are identified as such.

Executive verdict

Why this matters now

Version 4.0.0 shipped on August 14 as Omarchy's largest release. It rebuilt the bar, launcher, menus, notifications, on-screen displays, control panels, lock screen, and polkit agent as plugins inside one long-running Quickshell process. It also moved Omarchy internals from a Git checkout into pacman packages, added dual-boot and unattended installation paths, converted the Hyprland configuration to Lua, and introduced a Git-installed plugin ecosystem.

Current interest is not limited to the release announcement. Omarchy appeared on both GitHub's daily and weekly Trending lists when checked on August 24, with GitHub displaying 750 stars gained that day and 3,660 during the week. Phoronix covered the Quattro release independently. An August 21 Hacker News discussion about the newly announced Omacom Foundation reached 187 points and 181 comments at observation time. These dynamic values establish attention, not quality.

The funding and governance story also changed. The project announced a six-person core team on August 19 and an $8 million nonprofit foundation on August 21 to hold trademarks, fund infrastructure, and support dependencies. Those moves reduce the obvious risk of one unfunded maintainer operating a popular distribution, but they are announcements rather than a track record of durable release, incident-response, or support processes.

The security event makes the adoption question urgent. The proof of concept appeared on August 23. Three related hardening changes merged that day, and the package repository committed 4.0.1rc1 shortly after midnight UTC on August 24. Searches of current Reddit, Lobsters, XDA, Product Hunt, and indexed X results did not add a comparably strong release-specific signal. The editorial case rests on a major release, measurable repository interest, active governance work, and a verified gap between the stable and edge security state—not on a single viral post.

What Omarchy is—and what it is not

Omarchy is an opinionated Arch-based desktop distribution. The project supplies an ISO, installer, package and mirror infrastructure, migrations, hardware setup, defaults, applications, themes, and a desktop shell around Hyprland. A fresh install starts on the stable channel. The documented stable Arch mirror intentionally trails current Arch packages by one month so compatibility problems can be caught before they reach stable users.

The project is more than a dotfile bundle now. Omarchy 4 packages its runtime under /usr/share/omarchy, keeps user overrides under ~/.config, runs updates and migrations together, and takes a root filesystem snapshot before the integrated update. Its installer enables LUKS disk encryption by default, and the default firewall blocks inbound traffic except LocalSend until optional services such as SSH are enabled.

Omarchy is still not:

• a long-term-support distribution with a slow security and compatibility cadence;
• an immutable or declaratively reproducible workstation;
• a central fleet-management, policy-enforcement, or compliance product;
• a sandbox for themes, plugins, shell extensions, or user-installed software;
• a full backup system for /home, dotfiles, secrets, or project data;
• a hardware-certification program covering every laptop, GPU, dock, display, biometric reader, and suspend path;
• a supported native option for Apple silicon Macs.

That distinction matters. Omarchy productizes one maintainer group's preferred desktop integration, but the operator still owns an Arch workstation and every external dependency that comes with it.

Quattro's architecture: coherence and a larger failure domain

Before version 4, separate components handled the bar, launcher, notifications, on-screen displays, locking, idle behavior, background, and polkit prompt. Quattro replaces them with plugins and services in one event-driven Quickshell instance. IPC lets the command line summon panels, change widgets, apply themes, and reload configuration.

The benefit is real. One shell can share theming, state, input behavior, scaling, and lifecycle rules instead of coordinating many daemons with different configuration formats. Omarchy can expose a consistent menu and command surface, and users can override the bar and widgets without editing the packaged core.

The trade-off is concentration. A single process now hosts UI surfaces that include notifications, the launcher, lock and authorization prompts, clipboard presentation, and status controls. That does not automatically make the system insecure, and the project restarts the shell when needed. It does mean crash, performance, parsing, and plugin boundaries deserve workstation-level testing rather than being treated as cosmetic bar issues.

Third-party plugins are especially important. The current project documentation says they are Git repositories cloned into the user's configuration, remain disabled until enabled, and run as unsandboxed code inside omarchy-shell. Updates show a diff, but the user must make the trust decision. A plugin can therefore be appropriate for a personal test machine while remaining unacceptable for a managed fleet.

The shell also does not make all user state portable. User configuration can be versioned separately, which is good. Omarchy migrations, package choices, system overrides, enabled services, firmware, and hardware-specific fixes still form an imperative machine history. Rebuilding an equivalent workstation requires more than copying ~/.config.

The stable security gap

The public proof of concept targets a convenience feature introduced in 4.0.0. Omarchy's Chromium extension can send the current page to yt-dlp with Alt + Shift + D. After a successful download, a notification offers a click action that launches mpv with the downloaded path.

Upstream pull request #7847 documents the original chain. A hostile page could place newline and tab characters in video metadata. The saved filename was restricted, but the line-oriented output still included the unsanitized title. That allowed the record parser to replace the expected path with an mpv option. The user still had to invoke the download shortcut and click the completion notification, so this was not zero-click execution. The resulting action nevertheless ran attacker-controlled behavior with the user's desktop privileges; the later general fix describes it as an RCE class.

The response has three layers:

1. Pull request #7847 validates the downloaded file, confines it to the expected directory, separates options from paths, and adds regression tests around hostile records and control characters.
2. Pull request #7926 removes shell-string interpolation from notification click actions. Actions are carried as argument vectors and executed as positional parameters, so untrusted filenames and titles remain data instead of becoming commands.
3. Pull request #7884 prevents Git-installed themes from staging files that can execute code, including Lua and terminal-launch configuration. It also rejects unsafe names and symlink paths that could escape theme directories or expose files through privileged copies.

These are upstream fixes, not independent audit results. No CVE identifier or formal GitHub security advisory was visible for them during this review, and the repository did not contain a SECURITY.md with supported versions and a private reporting process. Absence of a published advisory is not evidence that the issue is minor or that no other vulnerabilities exist.

Distribution state is the decisive detail. The official stable x86_64 mirror returned the omarchy-4.0.0-1-any package and returned 404 for 4.0.1rc1. The edge mirror returned omarchy-4.0.1rc1-1-any. The official package definition pins that release candidate to commit 286b8c2, which contains backports of all three changes. Project packaging documentation explicitly says release candidates build for edge only and never enter stable.

Do not solve that gap by casually switching an important machine to edge. Omarchy's manual warns that edge follows the latest development builds and current Arch packages, and is for users able to recover breakage. Existing 4.0.0 users have safer short-term controls:

• do not use the Chromium Download Video shortcut on untrusted pages;
• do not click its completion action;
• do not install, apply, or update third-party themes;
• keep third-party Quickshell plugins disabled unless their code and update diff are reviewed;
• monitor the official releases and stable repository for the fixed final package;
• if exposure cannot be controlled, move the affected work to a different workstation rather than hand-patching packaged files.

Before trusting the next stable version, require its release notes or pinned package commit to include the substance of #7847, #7884, and #7926. A version number alone is weaker evidence than the actual source provenance.

Installation and hardware are part of the cost

New installations use an ISO. The full-disk path wipes the selected drive, while the free-space path supports dual boot. LUKS encryption is the default in both cases, and the release publishes an SHA-256 checksum; the security manual also documents an OpenPGP signing key and .sig files for ISOs.

The official getting-started guide requires Secure Boot and/or TPM to be disabled. Windows dual-boot instructions also require BitLocker to be turned off while preparing the install. Those are not small preferences for a managed endpoint. They affect boot-chain policy, recovery-key handling, and what the organization can attest about the machine. A company with mandatory Secure Boot, measured boot, device compliance, or centrally escrowed disk recovery should treat that requirement as a rejection criterion unless its security team approves a documented alternative.

Hardware support is broad but not universal. Omarchy contains detection and setup paths for NVIDIA, Intel, AMD, Framework, Dell, Surface, ASUS, several Apple devices, and other special cases. That activity is encouraging, but a script path is not certification. The project officially supports Intel Macs with documented limitations; Apple silicon requires a community-driven Asahi route and is not directly supported. VirtualBox, VMware, Parallels, Steam Deck, and NixOS paths are described through community guides, with the manual warning that virtualized performance may be poor.

Use real target hardware for acceptance. Test every external display, dock, GPU, camera, microphone, speaker, suspend and resume cycle, encrypted boot keyboard, fingerprint reader, enterprise Wi-Fi, VPN, screen-sharing portal, printer, Bluetooth device, and firmware-update path. A visually successful VM is insufficient evidence for a daily workstation.

Updates, rollback, and the recovery boundary

The integrated update path is one of Omarchy's strongest operational choices. omarchy update coordinates the Omarchy packages, Arch packages, migrations, configuration refreshes, package-cache cleanup, and a pre-update Snapper snapshot. The project deliberately blocks ordinary direct pacman -Syu because it bypasses those steps.

The stable channel is not frozen. It tracks Omarchy final releases and a delayed Arch mirror. That can reduce immediate package breakage, but it still creates a rolling maintenance model with frequent integration work. The 72 commits between the 4.0.0 tag and the observed branch tip illustrate the current pace. Rapid fixes are good; rapid churn raises the amount of state a workstation owner must understand.

Snapshot rollback has boundaries that must be tested. It restores the root filesystem, not /home. User configuration under ~/.config stays at its current state even when older packages are restored, so a newer incompatible config can survive rollback. Bootable snapshots require Limine; installations using GRUB or systemd-boot do not receive that path. Direct boot can also hide Limine until it is selected from firmware.

A real recovery plan therefore needs all of the following:

• a separate backup of /home, keys, repositories, browser data, and dotfiles;
• a recorded ISO checksum and signature-verification procedure;
• an accessible wired or 2.4 GHz keyboard for encrypted boot;
• a tested Limine snapshot restore after a representative update;
• an offline route to restore or reinstall when networking and the desktop shell are unavailable;
• a second machine for credentials, documentation, and emergency work.

If losing the workstation for one day would stop the business, the pilot is not ready.

Privacy, external services, and customization trust

The primary desktop runs locally, and no mandatory hosted Omarchy account is documented. That does not make every workflow offline. Package and ISO infrastructure, Git-based themes and plugins, weather, optional Dropbox and Tailscale panels, web applications, browser downloads, firmware, and optional AI agents all create network boundaries chosen by the user.

Quattro also centralizes locally sensitive state. Clipboard history can contain images and text, notification history can replay recent messages, and the shell can expose model-usage information from installed agent harnesses. The release says sensitive clipboard content is excluded, but OpenSourceChoice did not test those heuristics. Treat clipboard and notification state as sensitive user data, particularly on shared or regulated machines.

Agent integration deserves separate controls. Omarchy can lazy-install and launch several coding agents and offers a temporary passwordless-sudo mode. The security manual correctly warns that, while enabled, any process running as the user can act as root without another prompt. Do not combine a new desktop pilot, unreviewed agent permissions, third-party plugins, and passwordless sudo in the same evaluation phase. Establish the workstation boundary first, then add one integration at a time.

License, governance, and portability

Omarchy's repository uses the MIT license, which permits commercial use, modification, redistribution, and sublicensing subject to its notice. Individual Arch packages, bundled applications, themes, and external services retain their own licenses and terms. The MIT license removes a source-code licensing lock-in, but it does not make the branded infrastructure, package mirrors, or every preinstalled application interchangeable.

Portability is moderate. Plain-text user configuration, standard Arch packages, Hyprland Lua, and common Linux data formats make individual workflows recoverable. Omarchy-specific migrations, menu definitions, shell plugins, package mirrors, and hardware helpers make the assembled desktop harder to reproduce elsewhere. There is no supported in-place conversion from Omarchy to Fedora, NixOS, or plain Arch; a clean reinstall plus data and dotfile migration is the safer exit plan.

Governance is improving but still concentrated. The new core team names five contributors alongside DHH, and the foundation creates a substantial funding runway. In the 30-day Git history observed on August 24, 344 of 475 commits carried David Heinemeier Hansson's author name. That simple author count includes merges and cannot calculate a true bus factor, but it shows that implementation leadership remains concentrated despite broader formal ownership.

The right conclusion is neither “one-person project” nor “institutionally mature distribution.” Omarchy is an unusually active young project that is building the people and infrastructure needed for durability. Teams should judge the next six to twelve months of releases, incident communication, signed artifacts, security reporting, and succession in practice.

Alternatives to evaluate in parallel

Fedora Sway Atomic is the most useful parallel test for teams. It does not reproduce Omarchy's design, but it tests whether the real requirement is a keyboard-first Wayland desktop or the exact Quattro experience. NixOS is the stronger comparison when reproducibility and fleet configuration matter more than immediate usability.

A measurable workstation pilot

1. Wait for the stable security gate

Track official releases and the stable package mirror. Start the important-machine pilot only after a final version includes the fixes from #7847, #7884, and #7926. Record the tag, package version, pinned source commit, ISO checksum, signature result, and installation date.

2. Use spare target hardware

Install on a dedicated SSD or secondary laptop whose loss is acceptable. Do not begin by repartitioning the only Windows or macOS machine. Keep Secure Boot, TPM, BitLocker, and organizational compliance requirements in the written go/no-go checklist.

3. Establish recovery before customization

Create an encrypted off-device backup, complete one update, boot the previous Limine snapshot, restore it, and separately restore representative /home data. Require another machine to hold the recovery instructions and credentials.

4. Keep the trust surface minimal

Use built-in themes only. Keep third-party plugins, AI agents, passwordless sudo, browser download helpers, and optional cloud panels disabled during the baseline. Enable one item only after reviewing its repository, update behavior, permissions, outbound connections, and rollback.

5. Exercise real work for five business days

Test source builds, containers, IDE or terminal workflows, video calls, screen sharing, suspend and resume, docking, all displays, audio, Bluetooth, printers, VPN, enterprise Wi-Fi, encrypted boot, firmware updates, and battery behavior. Record failures, recovery time, and any workaround that modifies packaged files.

6. Test update discipline

Run only the supported Omarchy update path. Confirm a snapshot is actually created, migrations finish, user overrides survive, and no .pacnew or configuration mismatch is silently ignored. Roll back one test update and confirm applications still understand the retained /home configuration.

7. Define adoption thresholds

Adopt for one technical user only if:

• the fixed final package is on stable;
• the ISO and packages verify against official signatures;
• no required hardware or security-policy feature remains unsupported;
• five workdays complete without a data-loss or unrecoverable session failure;
• root rollback completes within 20 minutes;
• representative /home data restores within the recovery objective;
• no third-party plugin or theme is needed for critical work;
• an alternate workstation is immediately available.

Fleet adoption needs additional evidence: centralized inventory, staged update rings, security-notification ownership, documented exceptions for Secure Boot and TPM, configuration management, incident response, and a support model beyond community Discord. Omarchy's unattended installer helps repeat installation; it does not supply those controls.

Final assessment

Omarchy 4 is a substantial desktop product, not merely a screenshot-friendly set of dotfiles. Quattro's unified shell, packaged runtime, integrated updates, snapshots, encryption defaults, hardware helpers, and growing governance can save an experienced user weeks of assembly.

The same integration widens the consequence of mistakes. Version 4.0.0 added a browser-download and notification chain that enabled user-assisted remote code execution, while its third-party theme path could stage executable configuration. Upstream responded quickly and built the fixes into 4.0.1rc1, which is a positive maintenance signal. The stable distribution gap remains the fact that matters to adopters.

Pilot Omarchy on spare hardware and evaluate the whole workstation, not just its appearance. Wait for the fixed final package before moving important work. If atomic upgrades, Secure Boot policy, reproducible configuration, or fleet governance are hard requirements, evaluate Fedora Sway Atomic or NixOS in parallel and be prepared to reject Omarchy even after the immediate security fixes ship.

Sources and verification notes

Project, release, package, repository, documentation, security-fix, governance, alternative, and community state were checked on August 24, 2026. Dynamic counts are dated discovery or maintenance signals, not quality guarantees. Technical conclusions are OpenSourceChoice editorial analysis, not claims of hands-on validation.

Primary and official sources

• Omarchy v4.0.0 release notes — Omarchy maintainers; released August 14, 2026; Quattro architecture, installation checksum, features, migration path, and bundled Download Video shortcut.
• Omarchy repository and quattro commit history — current source and maintenance state observed August 24, 2026.
• Getting Started — current official manual; ISO paths, disk wipe, encryption, Secure Boot/TPM requirement, and unattended installation.
• Updates and system snapshots — current official manual; channels, delayed stable mirror, integrated update, root-only rollback, and Limine boundary.
• Security manual — current official manual; LUKS, firewall, SSH, passwordless sudo, package trust, signing key, and ISO signatures.
• Omarchy shell architecture — current project documentation; single Quickshell process, plugins, configuration, IPC, and unsandboxed third-party code.
• Pull request #7847 — Omarchy maintainers and contributors; merged August 23, 2026; video-title/download-path exploit analysis, mitigations, and regression tests.
• Pull request #7926 — Omarchy maintainers; merged August 23, 2026; notification click actions moved from shell strings to argument vectors and RCE-class scope.
• Pull request #7884 — Omarchy maintainers; merged August 23, 2026; Git-installed theme code filtering, path validation, symlink hardening, and residual trust boundary.
• Omarchy packages commit e5fb86e — official packaging source; 4.0.1rc1 pinned on August 24, 2026 to backports containing the three security fixes.
• Omarchy package repository documentation — official package workflow; edge/stable promotion and the rule that release candidates never reach stable.
• Stable 4.0.0 package and edge 4.0.1rc1 package — official repository artifacts returning HTTP 200 on August 24, 2026; the RC artifact returned 404 on stable.
• Omarchy MIT license at v4.0.0 and repository security page — license and published policy/advisory state observed August 24, 2026.
• Omarchy Core Team announcement — official project announcement; published August 19, 2026; six-person core team and stated responsibilities.
• Omacom Foundation announcement — official project announcement; published August 21, 2026; funding and infrastructure mission.
• Fedora Sway Atomic and Fedora Sway Atomic 44 download — Fedora Project; current atomic Sway scope, signed media, release, and system requirements.
• NixOS stable manual and Archinstall manual — official alternative installation, declarative generation, rollback, and disk-encryption references checked August 24, 2026.

Security report and trend context

• Omarchy public proof of concept — Mehmet Ince; observed August 23–24, 2026; two-action exploit demonstration. Technical conclusions above rely on upstream reproduction and fixes, not the demonstration page alone.
• GitHub Trending — observed August 24, 2026; daily and weekly interest signal.
• Hacker News discussion of the Omacom Foundation — August 21, 2026; independent discussion and current attention signal.
• Phoronix coverage of Omarchy 4.0 — Michael Larabel; August 14, 2026; independent release coverage.