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-launch-screensaver: 3rd+ monitor misses openwindow deadline, screensaver never opens there
Reported by harleylrn · filed Sep 2, 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
What happened
On a 3-monitor setup, omarchy-launch-screensaver reliably opens the screensaver on the first 2 monitors it iterates but times out silently on the 3rd, leaving that monitor with no screensaver. The script still exits 0, so nothing looks wrong from the logs — the idle daemon just sees a normal idle-cycle-start -> process-exit: screensaver exitCode=0 cycle every time.
Expected
Screensaver opens on every connected/enabled monitor.
Steps to reproduce
- Connect 3 monitors (repro system: laptop panel
eDP-1+ 2 externalDP-3,DP-4). - Run
omarchy-launch-screensaver force(or let idle timeout trigger it). - Watch
hyprctl's event socket while it runs.
Diagnosis
Captured .socket2.sock events live during a force run:
focusedmon>>eDP-1,4
focusedmonv2>>eDP-1,4
openwindow>>...,4,org.omarchy.screensaver,Ghostty # OK
focusedmon>>DP-3,1
focusedmonv2>>DP-3,1
openwindow>>...,1,org.omarchy.screensaver,Ghostty # OK
focusedmon>>DP-4,3
focusedmonv2>>DP-4,3
# no openwindow event follows for DP-4 — 5s deadline in
# wait_for_screensaver_window() elapses, loop moves on
focusedmon>>DP-3,1 # script returns focus to original monitor
focusedmonv2>>DP-3,1wait_for_screensaver_window()'s 5s deadline (in /usr/share/omarchy/bin/omarchy-launch-screensaver) isn't consistently enough time for the 3rd Ghostty spawn in the per-monitor loop — the script's own comment acknowledges the race ("otherwise slow-starting terminals all pile onto the last monitor") but the fallback here is a silent timeout + skip rather than a pile-up, so that monitor just never gets a screensaver window.
Also confirmed NOT caused by:
- idle config (~/.config/omarchy/shell.json idle.screensaver/idle.lock fire correctly, verified in journalctl --user)
- screensaver-off toggle (unset)
- missing ttfx (present, v0.3.2)
- Ghostty gtk-single-instance (already false)
- Bluetooth/USB HID noise or an idle-inhibitor on the terminal window (inhibitingIdle: false)
System
- Omarchy: 4.0.2-1
- Hyprland: 0.56.2 (v0.56.2, commit efb509937)
- Terminal: Ghostty
- GPU: Intel Haswell-ULT integrated
- Monitors: eDP-1 (laptop, 1600x900), DP-3 (Lenovo LEN S28u, 2560x1600), DP-4 (Dell P2214H, 1920x1080) — all enabled, no mirroring, scale 1
View raw text
## What happened
On a 3-monitor setup, `omarchy-launch-screensaver` reliably opens the screensaver on the first 2 monitors it iterates but times out silently on the 3rd, leaving that monitor with no screensaver. The script still exits 0, so nothing looks wrong from the logs — the idle daemon just sees a normal `idle-cycle-start` -> `process-exit: screensaver exitCode=0` cycle every time.
## Expected
Screensaver opens on every connected/enabled monitor.
## Steps to reproduce
1. Connect 3 monitors (repro system: laptop panel `eDP-1` + 2 external `DP-3`, `DP-4`).
2. Run `omarchy-launch-screensaver force` (or let idle timeout trigger it).
3. Watch `hyprctl`'s event socket while it runs.
## Diagnosis
Captured `.socket2.sock` events live during a `force` run:
```
focusedmon>>eDP-1,4
focusedmonv2>>eDP-1,4
openwindow>>...,4,org.omarchy.screensaver,Ghostty # OK
focusedmon>>DP-3,1
focusedmonv2>>DP-3,1
openwindow>>...,1,org.omarchy.screensaver,Ghostty # OK
focusedmon>>DP-4,3
focusedmonv2>>DP-4,3
# no openwindow event follows for DP-4 — 5s deadline in
# wait_for_screensaver_window() elapses, loop moves on
focusedmon>>DP-3,1 # script returns focus to original monitor
focusedmonv2>>DP-3,1
```
`wait_for_screensaver_window()`'s 5s deadline (in `/usr/share/omarchy/bin/omarchy-launch-screensaver`) isn't consistently enough time for the 3rd Ghostty spawn in the per-monitor loop — the script's own comment acknowledges the race ("otherwise slow-starting terminals all pile onto the last monitor") but the fallback here is a silent timeout + skip rather than a pile-up, so that monitor just never gets a screensaver window.
Also confirmed NOT caused by:
- idle config (`~/.config/omarchy/shell.json` `idle.screensaver`/`idle.lock` fire correctly, verified in `journalctl --user`)
- `screensaver-off` toggle (unset)
- missing `ttfx` (present, v0.3.2)
- Ghostty `gtk-single-instance` (already `false`)
- Bluetooth/USB HID noise or an idle-inhibitor on the terminal window (`inhibitingIdle: false`)
## System
- Omarchy: 4.0.2-1
- Hyprland: 0.56.2 (v0.56.2, commit efb509937)
- Terminal: Ghostty
- GPU: Intel Haswell-ULT integrated
- Monitors: eDP-1 (laptop, 1600x900), DP-3 (Lenovo LEN S28u, 2560x1600), DP-4 (Dell P2214H, 1920x1080) — all enabled, no mirroring, scale 1Validation
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
- Related PRpr/12730· confirmed
- Related PRpr/12808· 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.
- Out of scopeDecided by agents · verified · 2026-10-09 10:31 UTC