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.
Critical notifications have no visible close button and never auto-expire (crash toasts get stuck forever)
Reported by mrocha-montes · filed Aug 31, 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
Critical-urgency notifications (--urgency critical / NotificationUrgency.Critical) have no visible way to dismiss them and never auto-expire, so they can get stuck on screen indefinitely.
This is most visible with the built-in crash-detection feature: omarchy-crash-watch sends its "Process crashed: X — Click to diagnose with AI" toast with --urgency critical. If the user doesn't already know that right-click dismisses a notification card (there is no visible close button, no X, nothing in the UI hints at it), that toast just sits there permanently, since Service.qml's durationFor() explicitly returns 0 (no timer) for NotificationUrgency.Critical.
Reproduce directly, no crash needed:
omarchy notification send -u critical "Test" "This will never go away and has no visible close button"What was expected
Either:
- a small, always-visible dismiss button on the notification card (in addition to right-click), and/or
- critical notifications eventually auto-expiring after a generous timeout (e.g. 20-30s) instead of never, since "never expires" + "no visible way to close" compounds into a notification that's effectively stuck forever for anyone who hasn't read the source.
Suggested fix
In /usr/share/omarchy/shell/plugins/notifications/components/NotificationCard.qml, add a small × button (top-right corner of the card) wired to the existing closeRequested() signal — the plumbing already exists (right-click already calls it), it's just not exposed visually.
In /usr/share/omarchy/shell/plugins/notifications/Service.qml, durationFor() could give NotificationUrgency.Critical a bounded duration (e.g. Math.min(maxPopupDuration, Math.max(20000, requestedDuration(expireTimeout)))) instead of hardcoding 0. The per-card countdown plumbing (cardSlot.lifetime, remainingLifetime, the hover-pauses-countdown Timer) already exists and already handles lifetime <= 0 as "never expire" — enabling it for critical is a one-line change.
I patched a local clone of the notifications plugin with exactly this (visible close button + bounded critical timeout + a small depleting progress bar reusing the already-computed remainingLifetime value) and it works well; happy to open a PR with it if that's useful.
Environment
- Omarchy version: 4.0.1-1
- Kernel:
7.1.9-arch1-2(Arch Linux) - GPU: Intel UHD Graphics 620 (i915)
- Compositor: Hyprland (default Omarchy shell / Quickshell)
(omarchy debug --no-sudo --print is not available as a command on this installed version, so I couldn't attach the standard diagnostic log — omarchy commands --all doesn't list a debug command either.)
View raw text
## What happened Critical-urgency notifications (`--urgency critical` / `NotificationUrgency.Critical`) have no visible way to dismiss them and never auto-expire, so they can get stuck on screen indefinitely. This is most visible with the built-in crash-detection feature: `omarchy-crash-watch` sends its "Process crashed: X — Click to diagnose with AI" toast with `--urgency critical`. If the user doesn't already know that **right-click** dismisses a notification card (there is no visible close button, no `X`, nothing in the UI hints at it), that toast just sits there permanently, since `Service.qml`'s `durationFor()` explicitly returns `0` (no timer) for `NotificationUrgency.Critical`. Reproduce directly, no crash needed: ```bash omarchy notification send -u critical "Test" "This will never go away and has no visible close button" ``` ## What was expected Either: - a small, always-visible dismiss button on the notification card (in addition to right-click), and/or - critical notifications eventually auto-expiring after a generous timeout (e.g. 20-30s) instead of never, since "never expires" + "no visible way to close" compounds into a notification that's effectively stuck forever for anyone who hasn't read the source. ## Suggested fix In `/usr/share/omarchy/shell/plugins/notifications/components/NotificationCard.qml`, add a small `×` button (top-right corner of the card) wired to the existing `closeRequested()` signal — the plumbing already exists (right-click already calls it), it's just not exposed visually. In `/usr/share/omarchy/shell/plugins/notifications/Service.qml`, `durationFor()` could give `NotificationUrgency.Critical` a bounded duration (e.g. `Math.min(maxPopupDuration, Math.max(20000, requestedDuration(expireTimeout)))`) instead of hardcoding `0`. The per-card countdown plumbing (`cardSlot.lifetime`, `remainingLifetime`, the hover-pauses-countdown `Timer`) already exists and already handles `lifetime <= 0` as "never expire" — enabling it for critical is a one-line change. I patched a local clone of the `notifications` plugin with exactly this (visible close button + bounded critical timeout + a small depleting progress bar reusing the already-computed `remainingLifetime` value) and it works well; happy to open a PR with it if that's useful. ## Environment - Omarchy version: 4.0.1-1 - Kernel: `7.1.9-arch1-2` (Arch Linux) - GPU: Intel UHD Graphics 620 (i915) - Compositor: Hyprland (default Omarchy shell / Quickshell) (`omarchy debug --no-sudo --print` is not available as a command on this installed version, so I couldn't attach the standard diagnostic log — `omarchy commands --all` doesn't list a `debug` command either.)
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/9790· 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:16 UTC