Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA 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.
Quattro upgrade replaces customized monitors.conf with default monitors.lua (auto layout, GDK_SCALE=2) without porting or warning
Reported by daventhedude · filed Aug 15, 2026 · open at source
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
System details
AMD Ryzen 7 7800X3D, NVIDIA RTX 4070, Omarchy 3.8.4 → 4.0.0-1 (Quattro upgrade on 2026-08-15), triple 1440p setup (2× HP Z27i, 1× HP X27q 165 Hz)
What's wrong?
The upgrade-to-Quattro migration creates ~/.config/hypr/monitors.lua from the stock template and silently stops loading the user's customized ~/.config/hypr/monitors.conf.
Unlike the other configs the upgrade touches (waybar, mako, hyprsunset, brave-flags — all parked as *.omarchy-upgrade-to-quattro.<ts>.bak), monitors.conf is left in place but unreferenced: no .bak, no mention in the upgrade output. There is no breadcrumb telling the user their display configuration stopped applying.
After relogin, a multi-monitor user lands in:
- auto layout — the template only contains
hl.monitor({ output = "", mode = "preferred", position = "auto", scale = omarchy_monitor_scale }),
so my portrait monitor came up landscape and all positions were wrong
- GDK_SCALE=2 from the template (local omarchy_gdk_scale = 2), while my monitors.conf had env = GDK_SCALE,1 — so GTK apps also rendered at the wrong scale on 1440p @ scale 1
Steps to recreate
- On Omarchy 3.8.x, have a customized
~/.config/hypr/monitors.conf(mine: three 1440p monitors matched bydesc:, one withtransform, 1, one withvrr, 2, plusenv = GDK_SCALE,1) - Run the upgrade to Quattro (
omarchy update→ accept the invite) - Relogin:
~/.config/hypr/monitors.luacontains only the template defaults;monitors.confis ignored
Expected
Either the migration ports the simple monitor = / env = GDK_SCALE lines into hl.monitor() / hl.env() calls, or — probably the pragmatic 80% fix — monitors.conf gets the same .bak treatment as the other configs plus a line in the upgrade summary, so users immediately know to redo their display setup in monitors.lua.
Workaround
Rewriting monitors.lua by hand restores everything, e.g.:
hl.env("GDK_SCALE", "1")
hl.monitor({ output = "desc:Hewlett Packard HP Z27i CNK4040DPF", mode = "2560x1440@60", position = "0x0", scale = 1, transform = 1 })
hl.monitor({ output = "desc:HP Inc. HP X27q 6CM3262XR9", mode = "2560x1440@165", position = "1440x560", scale = 1, vrr = 2 })
hl.monitor({ output = "desc:Hewlett Packard HP Z27i CNK4040DJW", mode = "2560x1440@60", position = "4000x560", scale = 1 })Apart from this, the upgrade went remarkably smoothly here — and the new Lua config plus the bundled agent docs (skills/omarchy/hyprland.md) made the manual fix easy to figure out. Thanks a lot for Quattro!
View raw text
### System details
AMD Ryzen 7 7800X3D, NVIDIA RTX 4070, Omarchy 3.8.4 → 4.0.0-1 (Quattro upgrade on 2026-08-15), triple 1440p setup (2× HP Z27i, 1× HP X27q 165 Hz)
### What's wrong?
The upgrade-to-Quattro migration creates `~/.config/hypr/monitors.lua` from the stock template and silently stops loading the user's customized `~/.config/hypr/monitors.conf`.
Unlike the other configs the upgrade touches (waybar, mako, hyprsunset, brave-flags — all parked as `*.omarchy-upgrade-to-quattro.<ts>.bak`), `monitors.conf` is left in place but unreferenced: no `.bak`, no mention in the upgrade output. There is no breadcrumb telling the user their display configuration stopped applying.
After relogin, a multi-monitor user lands in:
- auto layout — the template only contains
`hl.monitor({ output = "", mode = "preferred", position = "auto", scale = omarchy_monitor_scale })`,
so my portrait monitor came up landscape and all positions were wrong
- `GDK_SCALE=2` from the template (`local omarchy_gdk_scale = 2`), while my `monitors.conf` had `env = GDK_SCALE,1` — so GTK apps also rendered at the wrong scale on 1440p @ scale 1
**Steps to recreate**
1. On Omarchy 3.8.x, have a customized `~/.config/hypr/monitors.conf` (mine: three 1440p monitors matched by `desc:`, one with `transform, 1`, one with `vrr, 2`, plus `env = GDK_SCALE,1`)
2. Run the upgrade to Quattro (`omarchy update` → accept the invite)
3. Relogin: `~/.config/hypr/monitors.lua` contains only the template defaults; `monitors.conf` is ignored
**Expected**
Either the migration ports the simple `monitor =` / `env = GDK_SCALE` lines into `hl.monitor()` / `hl.env()` calls, or — probably the pragmatic 80% fix — `monitors.conf` gets the same `.bak` treatment as the other configs plus a line in the upgrade summary, so users immediately know to redo their display setup in `monitors.lua`.
**Workaround**
Rewriting `monitors.lua` by hand restores everything, e.g.:
```lua
hl.env("GDK_SCALE", "1")
hl.monitor({ output = "desc:Hewlett Packard HP Z27i CNK4040DPF", mode = "2560x1440@60", position = "0x0", scale = 1, transform = 1 })
hl.monitor({ output = "desc:HP Inc. HP X27q 6CM3262XR9", mode = "2560x1440@165", position = "1440x560", scale = 1, vrr = 2 })
hl.monitor({ output = "desc:Hewlett Packard HP Z27i CNK4040DJW", mode = "2560x1440@60", position = "4000x560", scale = 1 })
```
Apart from this, the upgrade went remarkably smoothly here — and the new Lua config plus the bundled agent docs (`skills/omarchy/hyprland.md`) made the manual fix easy to figure out. Thanks a lot for Quattro!
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:07 UTC