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.
Lock shell dies during normal idle->lock; session permanently locked, reboot required
Reported by akashgagda · filed Aug 8, 2026 · open at source
This defect is tracked under R-1659. This report describes the same defect, so it is folded under it in the inbox.
Earliest report of this defect: R-1882 (filed Aug 8, 2026).
Decided by agents · verified· Oct 9, 2026
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?
- 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
Summary
The Omarchy shell (a single quickshell process hosting the omarchy.idle and omarchy.lock services) exits while the session is locked during a normal idle → lockscreen cycle with no user interaction and no idle inhibitor active. Because ext-session-lock leaves the session permanently locked when the lock client dies, Hyprland shows its "lockscreen app died" failsafe and the machine is unusable until a reboot.
Expected behavior
The idle → lockscreen → lock cycle should not end in a dead shell. At minimum, if the lock client dies, the session should be recoverable (respawn / re-acquire the lock) instead of requiring a reboot, and diagnostics should be available afterwards.
Reproduction steps
- Start a session and leave the machine untouched (no media playing, no idle inhibitor, nothing fullscreen).
- Idle timeout fires at
idle.screensaver(150s), thenidle.lock(300s). The lock screen appears normally. - After some time the lock surface vanishes and the Hyprland gray failsafe ("lockscreen app died") appears.
- Nothing recovers the display. Only a reboot (or TTY + reboot) restores the system.
Environment
- OS: Arch Linux, kernel 7.1.6
- CPU: Intel Core i5-13500 (13th gen)
- GPU: Intel UHD Graphics 770 (iGPU only)
hyprland0.56.2-1quickshell-git0.3.0.r18.g10b439f-3 (quickshell-git AUR, built 2026-07-25, since omarchy requires the git build)omarchy-dev4.0.0.r1569.g007d6fc-1idle.lock= 300,idle.screensaver= 150
Diagnostics / observations
- No coredump. The previous session's journal contains no
systemd-coredump/ signal-crash entry forquickshell, and no Hyprland crash report — the death looks like an exit without a signal (or the dump was lost). - No shell log.
quickshell -n -p $OMARCHY_PATH/shellis launched by Hyprland autostart viahl.exec_cmd()with no output redirection, so the idle/lock event trail is not persisted anywhere and is lost on reboot. This made root-cause analysis impossible from the shell side. - Hyprland journal shows
error in client communication (pid …)~15 min into the (short, otherwise quiet) session, which may be the shell being killed by the compositor. - The lock service (
/usr/share/omarchy/shell/plugins/lock/Service.qml) already contains a guard for zero/phantom screens (requestSessionLock/hasRealScreen()/ pending timers), presumably in response to Quickshell's known session-lock crash reports. This crash appears to get past that guard, or comes from a different path.
Possibly related upstream
- quickshell-mirror/quickshell #61 —
qFatal()"Session lock screen does not correspond to a real screen" when a lock surface targets a phantom/no screen. - quickshell-mirror/quickshell #76 — crash in
WlSessionLock::realizeLockTarget()when the compositor rejects a lock request while no real screen exists.
Happy to attach a full omarchy debug log and/or a screen capture of the failsafe on the next occurrence.
View raw text
## Summary
The Omarchy shell (a single `quickshell` process hosting the `omarchy.idle` and `omarchy.lock` services) exits while the session is locked during a **normal idle → lockscreen cycle with no user interaction and no idle inhibitor active**. Because ext-session-lock leaves the session permanently locked when the lock client dies, Hyprland shows its "lockscreen app died" failsafe and the machine is unusable until a reboot.
## Expected behavior
The idle → lockscreen → lock cycle should not end in a dead shell. At minimum, if the lock client dies, the session should be recoverable (respawn / re-acquire the lock) instead of requiring a reboot, and diagnostics should be available afterwards.
## Reproduction steps
1. Start a session and leave the machine untouched (no media playing, no idle inhibitor, nothing fullscreen).
2. Idle timeout fires at `idle.screensaver` (150s), then `idle.lock` (300s). The lock screen appears normally.
3. After some time the lock surface vanishes and the **Hyprland gray failsafe** ("lockscreen app died") appears.
4. Nothing recovers the display. Only a reboot (or TTY + reboot) restores the system.
## Environment
- OS: Arch Linux, kernel 7.1.6
- CPU: Intel Core i5-13500 (13th gen)
- GPU: Intel UHD Graphics 770 (iGPU only)
- `hyprland` 0.56.2-1
- `quickshell-git` 0.3.0.r18.g10b439f-3 (quickshell-git AUR, built 2026-07-25, since omarchy requires the git build)
- `omarchy-dev` 4.0.0.r1569.g007d6fc-1
- `idle.lock` = 300, `idle.screensaver` = 150
## Diagnostics / observations
- **No coredump.** The previous session's journal contains **no** `systemd-coredump` / signal-crash entry for `quickshell`, and no Hyprland crash report — the death looks like an exit without a signal (or the dump was lost).
- **No shell log.** `quickshell -n -p $OMARCHY_PATH/shell` is launched by Hyprland autostart via `hl.exec_cmd()` with **no output redirection**, so the idle/lock event trail is not persisted anywhere and is lost on reboot. This made root-cause analysis impossible from the shell side.
- Hyprland journal shows `error in client communication (pid …)` ~15 min into the (short, otherwise quiet) session, which may be the shell being killed by the compositor.
- The lock service (`/usr/share/omarchy/shell/plugins/lock/Service.qml`) already contains a guard for zero/phantom screens (`requestSessionLock` / `hasRealScreen()` / pending timers), presumably in response to Quickshell's known session-lock crash reports. This crash appears to get past that guard, or comes from a different path.
## Possibly related upstream
- quickshell-mirror/quickshell #61 — `qFatal()` "Session lock screen does not correspond to a real screen" when a lock surface targets a phantom/no screen.
- quickshell-mirror/quickshell #76 — crash in `WlSessionLock::realizeLockTarget()` when the compositor rejects a lock request while no real screen exists.
Happy to attach a full `omarchy debug` log and/or a screen capture of the failsafe on the next occurrence.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
- Fixed bypr/6642· confirmed
- Duplicate ofR-1659omarchy-shell lock screen crash-loops (~every 18s) after locking, due to DPMS-off· decided by agents · verified
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.