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.
Screensaver closes after ~1s as a small square when the clock calendar popup is open
Reported by SteelOverseer · filed Sep 25, 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: Intel i7-1355U, Intel Iris Xe (i915), System76 Lemur Pro, single eDP-1 display, Omarchy 4.0.4-1, Hyprland 0.56.2, kernel 7.2.5-3-omarchy, Alacritty
What's wrong?
When the clock's calendar popup (omarchy.clock, SUPER+CTRL+ALT+D) is open and the idle screensaver launches, the screensaver appears as a small centered square (not fullscreen) and closes after about 1.4s. The idle service then logs screensaver-dismissed, as if the user had provided input.
Expected: the screensaver goes fullscreen and stays up until there is real input.
Steps to reproduce
- Open the clock popup with
SUPER+CTRL+ALT+D. - Either wait for the idle timeout (default 150s), or run
omarchy-launch-screensaver forcefrom a delayed command (e.g.sleep 10; omarchy-launch-screensaver force, then open the popup within the delay). - Don't touch the keyboard or mouse.
Seen three times: once from the idle timer, and twice from the delayed command. A screensaver run with no popup open (16:50 the same day) behaved normally and ran about 62s.
Trace
I logged Hyprland events, the active window and layer surfaces while running omarchy-launch-screensaver force with the popup open:
| Time | State |
|---|---|
| t+0.00s | omarchy-keyboard-panel layer surface covers the screen (1536x864). Active window is an existing Alacritty. |
| t+0.28s | openwindow>>...,org.omarchy.screensaver,Alacritty |
| t+0.34s to t+0.85s | Screensaver window is mapped with fullscreen=0, floating=true, size=[800,600], centered. |
| throughout | Active window never changes. There is no activewindow event for the screensaver window. |
| t+1.46s | closewindow for the screensaver window. |
Idle service journal for the natural occurrence:
17:02:35.560 idle-cycle-start: screensaver=150 lock=300
17:02:35.560 process-start: screensaver ... omarchy-launch-screensaver
17:02:35.826 idle-monitor: active
17:02:36.998 idle-cycle-cancel: screensaver-dismissedNo coredumps and nothing relevant in hyprland.log.
Analysis
- The screensaver window never becomes the active window while the popup is open.
omarchy-screensaverexits as soon asscreensaver_in_focusis false (checked every 1s), which matches the ~1.4s lifetime.- The popup is a
KeyboardPanel(Ui/KeyboardPanel.qml), which takes keyboard focus (Exclusive, thenOnDemand), which is a plausible reason focus is never handed to the new window. - Separately, the
fullscreen = truewindow rule fororg.omarchy.screensaver(default/hypr/apps/system.lua) did not apply; the window opened at the default floating size of 800x600. I haven't determined whether that is caused by the popup or is a separate problem.
The keyboard-focus explanation is my reading of the code and is not confirmed. The trace above is what I observed.
Possible directions: close open popups when the screensaver launches, or don't treat "not focused" as dismissal in the first moments after launch.
Investigation and write-up assisted by Claude Code.
View raw text
**System details:** Intel i7-1355U, Intel Iris Xe (i915), System76 Lemur Pro, single eDP-1 display, Omarchy 4.0.4-1, Hyprland 0.56.2, kernel 7.2.5-3-omarchy, Alacritty ## What's wrong? When the clock's calendar popup (`omarchy.clock`, `SUPER+CTRL+ALT+D`) is open and the idle screensaver launches, the screensaver appears as a small centered square (not fullscreen) and closes after about 1.4s. The idle service then logs `screensaver-dismissed`, as if the user had provided input. Expected: the screensaver goes fullscreen and stays up until there is real input. ### Steps to reproduce 1. Open the clock popup with `SUPER+CTRL+ALT+D`. 2. Either wait for the idle timeout (default 150s), or run `omarchy-launch-screensaver force` from a delayed command (e.g. `sleep 10; omarchy-launch-screensaver force`, then open the popup within the delay). 3. Don't touch the keyboard or mouse. Seen three times: once from the idle timer, and twice from the delayed command. A screensaver run with no popup open (16:50 the same day) behaved normally and ran about 62s. ### Trace I logged Hyprland events, the active window and layer surfaces while running `omarchy-launch-screensaver force` with the popup open: | Time | State | |---|---| | t+0.00s | `omarchy-keyboard-panel` layer surface covers the screen (1536x864). Active window is an existing Alacritty. | | t+0.28s | `openwindow>>...,org.omarchy.screensaver,Alacritty` | | t+0.34s to t+0.85s | Screensaver window is mapped with `fullscreen=0`, `floating=true`, `size=[800,600]`, centered. | | throughout | Active window never changes. There is no `activewindow` event for the screensaver window. | | t+1.46s | `closewindow` for the screensaver window. | Idle service journal for the natural occurrence: ``` 17:02:35.560 idle-cycle-start: screensaver=150 lock=300 17:02:35.560 process-start: screensaver ... omarchy-launch-screensaver 17:02:35.826 idle-monitor: active 17:02:36.998 idle-cycle-cancel: screensaver-dismissed ``` No coredumps and nothing relevant in `hyprland.log`. ### Analysis - The screensaver window never becomes the active window while the popup is open. - `omarchy-screensaver` exits as soon as `screensaver_in_focus` is false (checked every 1s), which matches the ~1.4s lifetime. - The popup is a `KeyboardPanel` (`Ui/KeyboardPanel.qml`), which takes keyboard focus (`Exclusive`, then `OnDemand`), which is a plausible reason focus is never handed to the new window. - Separately, the `fullscreen = true` window rule for `org.omarchy.screensaver` (`default/hypr/apps/system.lua`) did not apply; the window opened at the default floating size of 800x600. I haven't determined whether that is caused by the popup or is a separate problem. The keyboard-focus explanation is my reading of the code and is not confirmed. The trace above is what I observed. Possible directions: close open popups when the screensaver launches, or don't treat "not focused" as dismissal in the first moments after launch. --- Investigation and write-up assisted by Claude Code.
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 18:26 UTC