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-2209GitHub issuePublicReceived

Quickshell exits with status 137 on wake from suspend, briefly flashing Hyprland lockdead screen

Reported by Jeffe747 · filed Oct 3, 2026 · open at source

In the audited area (lock) — decided by agents · verified. Not validated yet.

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?
AreaIn the audited arealock· 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?
Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. So far: in the audited area (lock) — decided by agents · verified; matches no known issue — decided by agents · verified. The outcome (valid, duplicate, not a bug, …) is not decided yet. See the decision.

Original report

Quickshell exits with status 137 on wake from suspend, briefly flashing Hyprland lockdead screenrevision 1 · captured 2026-10-03 12:10 UTC via poll

System details

Apple MacBookAir5,2, Intel Core i5-3427U, Intel HD Graphics 4000, Omarchy 4.0.4-1, Hyprland 0.56.2, Linux 7.2.5-3-omarchy

What's wrong?

Description

Upon opening the laptop lid and resuming from suspend (S3), the Omarchy lock screen briefly displayed Hyprland's emergency lockdead.png failsafe screen ("Oopsie daisy, it looks like you locked your screen but the lockscreen app died :("). Approximately 3–4 seconds later, the shell recovered automatically and restored the normal password input prompt.

Root Cause & Log Evidence

Reviewing journalctl logs revealed that the running Quickshell lock client (PID 1663) abruptly terminated with status 137 (SIGKILL) while processing rapid post-wake D-Bus property changes from NetworkManager access point enumeration:

Oct 03 13:53:14 systemd-logind[1294]: Lid opened.
Oct 03 13:53:14 systemd-sleep[10777]: System returned from sleep operation 'suspend'.
...
[quickshell] Updating all properties of org.freedesktop.NetworkManager/org/freedesktop/NetworkManager/AccessPoint/8 via GetAll
Oct 03 13:53:18 omarchy-shell[11045]: Omarchy shell exited with status 137; relaunching.

Because the active ext-session-lock-v1 client died while the compositor was locked, Hyprland engaged its failsafe lock screen (/usr/share/hypr/lockdead.png).

Omarchy's supervisor (omarchy-launch-shell) respawned Quickshell at 13:53:19 (PID 11092). Because misc.allow_session_lock_restore = true is configured in looknfeel.lua, the new instance successfully detected the orphaned lock and recovered:

Oct 03 13:53:21 omarchy-shell[11092]: DEBUG qml: omarchy lock lock-stranded: recovering
Oct 03 13:53:22 omarchy-shell[11092]: DEBUG qml: omarchy lock secure=true

Steps to reproduce

  1. Suspend the machine (lid close or idle) with lock screen active.
  2. Resume by opening the lid.
  3. Observe the transient lockdead failsafe screen before the shell respawns and reclaims the lock.

Diagnostic log generated with `omarchy-debug --no-sudo --print`.

View raw text
### System details

Apple MacBookAir5,2, Intel Core i5-3427U, Intel HD Graphics 4000, Omarchy 4.0.4-1, Hyprland 0.56.2, Linux 7.2.5-3-omarchy

### What's wrong?

#### Description
Upon opening the laptop lid and resuming from suspend (S3), the Omarchy lock screen briefly displayed Hyprland's emergency `lockdead.png` failsafe screen (*"Oopsie daisy, it looks like you locked your screen but the lockscreen app died :("*). Approximately 3–4 seconds later, the shell recovered automatically and restored the normal password input prompt.

#### Root Cause & Log Evidence
Reviewing journalctl logs revealed that the running Quickshell lock client (PID 1663) abruptly terminated with status **137** (`SIGKILL`) while processing rapid post-wake D-Bus property changes from NetworkManager access point enumeration:

```text
Oct 03 13:53:14 systemd-logind[1294]: Lid opened.
Oct 03 13:53:14 systemd-sleep[10777]: System returned from sleep operation 'suspend'.
...
[quickshell] Updating all properties of org.freedesktop.NetworkManager/org/freedesktop/NetworkManager/AccessPoint/8 via GetAll
Oct 03 13:53:18 omarchy-shell[11045]: Omarchy shell exited with status 137; relaunching.
```

Because the active `ext-session-lock-v1` client died while the compositor was locked, Hyprland engaged its failsafe lock screen (`/usr/share/hypr/lockdead.png`).

Omarchy's supervisor (`omarchy-launch-shell`) respawned Quickshell at 13:53:19 (PID 11092). Because `misc.allow_session_lock_restore = true` is configured in `looknfeel.lua`, the new instance successfully detected the orphaned lock and recovered:

```text
Oct 03 13:53:21 omarchy-shell[11092]: DEBUG qml: omarchy lock lock-stranded: recovering
Oct 03 13:53:22 omarchy-shell[11092]: DEBUG qml: omarchy lock secure=true
```

#### Steps to reproduce
1. Suspend the machine (lid close or idle) with lock screen active.
2. Resume by opening the lid.
3. Observe the transient `lockdead` failsafe screen before the shell respawns and reclaims the lock.

*Diagnostic log generated with `omarchy-debug --no-sudo --print`.*

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.

  • Decided by agents · verified: in the audited area (lock)
  • Decided by agents · verified: matches no known issue

The outcome (valid, duplicate, not a bug, …) is not decided yet.