Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.

Inbox
ReportR-1864GitHub issuePublicDecided· Out of scope

Omarchy-settings upgrades revert the custom Plymouth/SDDM unlock-screen theme chosen via Style → Unlock

Reported by brink-lab · filed Aug 14, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 4 days ago.

At a glance

1 · What is claimed?
Only the report text below — no validator has restated it as checkable claims yet.
2 · What does it affect?
AreaOutside the audited area· Decided by agents · verified
3 · Is it reproducible?
No validation has been run yet.
4 · What remains unclear?
  • Not validated yet: no claims, no reproducer.
5 · What happens next?
Decided by agents and verified by a second, independent agent — see the decision.

Original report

Omarchy-settings upgrades revert the custom Plymouth/SDDM unlock-screen theme chosen via Style → Unlockrevision 1 · captured 2026-09-28 21:29 UTC via poll

System details

  • Omarchy 4.0.0rc5-1 (channel: rc), Linux 7.1.8-arch1-3 x86_64, Hyprland 0.56.2, SDDM, Apple MacBookPro9,2 (i5-3210M / i915), LUKS-encrypted root (Plymouth shows the LUKS prompt), Limine + initramfs_async=0 quiet splash.

What's wrong?

Description

Setting a custom unlock screen (menu → Style → Unlock, i.e. omarchy plymouth set-by-theme) works at the moment, but the change is silently lost on the next `omarchy update`. The boot/login splash (Plymouth, incl. the LUKS prompt) and the SDDM logout screen revert to the default green/yellow "Omarchy" theme.

Expected

The unlock-screen selection should persist across omarchy update, the way omarchy theme set does (~/.local/state/omarchy/current/theme.name + staged theme files are preserved and re-applied).

Actual

After upgrading the omarchy-settings package, /usr/share/plymouth/themes/omarchy/ and /usr/share/sddm/themes/omarchy/ are restored to the packaged defaults. The selection is not recorded anywhere, so there is nothing to re-apply.

Steps to reproduce

  1. omarchy plymouth set-by-theme <theme> (or pick one via menu → Style → Unlock), e.g. vantablack. Verified applied: omarchy plymouth current → <theme>.
  2. Run omarchy update such that omarchy-settings is upgraded.
  3. omarchy plymouth current now reports default, and the boot/login splash is the default again.

Root cause

  • omarchy-plymouth-set writes the recolored assets and chosen logo directly into package-owned directories:
  • /usr/share/plymouth/themes/omarchy/ (owned by omarchy-settings, e.g. logo.png, omarchy.script)
  • /usr/share/sddm/themes/omarchy/ (owned by omarchy-settings, e.g. Main.qml, logo.png)
  • omarchy update runs pacman -Syu (omarchy-update-system-pkgs), which upgrades omarchy-settings and restores those files to the shipped defaults.
  • Unlike theme switching, omarchy-plymouth-set / set-by-theme persist no state and nothing re-applies the selection afterwards — omarchy-migrate and the post-update hooks never touch plymouth/sddm.

Suggested fix

  1. Persist the applied selection (theme name, or colors + logo path) to a user-writable state file when omarchy-plymouth-set runs, mirroring how omarchy-theme-set writes ~/.local/state/omarchy/current/theme.name.
  2. Re-apply the recorded selection after the package step of omarchy update (e.g. a pacman hook on omarchy-settings, or a step in omarchy-update), and after omarchy-refresh-plymouth.
  3. Alternatively, stop packaging runtime copies in /usr/share/plymouth/themes/omarchy/ and /usr/share/sddm/themes/omarchy/ (ship only /usr/share/omarchy/default/...) so package upgrades can't clobber user customization.

Evidence

  • /var/log/pacman.log: [2026-08-14T11:46:32] [ALPM] upgraded omarchy-settings (4.0.0rc4-1 -> 4.0.0rc5-1) — splash reverted here.
  • Customized assets in both dirs dated Aug 14 13:17 (the manual re-apply), upstream of the 11:46 package upgrade.
  • pacman -Qo: /usr/share/plymouth/themes/omarchy/logo.png and /usr/share/sddm/themes/omarchy/Main.qml are owned by omarchy-settings.

System

  • Omarchy 4.0.0rc5-1 (channel: rc), Linux 7.1.8-arch1-3 x86_64, Hyprland 0.56.2, SDDM, Apple MacBookPro9,2 (i5-3210M / i915), LUKS-encrypted root (Plymouth shows the LUKS prompt), Limine + initramfs_async=0 quiet splash.
View raw text
### System details

- Omarchy 4.0.0rc5-1 (channel: rc), Linux 7.1.8-arch1-3 x86_64, Hyprland 0.56.2, SDDM, Apple MacBookPro9,2 (i5-3210M / i915), LUKS-encrypted root (Plymouth shows the LUKS prompt), Limine + `initramfs_async=0 quiet splash`.

### What's wrong?

## Description

Setting a custom unlock screen (menu → Style → Unlock, i.e. `omarchy plymouth set-by-theme`) works at the moment, but the change is **silently lost on the next `omarchy update`**. The boot/login splash (Plymouth, incl. the LUKS prompt) and the SDDM logout screen revert to the default green/yellow "Omarchy" theme.

## Expected

The unlock-screen selection should persist across `omarchy update`, the way `omarchy theme set` does (`~/.local/state/omarchy/current/theme.name` + staged theme files are preserved and re-applied).

## Actual

After upgrading the `omarchy-settings` package, `/usr/share/plymouth/themes/omarchy/` and `/usr/share/sddm/themes/omarchy/` are restored to the packaged defaults. The selection is not recorded anywhere, so there is nothing to re-apply.

## Steps to reproduce

1. `omarchy plymouth set-by-theme <theme>` (or pick one via menu → Style → Unlock), e.g. `vantablack`. Verified applied: `omarchy plymouth current` → `<theme>`.
2. Run `omarchy update` such that `omarchy-settings` is upgraded.
3. `omarchy plymouth current` now reports `default`, and the boot/login splash is the default again.

## Root cause

- `omarchy-plymouth-set` writes the recolored assets and chosen logo **directly into package-owned directories**:
  - `/usr/share/plymouth/themes/omarchy/` (owned by `omarchy-settings`, e.g. `logo.png`, `omarchy.script`)
  - `/usr/share/sddm/themes/omarchy/` (owned by `omarchy-settings`, e.g. `Main.qml`, `logo.png`)
- `omarchy update` runs `pacman -Syu` (`omarchy-update-system-pkgs`), which upgrades `omarchy-settings` and restores those files to the shipped defaults.
- Unlike theme switching, `omarchy-plymouth-set` / `set-by-theme` **persist no state** and **nothing re-applies the selection afterwards** — `omarchy-migrate` and the `post-update` hooks never touch plymouth/sddm.

## Suggested fix

1. Persist the applied selection (theme name, or colors + logo path) to a user-writable state file when `omarchy-plymouth-set` runs, mirroring how `omarchy-theme-set` writes `~/.local/state/omarchy/current/theme.name`.
2. Re-apply the recorded selection after the package step of `omarchy update` (e.g. a pacman hook on `omarchy-settings`, or a step in `omarchy-update`), and after `omarchy-refresh-plymouth`.
3. Alternatively, stop packaging runtime copies in `/usr/share/plymouth/themes/omarchy/` and `/usr/share/sddm/themes/omarchy/` (ship only `/usr/share/omarchy/default/...`) so package upgrades can't clobber user customization.

## Evidence

- `/var/log/pacman.log`: `[2026-08-14T11:46:32] [ALPM] upgraded omarchy-settings (4.0.0rc4-1 -> 4.0.0rc5-1)` — splash reverted here.
- Customized assets in both dirs dated `Aug 14 13:17` (the manual re-apply), upstream of the 11:46 package upgrade.
- `pacman -Qo`: `/usr/share/plymouth/themes/omarchy/logo.png` and `/usr/share/sddm/themes/omarchy/Main.qml` are owned by `omarchy-settings`.

## System

- Omarchy 4.0.0rc5-1 (channel: rc), Linux 7.1.8-arch1-3 x86_64, Hyprland 0.56.2, SDDM, Apple MacBookPro9,2 (i5-3210M / i915), LUKS-encrypted root (Plymouth shows the LUKS prompt), Limine + `initramfs_async=0 quiet splash`.

Validation

Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.

Linked

Not linked to any known issue, other report or change yet.

Decision

Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.

  • Out of scopeDecided by agents · verified · 2026-10-09 04:05 UTC