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.
Suspend-on-lid-close from an unlocked session can resume unlocked (regression: before_sleep_cmd no longer uses loginctl lock-session)
Reported by shawnyeager · filed Jul 23, 2026Closed upstream on 2026-07-23 by its own reporter shawnyeager. GitHub close reason: completed. Closed by its own reporter — not by itself evidence of a fix.
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?
- Not yet mapped to any requirement or component.
- 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. No decision has been recorded yet.
Original report
Summary
Closing the lid while the session is unlocked and active can suspend the machine without a lock ever coming up, so it resumes unlocked. This appears to be a regression from ca74b4d1 ("Simplify but letting omarchy-system-lock be responsible for turning off display and keyboard brightness"), which changed before_sleep_cmd away from loginctl lock-session — the exact trigger the earlier anti-race fix f39dc9a2 (#1041, "delay suspend until screen is locked") was built around.
The regression
f39dc9a2 (#1041) fixed this race by pairing:
before_sleep_cmd = loginctl lock-session
inhibit_sleep = 3inhibit_sleep = 3 waits on logind's lock state, which loginctl lock-session drives. The old omarchy-system-lock even kept if ! loginctl lock-session; then omarchy-system-lock as a fallback.
ca74b4d1 later changed it to:
before_sleep_cmd = OMARCHY_LOCK_ONLY=true omarchy-system-lock
inhibit_sleep = 3inhibit_sleep = 3 was kept, but the trigger it was validated against was removed. omarchy-system-lock now launches hyprlock backgrounded ((hyprlock; …) &) instead of going through the logind lock signal. When hyprlock doesn't acquire the ext_session_lock within logind's delay-inhibitor window (~5s InhibitDelayMaxSec), logind suspends anyway — unlocked.
Evidence (journal, Omarchy 3.8.4)
Lid closed while active; note the lock command runs but no Wayland session got locked / no Hyprlock version line ever follows before suspend:
16:04:41 systemd-logind: Lid closed.
16:04:41 systemd-logind: Suspending...
16:04:41 hypridle: Executing OMARCHY_LOCK_ONLY=true omarchy-system-lock
16:04:46 systemd-logind: Delay lock is active (PID hypridle) but inhibitor timeout is reached.
16:04:46 systemd: Reached target Sleep / Performing sleep operation 'suspend'
16:49:39 systemd-logind: Lid opened. ← resumes UNLOCKEDContrast: an earlier lid-close where the session was already locked before closing suspended and resumed correctly locked. The failure only occurs when the lid is closed from an active/unlocked session.
Workaround (also the proposed fix)
Restoring the f39dc9a2 pairing fixes it — revert before_sleep_cmd to loginctl lock-session, keeping inhibit_sleep = 3. This drives the logind lock state inhibit_sleep actually waits on, so suspend blocks until the session is genuinely locked.
Environment
- Omarchy 3.8.4
- Framework 13 AMD (BOE panel), amdgpu
- hyprlock v0.9.6
- On battery (so
HandleLidSwitchExternalPower=ignoreis not a factor — logind suspends on lid as intended)
View raw text
## Summary
Closing the lid while the session is **unlocked and active** can suspend the machine without a lock ever coming up, so it resumes **unlocked**. This appears to be a regression from `ca74b4d1` ("Simplify but letting omarchy-system-lock be responsible for turning off display and keyboard brightness"), which changed `before_sleep_cmd` away from `loginctl lock-session` — the exact trigger the earlier anti-race fix `f39dc9a2` (#1041, "delay suspend until screen is locked") was built around.
## The regression
`f39dc9a2` (#1041) fixed this race by pairing:
```
before_sleep_cmd = loginctl lock-session
inhibit_sleep = 3
```
`inhibit_sleep = 3` waits on logind's lock state, which `loginctl lock-session` drives. The old `omarchy-system-lock` even kept `if ! loginctl lock-session; then omarchy-system-lock` as a fallback.
`ca74b4d1` later changed it to:
```
before_sleep_cmd = OMARCHY_LOCK_ONLY=true omarchy-system-lock
inhibit_sleep = 3
```
`inhibit_sleep = 3` was kept, but the trigger it was validated against was removed. `omarchy-system-lock` now launches `hyprlock` backgrounded (`(hyprlock; …) &`) instead of going through the logind lock signal. When `hyprlock` doesn't acquire the `ext_session_lock` within logind's delay-inhibitor window (~5s `InhibitDelayMaxSec`), logind suspends anyway — unlocked.
## Evidence (journal, Omarchy 3.8.4)
Lid closed while active; note the lock command runs but no `Wayland session got locked` / no `Hyprlock version` line ever follows before suspend:
```
16:04:41 systemd-logind: Lid closed.
16:04:41 systemd-logind: Suspending...
16:04:41 hypridle: Executing OMARCHY_LOCK_ONLY=true omarchy-system-lock
16:04:46 systemd-logind: Delay lock is active (PID hypridle) but inhibitor timeout is reached.
16:04:46 systemd: Reached target Sleep / Performing sleep operation 'suspend'
16:49:39 systemd-logind: Lid opened. ← resumes UNLOCKED
```
Contrast: an earlier lid-close where the session was **already locked** before closing suspended and resumed correctly locked. The failure only occurs when the lid is closed from an active/unlocked session.
## Workaround (also the proposed fix)
Restoring the `f39dc9a2` pairing fixes it — revert `before_sleep_cmd` to `loginctl lock-session`, keeping `inhibit_sleep = 3`. This drives the logind lock state `inhibit_sleep` actually waits on, so suspend blocks until the session is genuinely locked.
## Environment
- Omarchy 3.8.4
- Framework 13 AMD (BOE panel), amdgpu
- hyprlock v0.9.6
- On battery (so `HandleLidSwitchExternalPower=ignore` is not a factor — logind suspends on lid as intended)
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.
No decision has been recorded yet.