Proof Portal

Sign in
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-639GitHub issuePublicDecided· Out of scope

Screensaver exits on all monitors when Hyprland's ANR dialog steals focus

Reported by efrenaguilar95 · filed Sep 12, 2026 · open at source

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

Screensaver exits on all monitors when Hyprland's ANR dialog steals focusrevision 1 · captured 2026-09-28 21:23 UTC via poll

What happened

omarchy-launch-screensaver starts one ttfx animation per monitor via omarchy-screensaver. On a multi-monitor setup, the combined render load occasionally makes a screensaver terminal miss Hyprland's responsiveness ping, which triggers Hyprland's built-in "Application Not Responding" dialog (misc:enable_anr_dialog, on by default) via /usr/bin/hyprland-dialog. That dialog grabs keyboard focus.

omarchy-screensaver's watchdog loop polls hyprctl activewindow once a second and treats any focused window whose class isn't org.omarchy.screensaver as "the user dismissed the screensaver," calling exit_screensaver(), which runs pkill -x ttfx; pkill -f 'org.omarchy.screensaver'. That pkill isn't scoped to the current monitor/tty, so it kills every screensaver instance on every monitor at once, the moment the ANR dialog appears — even though the user never touched anything.

The net effect: the screensaver appears to randomly crash — all windows silently vanish, with no error, no core dump, and nothing logged anywhere (ttfx's stdout/stderr goes to its own pty, not the journal), because nothing actually crashed.

Expected

The screensaver should keep running (or at worst pause) through a transient ANR dialog rather than tearing down every monitor's instance the moment focus moves off any single screensaver window.

Steps to reproduce

  1. Have 2+ monitors (reproduced reliably on 3: DP-1 3440x1440@60, DP-2 2560x1440@170, HDMI-A-1 1024x600@60).
  2. Run omarchy-launch-screensaver force.
  3. Wait a few seconds while all monitors render ttfx simultaneously at --frame-rate 120.
  4. Watch hyprctl activewindow -j — when Hyprland's ANR dialog (class hyprland-dialog) pops up and takes focus, every screensaver window and ttfx process dies within ~1 second.

Diagnosis

Confirmed misc:enable_anr_dialog = true. Live capture (polling hyprctl activewindow/clients every 250ms) showed: all 3 org.omarchy.screensaver windows + 3 ttfx processes running normally → a hyprland-dialog-class window takes focus → ~0.5s later, 0 screensaver windows and 0 ttfx processes remain.

No coredump, no kernel segfault, no OOM kill correlates with this — ruling out an actual process crash.

System

  • omarchy 4.0.2-1
  • Hyprland 0.56.2
  • ttfx 0.3.2
  • Terminal: foot
  • 3 monitors (DP-1, DP-2, HDMI-A-1)

Filed by Claude Sonnet 5 via Claude Code.

View raw text
## What happened
`omarchy-launch-screensaver` starts one `ttfx` animation per monitor via `omarchy-screensaver`. On a multi-monitor setup, the combined render load occasionally makes a screensaver terminal miss Hyprland's responsiveness ping, which triggers Hyprland's built-in "Application Not Responding" dialog (`misc:enable_anr_dialog`, on by default) via `/usr/bin/hyprland-dialog`. That dialog grabs keyboard focus.

`omarchy-screensaver`'s watchdog loop polls `hyprctl activewindow` once a second and treats any focused window whose class isn't `org.omarchy.screensaver` as "the user dismissed the screensaver," calling `exit_screensaver()`, which runs `pkill -x ttfx; pkill -f 'org.omarchy.screensaver'`. That `pkill` isn't scoped to the current monitor/tty, so it kills every screensaver instance on every monitor at once, the moment the ANR dialog appears — even though the user never touched anything.

The net effect: the screensaver appears to randomly crash — all windows silently vanish, with no error, no core dump, and nothing logged anywhere (ttfx's stdout/stderr goes to its own pty, not the journal), because nothing actually crashed.

## Expected
The screensaver should keep running (or at worst pause) through a transient ANR dialog rather than tearing down every monitor's instance the moment focus moves off any single screensaver window.

## Steps to reproduce
1. Have 2+ monitors (reproduced reliably on 3: DP-1 3440x1440@60, DP-2 2560x1440@170, HDMI-A-1 1024x600@60).
2. Run `omarchy-launch-screensaver force`.
3. Wait a few seconds while all monitors render `ttfx` simultaneously at `--frame-rate 120`.
4. Watch `hyprctl activewindow -j` — when Hyprland's ANR dialog (class `hyprland-dialog`) pops up and takes focus, every screensaver window and `ttfx` process dies within ~1 second.

## Diagnosis
Confirmed `misc:enable_anr_dialog` = `true`. Live capture (polling `hyprctl activewindow`/`clients` every 250ms) showed: all 3 `org.omarchy.screensaver` windows + 3 `ttfx` processes running normally → a `hyprland-dialog`-class window takes focus → ~0.5s later, 0 screensaver windows and 0 `ttfx` processes remain.

No coredump, no kernel segfault, no OOM kill correlates with this — ruling out an actual process crash.

## System
- omarchy 4.0.2-1
- Hyprland 0.56.2
- ttfx 0.3.2
- Terminal: foot
- 3 monitors (DP-1, DP-2, HDMI-A-1)

Filed by Claude Sonnet 5 via 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 12:16 UTC