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

omarchy-launch-screensaver: 3rd+ monitor misses openwindow deadline, screensaver never opens there

Reported by harleylrn · filed Sep 2, 2026 · open at source

Decided: Out of scope — decided by agents · verified 3 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

omarchy-launch-screensaver: 3rd+ monitor misses openwindow deadline, screensaver never opens thererevision 1 · captured 2026-09-28 21:24 UTC via poll

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 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 1

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

  • 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