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.
omarchy hyprland monitor scaling reverts instantly when monitors.lua has per-monitor rules
Reported by Douda · filed Aug 17, 2026Closed upstream on 2026-09-21 by bjarneo via an automated message, as a duplicate of #6673 (R-1876). 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
Summary
omarchy hyprland monitor scaling (also the menu Display scale control) applies the new scale for ~0.1 s, then the monitor snaps back to the previous scale. The change can never be kept.
Environment
- Omarchy 4.0.0-1, Hyprland 0.56.2, NVIDIA (DP-2 external)
- Reproduced on a config where
~/.config/hypr/monitors.luahas explicit per-monitor rules ported from v3 (each withscale = 1) in addition to the stock catch-all.
Steps to reproduce
- In
monitors.lua, have both the stock catch-all AND an explicit rule like:
local omarchy_monitor_scale = 1.6
hl.monitor({ output = "", mode = "preferred", position = "auto", scale = omarchy_monitor_scale })
hl.monitor({ output = "DP-2", mode = "2560x1440@165", position = "1920x0", scale = 1 })- Focus DP-2 and run
omarchy hyprland monitor scaling 1.25. - Scale flashes to 1.25 then reverts to 1 within ~0.1 s.
Root cause (verified)
omarchy-hyprland-monitor-scaling does two things:
1. Applies the scale at runtime: hyprctl eval hl.monitor({... scale = 1.25}) — works.
2. Persists by sed-writing only the catch-all vars (omarchy_monitor_scale / omarchy_gdk_scale) in monitors.lua.
Hyprland auto-reloads its config on any config-file write (configreloaded event, ~30 ms later). On a config with per-monitor scale = 1 rules, the explicit rule overrides the catch-all variable, so the reload re-applies scale = 1 — reverting the tool's own runtime change. Differential test: hyprctl eval alone (no file write) holds the scale indefinitely; the revert only happens after the file write + auto-reload.
Expected
The scale change should stick (and persist). On a stock catch-all-only config this works, because the variable the tool rewrites is the value the reload reads.
Suggested fix direction
The tool should detect per-monitor hl.monitor({ output = ... }) rules and either (a) update the matching rule's scale field instead of (or in addition to) the catch-all var, or (b) skip persisting when the config deviates from the stock shape (so at least it doesn't trigger the self-reverting reload). Note clean_scale() already knows the target output; the persistence branch is where the assumption lives.
View raw text
## Summary
`omarchy hyprland monitor scaling` (also the menu Display scale control) applies the new scale for ~0.1 s, then the monitor snaps back to the previous scale. The change can never be kept.
## Environment
- Omarchy 4.0.0-1, Hyprland 0.56.2, NVIDIA (DP-2 external)
- Reproduced on a config where `~/.config/hypr/monitors.lua` has explicit per-monitor rules ported from v3 (each with `scale = 1`) in addition to the stock catch-all.
## Steps to reproduce
1. In `monitors.lua`, have both the stock catch-all AND an explicit rule like:
```lua
local omarchy_monitor_scale = 1.6
hl.monitor({ output = "", mode = "preferred", position = "auto", scale = omarchy_monitor_scale })
hl.monitor({ output = "DP-2", mode = "2560x1440@165", position = "1920x0", scale = 1 })
```
2. Focus DP-2 and run `omarchy hyprland monitor scaling 1.25`.
3. Scale flashes to 1.25 then reverts to 1 within ~0.1 s.
## Root cause (verified)
`omarchy-hyprland-monitor-scaling` does two things:
1. Applies the scale at runtime: `hyprctl eval hl.monitor({... scale = 1.25})` — works.
2. Persists by sed-writing only the catch-all vars (`omarchy_monitor_scale` / `omarchy_gdk_scale`) in `monitors.lua`.
Hyprland auto-reloads its config on any config-file write (`configreloaded` event, ~30 ms later). On a config with per-monitor `scale = 1` rules, the explicit rule overrides the catch-all variable, so the reload re-applies `scale = 1` — reverting the tool's own runtime change. Differential test: `hyprctl eval` alone (no file write) holds the scale indefinitely; the revert only happens after the file write + auto-reload.
## Expected
The scale change should stick (and persist). On a stock catch-all-only config this works, because the variable the tool rewrites *is* the value the reload reads.
## Suggested fix direction
The tool should detect per-monitor `hl.monitor({ output = ... })` rules and either (a) update the matching rule's `scale` field instead of (or in addition to) the catch-all var, or (b) skip persisting when the config deviates from the stock shape (so at least it doesn't trigger the self-reverting reload). Note `clean_scale()` already knows the target output; the persistence branch is where the assumption lives.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.
No decision has been recorded yet.