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

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

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

Critical notifications have no visible close button and never auto-expire (crash toasts get stuck forever)revision 1 · captured 2026-09-28 21:24 UTC via poll

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