Proof Portal

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-1776GitHub issuePublicDecided· Out of scope

The White unlock theme paints the SDDM login screen black on black

Reported by omarchybot · filed Aug 16, 2026 · 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

The White unlock theme paints the SDDM login screen black on blackrevision 1 · captured 2026-09-28 21:29 UTC via poll

System details: Omarchy quattro @ 7488eade (post-4.0.0), QEMU/KVM VM. Found by an automated QA pass; reproduced on a disposable worker VM.

Choosing Style → Unlock → White gives a login screen that is a solid black rectangle — background, password field, lock glyph and bullets all #000000.

bin/omarchy-plymouth-set:70-73 syncs the SDDM greeter with two sed expressions applied in sequence to the same stream:

sed \
  -e "s/#1a1b26/#$bg_hex/g" \
  -e "s/#ffffff/#$text_hex/g" \
  "$sddm_template" | sudo tee "$sddm_dir/Main.qml" >/dev/null

For the white theme bg_hex=ffffff and text_hex=000000. The first expression rewrites the background placeholder to #ffffff; the second immediately matches that same text and rewrites it to #000000.

default/sddm/omarchy/Main.qml contains no #ffffff of its own — all greeter text is images — so the second expression is dead code for every theme except the one where it lands on the output of the first:

$ grep -c 'ffffff' default/sddm/omarchy/Main.qml
0
$ grep -n '1a1b26' default/sddm/omarchy/Main.qml
8:  color: "#1a1b26"

Confirmed on a worker:

$ omarchy-plymouth-set-by-theme white
$ grep -n "color:" /usr/share/sddm/themes/omarchy/Main.qml | head -1
8:  color: "#000000"          # themes/white/colors.toml has background = "#ffffff"

$ magick /usr/share/sddm/themes/omarchy/lock.png -resize 1x1! -alpha off -format "%[hex:u.p{0,0}]" info:-
000000                        # lock glyph, recoloured to foreground = #000000

# controls, same command:
gruvbox       -> 8:  color: "#282828"    correct
flexoki-light -> 8:  color: "#FFFCF0"    correct, glyph 100F0F

Plymouth takes a different path and is correct, so the boot splash is white and only the greeter is dead. white is the only shipped theme whose background is #ffffff, which is why nothing else shows it.


Correction, after an independent review of this report:

The original overstated it. The greeter is not a solid black rectangle and is not dead: the logo is drawn from an unrecoloured logo.png (default/sddm/omarchy/Main.qml:37), the focused password field still accepts input, and a failed login shows the red assets. What is black-on-black is the background and the normal-state password controls.

View raw text
**System details:** Omarchy `quattro` @ 7488eade (post-4.0.0), QEMU/KVM VM. Found by an automated QA pass; reproduced on a disposable worker VM.

Choosing Style → Unlock → **White** gives a login screen that is a solid black rectangle — background, password field, lock glyph and bullets all `#000000`.

`bin/omarchy-plymouth-set:70-73` syncs the SDDM greeter with two `sed` expressions applied in sequence to the same stream:

```sh
sed \
  -e "s/#1a1b26/#$bg_hex/g" \
  -e "s/#ffffff/#$text_hex/g" \
  "$sddm_template" | sudo tee "$sddm_dir/Main.qml" >/dev/null
```

For the `white` theme `bg_hex=ffffff` and `text_hex=000000`. The first expression rewrites the background placeholder to `#ffffff`; the second immediately matches that same text and rewrites it to `#000000`.

`default/sddm/omarchy/Main.qml` contains no `#ffffff` of its own — all greeter text is images — so the second expression is dead code for every theme *except* the one where it lands on the output of the first:

```
$ grep -c 'ffffff' default/sddm/omarchy/Main.qml
0
$ grep -n '1a1b26' default/sddm/omarchy/Main.qml
8:  color: "#1a1b26"
```

Confirmed on a worker:

```
$ omarchy-plymouth-set-by-theme white
$ grep -n "color:" /usr/share/sddm/themes/omarchy/Main.qml | head -1
8:  color: "#000000"          # themes/white/colors.toml has background = "#ffffff"

$ magick /usr/share/sddm/themes/omarchy/lock.png -resize 1x1! -alpha off -format "%[hex:u.p{0,0}]" info:-
000000                        # lock glyph, recoloured to foreground = #000000

# controls, same command:
gruvbox       -> 8:  color: "#282828"    correct
flexoki-light -> 8:  color: "#FFFCF0"    correct, glyph 100F0F
```

Plymouth takes a different path and is correct, so the boot splash is white and only the greeter is dead. `white` is the only shipped theme whose background is `#ffffff`, which is why nothing else shows it.

---

**Correction, after an independent review of this report:**

The original overstated it. The greeter is not a solid black rectangle and is not dead: the logo is drawn from an unrecoloured `logo.png` (`default/sddm/omarchy/Main.qml:37`), the focused password field still accepts input, and a failed login shows the red assets. What is black-on-black is the background and the normal-state password controls.

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:23 UTC