Omarchy: Linux für Entwickler mit KI-Agenten

Der neue Rechner steht auf dem Schreibtisch, das Projekt soll am Montag weiterlaufen. Was folgt, kennt jeder, der seinen Arbeitsplatz selbst baut: Arch installieren, Hyprland konfigurieren, Schriften, Tastenkürzel, Zwischenablage, Bildschirmsperre, dann Docker, dann die drei Agenten-CLIs, die inzwischen so selbstverständlich zum Werkzeugkasten gehören wie der Editor. Nichts davon ist schwer. Alles davon dauert.

Omarchy setzt genau an dieser Lücke an — und geht einen Schritt weiter als die üblichen Dotfile-Sammlungen: Die KI-Agenten sind hier nicht nachträglich installiert, sondern Teil des Systems, mit eigenem Platz in der Leiste, einem Standard-Agenten, den du selbst bestimmst, und einem eigenen Diagnose-Skill. Die Frage ist nicht, ob das im Screenshot gut aussieht, sondern ob es deine Hardware, deine Daten und deinen Arbeitsstil trägt. Was folgt, ist eine dokumentations- und quellenbasierte Einordnung mit Stand vom 3. September 2026 — kein mehrwöchiger Praxistest auf eigener Hardware, sondern eine Grundlage für deine eigene Entscheidung.

Das Wichtigste in Kürze

• Omarchy ist ein kostenloses Open-Source-System von David Heinemeier Hansson auf Basis von Arch Linux und dem Fenstermanager Hyprland, seit Version 4.0 mit Quickshell als Oberflächenschicht. Du sparst dir den Neuaufbau eines tastaturzentrierten Desktops — die Lernkurve von Tiling und Rolling Release sparst du dir nicht.
• Der eigentliche Unterschied liegt in der Agenten-Schicht: laut AI-Manual zehn vorbereitete Agenten-CLIs, ein Standard-Agent, den du per Befehl oder im Setup selbst festlegst, ein Widget für Provider- und Limit-Anzeige sowie ein Skill für Absturzdiagnosen. Agenten sind damit Systembürger statt Add-ons.
• Der Rückweg ist eingebaut, aber schmaler als er klingt: Vor Updates entstehen automatisch Snapshots, zurück geht es über das Limine-Bootmenü. Dokumentiert ist das nur für Root — nicht für /home.
• Über die Eignung entscheidet zuerst die Hardware: Dokumentiert sind x86-64-PCs und Intel-Macs (Stand: 3. September 2026), eine offizielle ARM- oder Apple-Silicon-Unterstützung war nicht auffindbar. Verschlüsselung ist Standard, Secure Boot und/oder TPM müssen laut Installer-Doku deaktiviert werden — nur eine Bluetooth-Tastatur scheitert am Boot-Passwort, kabelgebunden oder per 2,4-GHz-Dongle funktioniert es.
• Die offene Flanke ist die Reife: Die Versionen 4.0.1 und 4.0.2 haben reale, dokumentierte Sicherheitslücken geschlossen, darunter Agenten, die statt mit „auto-review“ mit vollem Bypass liefen. Security-Team und Responsible Disclosure existieren; Langzeitstabilität im Berufsalltag ist damit noch nicht belegt.

Was Omarchy anders macht als ein Arch-Setup von Hand

Omarchy ist keine neue Kernel-Welt, sondern eine Meinung, die als fertiges System ausgeliefert wird: Arch Linux als Unterbau, Hyprland als Fenstermanager, seit Version 4.0 Quickshell für Leiste, Menüs und Widgets — vorkonfiguriert, verschlüsselt, konsequent auf Tastaturbedienung ausgelegt. Wer dieselbe Kombination selbst zusammenstellt, landet bei einem ähnlichen Ergebnis: Der Unterschied ist kuratorisch, nicht technisch.

Die Meinung ist das Produkt. In einem selbstgebauten Setup verhandelst du jede Kleinigkeit einzeln — Launcher, Benachrichtigungsdienst, Terminal, Tastenkürzel. Omarchy beantwortet all das vorab und konsistent. Der Gewinn ist Zeit und Kohärenz; der Preis ist, dich in fremden Entscheidungen zurechtzufinden, bevor du sie sinnvoll änderst.

Die Versionsstände sind jung. Das Release 4.0.0 unter dem Namen Quattro stammt vom 14. August 2026, der aktuell verifizierte Stand 4.0.2 vom 31. August 2026 (Stand: 3. September 2026) — mit mehreren Releases mit dokumentierten Sicherheitskorrekturen dazwischen. Ein Projekt in aktiver Bewegung, kein System mit langer Feldbewährung; was das für die Sicherheitsbilanz bedeutet, steht weiter unten.

Weil bei einem Projekt mit prominentem Absender schnell Behauptung und Beleg durcheinandergeraten, hier die Trennung vorab:

Was sich im Agenten-Alltag konkret ändert

Der Unterschied zwischen „KI-CLIs sind installiert“ und „Agenten sind Systembürger“ zeigt sich an vier Stellen: beim Aufsetzen eines neuen Rechners, bei mehreren Abos, bei Abstürzen und bei der Konfiguration des Systems. In allen vier Fällen ersetzt Omarchy mehrere Handgriffe durch einen einzigen — mit einer Grenze, die du kennen solltest.

Ein Rechner, ein Installationsdurchlauf. Statt Arch, Hyprland, Leiste, Schriften und jede Agenten-CLI einzeln zu installieren — realistisch ein bis zwei Abende, meist Nachjustieren statt Installieren —, bootest du ein ISO und hast danach ein fertig verzahntes System. Accounts, API-Schlüssel, SSH-Schlüssel, Git-Identität und eigene Dotfiles bleiben unverändert deine Aufgabe: Omarchy verkürzt die Systemschicht, nicht deine Identitätsschicht.

Mehrere Agenten-Abos, ein Blick. Wer mit mehreren Agenten-CLIs parallel arbeitet, kennt das Problem: mehrere Anbieter, mehrere Verbrauchsanzeigen, meist erst geprüft, wenn ein Limit schon gegriffen hat. Omarchy bündelt Provider- und Limit-Status in einem Widget in der Leiste: Laut AI-Manual deckt es Claude Code, Codex und Fireworks direkt ab. Die Anzeige aktualisiert sich alle 15 Minuten und lässt sich laut Doku über mehrere Maschinen zusammenführen. Die Grenze: Ein Widget zeigt Verbrauch, es steuert ihn nicht — Abrechnung und Kostendeckelung bleiben beim jeweiligen Anbieter.

Abstürze übergeben statt auseinandernehmen. Klassisch läuft eine Absturzanalyse über Coredump und Debugger: Dump lokalisieren, Symbole passend halten, Backtrace lesen, Hypothese bilden. Omarchy bringt dafür einen eigenen Diagnose-Skill mit, der systemd-coredump überwacht: Eine abgestürzte Anwendung lässt sich an deinen Standard-Agenten übergeben — den du selbst per omarchy default agent <name> oder unter Setup > Defaults > Agent festlegst; die Frischinstallation fragt einmalig danach. Das Ergebnis ist eine gelesene Spur und eine begründete Vermutung, schneller als manuelles Debuggen, aber ohne passende Debug-Symbole bleibt es eine Hypothese. Sie ersetzt das Nachprüfen nicht, sie beschleunigt es.

Den Desktop vom Agenten umbauen lassen. Hyprland und Quickshell lassen sich über Konfigurationsdateien anpassen — mächtig, aber mühsam. Omarchy stellt dafür einen experimentell markierten Skill bereit, mit dem der Agent Desktop-Einstellungen selbst ändern kann. Diese Markierung sollte man ernst nehmen: Ein Sprachmodell schreibt hier in die Konfiguration deines Systems. Praktikabel wird das nur mit zwei Leitplanken: erst planen lassen und den Plan lesen, dann erst schreiben — und einen Rückweg haben, Versionskontrolle oder aktuellen Snapshot. Wer einem Agenten Schreibrechte gibt, sollte verstehen, wie Prompt Injection bei KI-Agenten funktioniert: Lesen fremder Inhalte plus Systemänderungsrechte sind genau die zwei Eigenschaften, aus denen echte Vorfälle entstehen.

Über den ganzen Lebenszyklus einer Maschine ergibt sich damit dieses Bild:

Wie sich der Arbeitstag mit Tiling und Hyprland anfühlt

Genau hier trifft das Titelversprechen auf den Alltag: Ein Agent braucht ein sichtbares Terminal, während du an etwas anderem weiterarbeitest — in einem Tiling-Fenstermanager teilen sich beide den Bildschirm, statt sich zu verdecken. In Omarchy ist das vorkonfiguriert: Du sagst per Tastenkombination, was wohin soll, statt mit der Maus zu ziehen.

Praktisch sieht ein Vormittag so aus: Arbeitsfläche eins Editor und Terminal nebeneinander, Arbeitsfläche zwei Browser mit Testumgebung, Arbeitsfläche drei der Agent bei einem Refactoring, dessen Ausgabe im Terminal mitläuft — das Terminal ist die Standardfläche, auf der Agenten gestartet, beobachtet und unterbrochen werden. Der Wechsel ist ein Tastendruck, kein Suchen in der Fensterleiste.

Der Preis besteht aus drei Posten: die Muskelgedächtnis-Phase mit langsameren ersten Tagen, Randfälle bei Anwendungen, die sich schlecht in feste Kacheln fügen — Videokonferenzen, manche Electron- und Java-Programme —, und Wayland-Eigenheiten, allen voran Bildschirmfreigabe. Nichts davon ist ein K.-o.-Kriterium, aber genau diese Punkte nerven an einem Dienstagvormittag mit Kundentermin.

Installation, Update und der Rückweg

Der Installer bietet zwei Wege: die gesamte Festplatte oder — seit dem Quattro-Release — freien Speicherplatz neben einem bestehenden System. Verschlüsselung ist der Standardfall; laut Installer-Doku müssen Secure Boot und/oder TPM deaktiviert werden.

Die Tastatur ist ein echtes Problem. Ein verschlüsseltes System fragt sein Passwort ab, bevor das Betriebssystem läuft — und damit bevor der Bluetooth-Stack existiert. Eine Bluetooth-Tastatur kann dieses Passwort nicht eingeben; kabelgebunden oder per 2,4-GHz-Dongle funktioniert es einwandfrei. Kläre das vor der Installation, nicht danach.

Updates kommen rollend, der Snapshot kommt automatisch. Arch als Rolling Release liefert Aktualisierungen fortlaufend — deshalb bleibt das System aktuell, deshalb kann ein Update theoretisch etwas kaputt machen. Omarchy legt vor jeder Aktualisierung automatisch einen Snapshot an: Geht etwas schief, wählst du beim Neustart im Limine-Bootmenü den vorherigen Stand, statt Live-USB und Chroot durchzustehen.

Die Grenze, die man kennen muss: Der Rollback ist laut Doku für Root gedacht, nicht für /home — Datensicherung für eigene Daten bleibt eine getrennte Aufgabe. Wichtig: Diese Rollback-Fähigkeit hängt an Limine — mit GRUB oder systemd-boot als Bootloader steht sie nicht zur Verfügung. Der Standard-Dual-Boot setzt deshalb auf Limine; ein daneben installiertes Fremdsystem trägt limine-scan ins Bootmenü ein, rollback-fähig wird es dadurch nicht. Vor einem Dual Boot mit Windows muss zusätzlich BitLocker deaktiviert sein.

Und wenn der Rechner weitergeht: Für die Übergabe an eine andere Person sieht Omarchy einen Factory Reset vor, der die Maschine in den Auslieferungszustand zurückversetzt — dokumentiert ist er nur für Installationen, die frisch mit Quattro aufgesetzt wurden, nicht für später migrierte Systeme. Für Flotten dokumentiert Omarchy zusätzlich unbeaufsichtigte Erstinstallationen aus einem Config-Image, etwa für VMs. Eine laufende zentrale Verwaltungskonsole, Mehrbenutzer-Provisionierung oder ein Geräteinventar sind dagegen nicht dokumentiert — wer fünfzig Geräte zentral betreuen will, löst damit sein Problem nicht.

Sicherheit und Reife: was die Fix-Historie verrät

Die interessanteste Information über Omarchy steht in den Release-Notes von 4.0.1 und 4.0.2. Zwischen Quattro und 4.0.2 lagen 17 Tage, in denen reale Sicherheitslücken geschlossen wurden — darunter Agenten mit vollem Bypass statt automatischer Prüfung, eine Shell-Injection, eine SSH-Härtung und signierte Pakete.

Das gute Signal: Die Lücken wurden gefunden, offengelegt, behoben und benannt. Es gibt eine Sicherheitsseite, ein Security-Team und einen Weg für Responsible Disclosure. Ein Projekt, das eigene Fehler im Klartext dokumentiert, ist berechenbarer als eines, dessen Release-Notes nur Features feiern.

Das unbequeme Signal: Diese Lücken waren in einer ausgelieferten Version enthalten — ausgerechnet in der Agenten-Schicht, wo automatisierte Prozesse Befehle auf deinem Rechner ausführen. Der Unterschied zwischen „auto-review“ und „full bypass“ ist der Unterschied zwischen einem Agenten, der fragt, und einem, der macht. Zwei Releases mit sicherheitsrelevanten Korrekturen in so kurzer Zeit sind Reaktionsfähigkeit und Jugend zugleich.

Der teuerste Denkfehler: „Lokal“ heißt nicht „meine Daten bleiben hier“. Ein Agent, der auf deinem Rechner läuft, aber über die API eines externen Anbieters denkt, schickt Code und Fehlermeldungen nach draußen — dieselbe Abwägung wie bei lokaler KI gegenüber Cloud-Modellen. Für Teams gelten dieselben Leitplanken wie beim Einsatz von KI-Agenten im Unternehmen: minimale Rechte, Freigabe für kritische Aktionen, Protokollierung.

Für wen sich der Umstieg lohnt — und für wen nicht

Die Eignungsfrage entscheidet sich an drei Dingen, in dieser Reihenfolge: Läuft es auf deiner Hardware, verträgst du Rolling Release und Tiling, und ist der Rechner ersetzbar, wenn ein Update ihn für zwei Stunden lahmlegt? Ein Nein bei Punkt eins beendet die Diskussion sofort.

Zwei Zeilen verdienen eine Erläuterung. Der Alleinrechner als Hauptgerät ist der kritischste Fall: eine teure Wette, die voraussetzt, dass du den Rollback-Weg geübt hast und ein separates Backup existiert. Der Einsteiger unterschätzt regelmäßig, dass die Vorkonfiguration den Desktop betrifft, nicht das Betriebssystem: Sobald ein Paket klemmt, stehst du in Arch, und die Antwort steht im Arch-Wiki, nicht im Omarchy-Handbuch.

Der risikoarme erste Test

Wenn du nach diesem Text neugierig bist, ist der nächste Schritt nicht „Hauptrechner neu aufsetzen“, sondern ein begrenzter Versuch mit vorher festgelegten Abbruchkriterien:

• Hardware wählen, deren Ausfall nichts kostet: Zweitrechner, alte SSD oder ausgemusterter x86-64-Laptop.
• Tastatur mit Kabel oder 2,4-GHz-Dongle bereitlegen — Bluetooth scheitert am ersten verschlüsselten Start.
• Vorab klären, welche Änderungen an Secure Boot und/oder TPM sowie einem zweiten System nötig sind, bevor der Installer läuft.
• Rollback einmal absichtlich üben, solange nichts kaputt ist — ein Rückweg, den du nie gegangen bist, ist eine Vermutung.
• Eine Woche echte Arbeit verlagern statt einer Demo-Stunde: Der Unterschied zwischen „sieht gut aus“ und „trägt“ zeigt sich am dritten Tag, wenn ein Werkzeug fehlt.
• Kriterien vorher aufschreiben: Sitzen die Tastenkürzel nach fünf Tagen? Nutzt du das Limit-Widget wirklich? Hat der Diagnose-Skill Zeit gespart?

Wer diese Fragen erst hinterher stellt, beantwortet sie mit dem Bauch.

Unterm Strich

Omarchy verkauft Zeitersparnis, verlangt aber Systemkompetenz — eine unbequeme Kombination. Wer die Arch- und Wayland-Grundlagen beherrscht, um im Ernstfall selbst zu reparieren, hätte sich das System zur Not auch selbst bauen können. Wer sie nicht beherrscht, bekommt einen wunderbar eingerichteten Desktop und im ersten Störfall ein Problem, für das die Vorkonfiguration keine Antwort hat. Der ehrliche Nutzen liegt genau dazwischen: für Leute, die es könnten, aber die Abende lieber in ihre Projekte stecken.

Der eigentlich interessante Punkt ist aber nicht der Desktop, sondern die Grundannahme dahinter. Wenn KI-Agenten dauerhaft zum Werkzeugkasten gehören, dann gehören sie ins Betriebssystem — mit einem festen Platz, sichtbaren Limits, klaren Rechten und einer Diagnose, die nicht bei jedem Anbieter neu erfunden wird. Diese Bewegung findet statt, ob Omarchy sich durchsetzt oder nicht. Die Frage ist nur, mit welcher Rechteverwaltung sie ankommt — und ob du im Zweifel sagen kannst, was der Agent auf deinem Rechner darf.