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.
scale = "auto" is not stable across evaluations: 2 at boot, 1.5 after hyprctl reload
Reported by andrei-himself · filed Aug 17, 2026Closed upstream on 2026-08-22 by the merge of PR #7581 (closed by dhh). GitHub close reason: completed.
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?
- Not yet mapped to any requirement or component.
- 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?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
Omarchy 4.0.0-1 (rc channel) · Hyprland 0.56.2-1
Panel: eDP-1, BOE 0x06FB, 1920x1080, physical 340x190 mm (~143 DPI)
Config: stock ~/.config/hypr/monitors.lua, byte-identical to /usr/share/omarchy/config/hypr/monitors.lua (omarchy_monitor_scale = "auto")
Repro
- Boot →
hyprctl monitors→scale: 2 hyprctl reload— no config change whatsoeverhyprctl monitors→scale: 1.5
diff against the packaged default between steps 1 and 3 confirms nothing edited the config.
Expected
The same scale at boot and after a reload. 1.5 is correct for 143 DPI, and it is what auto computes once reloaded.
Impact
Every boot comes up oversized until something happens to trigger a reload, at which point the desktop suddenly shrinks. It reads as "I broke something by editing a config" — which is exactly how I found it, after editing an unrelated hypr/*.lua file.
Workaround
Pin local omarchy_monitor_scale = 1.5 instead of "auto".
Guess
The monitor rule is applied before the panel's EDID/physical size is usable, so auto has no DPI to work from and falls back to 2.
Likely the same root cause as the auto-scale drift noted in the system details of #7021 — same panel geometry (340x190 mm), but observed in the other direction there (1.5, then recomputed as 2 after reloads). Filing separately because that issue is about XWayland/Java window overflow; this is just auto being unstable across evaluations.
View raw text
**Omarchy** 4.0.0-1 (rc channel) · **Hyprland** 0.56.2-1 **Panel:** eDP-1, BOE 0x06FB, 1920x1080, physical 340x190 mm (~143 DPI) **Config:** stock `~/.config/hypr/monitors.lua`, byte-identical to `/usr/share/omarchy/config/hypr/monitors.lua` (`omarchy_monitor_scale = "auto"`) ### Repro 1. Boot → `hyprctl monitors` → `scale: 2` 2. `hyprctl reload` — no config change whatsoever 3. `hyprctl monitors` → `scale: 1.5` `diff` against the packaged default between steps 1 and 3 confirms nothing edited the config. ### Expected The same scale at boot and after a reload. 1.5 is correct for 143 DPI, and it is what auto computes once reloaded. ### Impact Every boot comes up oversized until something happens to trigger a reload, at which point the desktop suddenly shrinks. It reads as "I broke something by editing a config" — which is exactly how I found it, after editing an unrelated `hypr/*.lua` file. ### Workaround Pin `local omarchy_monitor_scale = 1.5` instead of `"auto"`. ### Guess The monitor rule is applied before the panel's EDID/physical size is usable, so auto has no DPI to work from and falls back to 2. --- Likely the same root cause as the auto-scale drift noted in the system details of #7021 — same panel geometry (340x190 mm), but observed in the other direction there (1.5, then recomputed as 2 after reloads). Filing separately because that issue is about XWayland/Java window overflow; this is just auto being unstable across evaluations.
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
- Fixed bypr/10747· confirmed
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.
No decision has been recorded yet.