Stalled lock latches lockRequested, so every later lock() returns "ok" without locking — machine suspends unlocked

[mchldotdev]

Summary

When a lock request stalls after lock-pending: screen-stabilizing, lockRequested stays latched true forever. Because the lock plugin derives locked from lockRequested, the lock IPC method then short-circuits and returns "ok" for every subsequent request without ever locking. The lid-close lock therefore becomes a silent no-op and the machine suspends with the session fully exposed. On resume, Hyprland shows its crashed-lockscreen failsafe.

The stall itself is intermittent. The latch that turns one stall into "every later lock silently does nothing, and reports success" is deterministic, and is the part that makes this a security issue rather than a cosmetic one.

What happened

Single boot, no user config beyond stock idle values (screensaver: 150, lock: 300):

08:48:21  omarchy idle: process-start: lock omarchy-system-lock
08:48:21  omarchy lock  lock-requested
08:48:21  omarchy lock  lock-pending: screen-stabilizing
08:48:21  omarchy idle: process-exit: lock exitCode=0 status=0
          <-- no session-locked=true, no secure=true, ever
08:50:51  omarchy idle: process-start: screensaver   (so lock isLocked == false)
08:53:21  omarchy idle: process-exit: lock exitCode=0 status=0   (second idle lock, also a no-op)
08:57:44  systemd-logind: Lid closed.
08:57:57  systemd-logind: Suspending...
          <-- suspended UNLOCKED
10:52:36  systemd-logind: Lid opened.  (resume)
          <-- Hyprland crashed-lockscreen failsafe on screen
10:52:43  omarchy lock  session-locked=false
10:52:43  omarchy lock  unlocked

Between 08:48:21 and 10:52:43 the omarchy lock namespace logged nothing at all. sessionLock.locked = true was reached (no lock-pending: no-real-screen was logged, so hasRealScreen() was true and requestSessionLock() ran to completion), but onLockStateChanged never fired — Quickshell silently declined to take the ext-session-lock.

Expected behavior

A lock request that cannot be satisfied should fail loudly and reset lockRequested, so the next request — in particular the lid-close one — gets a real attempt. A machine must never suspend unlocked because an earlier lock stalled.

Root cause

plugins/lock/Service.qml:

readonly property bool locked: lockRequested || sessionLock.locked || sessionLock.secure

IpcHandler {
  target: "lock"

  function lock(): string {
    if (!root.passwordPamConfigured) return "missing-pam"
    if (!root.locked && !root.beginLock()) return "failed"
    return "ok"
  }

Once lockRequested is true, root.locked is true, so beginLock() is never called again and the method returns "ok". There is no timeout that resets lockRequested when the session lock never materialises — pendingSessionLockTimer retries requestSessionLock() forever, and requestSessionLock() returns immediately at its first guard once lockRequested is set but the lock never arrives.

Nothing downstream can notice, either:

• omarchy-system-lock runs omarchy-shell lock lock >/dev/null and never checks the reply.
• omarchy-system-sleep-lock's lock_state() reads requested: true, secure: false and classifies it as locking — "the shell has the request and is working on it, so leave it alone" — so it waits out its whole budget instead of re-requesting.

So the one component that could have caught this deliberately stays quiet, because a latched-stuck request is indistinguishable from a healthy in-progress one.

Suggested direction

Give the pending state a deadline. If sessionLock.locked has not become true within some bound of beginLock(), log a failure, reset lockRequested/pendingSessionLock, and let the next caller retry from scratch. lock() returning "ok" should mean "the session is locked or is provably becoming locked", not "a request was recorded at some point".

Distinguishing requested-but-stalled from locking in lock status would also let omarchy-system-sleep-lock re-request rather than wait, which is what it already does for the idle state.

Steps to reproduce

The stall is intermittent and I could not reproduce it on demand. The latch is trivially reproducible once the stall has happened: while lock status reports requested: true, sessionLocked: false, secure: false, every omarchy-shell lock lock returns ok and nothing locks, including omarchy system lock and the lid-close path.

Contrast: on the same shell process (PID unchanged), a manual omarchy-shell lock lock from a clean state reaches secure=true in ~400-600 ms, twice out of two attempts:

0.0s  req=True  sessLocked=False secure=False last=lock-pending: screen-stabilizing
0.4s  req=True  sessLocked=True  secure=True  last=secure=true

Possibly relevant

The shell had been restarted with omarchy restart shell about 8 minutes before the stalled lock (08:40:32; the stall was at 08:48:21). The same process later locked correctly on demand, so a restart is clearly not sufficient to cause it, but it may be part of the trigger and I did not want to leave it out.

omarchy-sleep-lock.service also failed three times on resume with Failed to inhibit: The operation inhibition has been requested for is already running (restart counter 1→4 at 10:52:36-10:52:42), which looks like #7280.

Related

• Idle-triggered lock silently no-ops; screen never actually locks #9480 — idle-triggered lock silently no-ops. Related but distinct: there the lock module logs nothing at all, so the IPC never reaches it. Here the IPC arrives and the module logs lock-requested before stalling.
• Shell lock client dies on resume from suspend, showing Hyprland 'screensaver died' failsafe #9156 — shell lock client dies on resume, showing the same Hyprland failsafe.
• omarchy-sleep-lock.service fails on resume: Restart=always re-runs systemd-inhibit while logind's sleep operation is still in flight #7280 — omarchy-sleep-lock.service Restart=always racing logind on resume.

System details

• Omarchy: 4.0.2-1
• Hyprland: 0.56.2
• Quickshell: 0.3.1-1
• Kernel: 7.1.9-arch1-2
• Model: LENOVO Yoga 7 2-in-1 16AKP10 (83JU)
• CPU: AMD Ryzen AI 7 350 w/ Radeon 860M
• GPU: AMD Krackan [Radeon 840M / 860M Graphics]
• Single internal display, no external monitors
• /etc/pam.d/omarchy-lock-password present and valid; fingerprint not configured
• All 96 migrations applied

omarchy debug is not available in 4.0.2 (Unknown Omarchy command), so the details above were collected by hand.

[omarchybot]

Confirmed, and the latch is the part that matters. Reviewed twice: once by Opus 5 in Claude Code, and once independently by Codex (gpt-5.6-sol) at xhigh reasoning. Codex agreed on the latch and on the consequence chain, and added two things neither the report nor the first review had.

The latch, proven in source

shell/plugins/lock/Service.qml:

• lockRequested is set true in beginLock() at :135, before anything has confirmed anything.
• locked is derived from it at :37 — readonly property bool locked: lockRequested || sessionLock.locked || sessionLock.secure.
• The lock IPC method skips beginLock() on that at :515 and falls through to return "ok" at :516.

Only two paths in the whole file ever set lockRequested back to false, and neither is reachable once the session lock has failed to materialise:

• finishUnlock() at :151, reached only from a successful PAM result (:332 password, :224 fingerprint). Fingerprint cannot start until sessionLock.secure is true (:210), and the password can only be submitted from the LockView inside WlSessionLockSurface (:264-284) — which does not exist without a compositor lock. The preview window's LockView (:299-310) has inputEnabled: false and no onSubmitPassword handler, so it is not a way in either.
• onLockStateChanged at :254, which fires on a change in the compositor-confirmed lock state. If that state never became true, it never changes to false.

There is no deadline anywhere, and IpcHandler (:510-550) exposes no unlock, so nothing outside the process can clear it either.

Why one stall becomes permanent, which is also in this repo

requestSessionLock() clears pendingSessionLock and stops the retry timer at :74-75 and only then assigns sessionLock.locked = true at :76. It disarms its own retry on the strength of a write it has not had confirmed. Both confirmation handlers already stop those timers (:239-240 on secure, :250-251 on lock state), so the pre-emptive stop is redundant when the lock succeeds and fatal when it does not.

That is what your pending/sessionLocked pair identifies. Codex's point: requested:true with pending:false is reachable through exactly one branch — :74-76 — because it is the only place pendingSessionLock is cleared without lockRequested also being cleared. Your status output is a fingerprint of that branch.

Codex also found a second disarm of the same kind at :248-252: when locked becomes true both timers stop, before secure has arrived. A lock that goes locked-but-never-secure is disarmed the same way.

Reproduced on a worker

Clean Omarchy 4.0.x VM, single output, shell/plugins/lock/Service.qml byte-identical to yours (unchanged since v4.0.2). The intermittent part is the compositor declining the lock, which I could not induce — I first tried holding an ext-session-lock with an independent Quickshell client, and Hyprland granted Omarchy's lock anyway, so a stranded lock is not the trigger. So I stubbed out the one line whose effect your journal shows never arriving, :76, and left the rest of the stack stock. The shell then reached beginLock() through its own stranded-lock recovery, and:

{"locked":true,"requested":true,"pending":false,"sessionLocked":false,"secure":false,
 "realScreens":1,"passwordPam":true,"fingerprint":false,"authenticating":false,
 "lastEvent":"lock-pending: screen-stabilizing"}

That is your captured state exactly. From there:

• five consecutive omarchy-shell lock lock over twenty seconds, all ok, nothing locked, state unmoved;
• lock isLocked → true;
• omarchy-system-lock → exit 0;
• omarchy-system-sleep-lock → exit 1 after 12 s, suspending without a secure lock (the shell did not secure the session within 12000ms);
• 90 s later, still latched. Nothing times out.

The journal for the whole run was your three lines and then silence:

lock-stranded: recovering
lock-requested
lock-pending: screen-stabilizing

The consequence chain, checked separately

Lid close → switch:on:Lid Switch (default/hypr/bindings/utilities.lua:34) → omarchy-system-lid-close, which runs omarchy-system-lock >/dev/null 2>&1 || true (:17). omarchy-system-lock:8 discards the IPC reply, and the script's exit status comes from its last line, pkill -f '[o]rg.omarchy.screensaver' ... || true (:26). It exits 0 whether or not a lock surface exists — so your process-exit: lock exitCode=0 carries no information about locking at all.

Then PrepareForSleep(true) → omarchy-system-sleep-monitor:11-13 → omarchy-system-sleep-lock under a delay inhibitor. request_lock (:71-75) only reacts to missing-pam, so ok passes; lock_state (:79-84) maps requested:true, secure:false to locking; the loop deliberately does nothing for that (:114-122). With the shipped InhibitDelayMaxSec=15 (etc/systemd/logind.conf.d/20-inhibit-delay.conf:10) the budget derived at :21-36 is 12 s. Your lid-close-to-Suspending gap is 13 s. Then report_unsecured (:96-105) warns and exits 1, and logind suspends anyway, because a delay inhibitor is a timer and not a veto — the comment at :93-95 says so.

One refinement to your suggested direction: distinguishing requested-but-stalled from locking would make omarchy-system-sleep-lock re-request, but on its own that would not have helped — the re-request goes back through the same IPC method and is short-circuited by the same latch. The service has to rearm first.

Two things your log understates

isLocked (:519-521) returns root.locked too, and the idle service guards the screensaver on it: shell/plugins/services/idle/Service.qml:68 runs [[ $(omarchy-shell lock isLocked) == "true" ]] || omarchy-launch-screensaver. process-start: screensaver is logged when that wrapper starts, not when a screensaver appears — so it does not show isLocked == false. Under the latch it returns true and the screensaver is suppressed, which the worker confirmed. Worth checking your own journal for whether ttfx or org.omarchy.screensaver actually appeared at 08:50:51: if it did not, that is a second confirmation of the latch from the same boot.

And omarchy-system-sleep-lock should have sent a critical notification, "Screen did not lock before suspend", landing on the screen you opened the lid into. If you saw it, the chain above is confirmed end to end from your side too.

What is still open, and what would close it

Why Quickshell declined the lock on your machine is not established, and cannot be from this repository. Two things from that same window would help, and you would have filtered both out:

1. Anything Quickshell logged between 08:48:21 and 08:57:57 outside the omarchy lock namespace — the full journalctl --user _COMM=quickshell for that window, particularly WlSessionLock, Aborting lock, lock surface, placeholder screen. Lock screen fails: WlSessionLock.surface does not create WlSessionLockSurface #9836 and Crash: "Tried to show lockscreen surfaces without active lock" on shell restart #9811 quote two different refusal messages of that shape.
2. hyprctl -j monitors around then, if you happen to have it, since the acquisition turns on what Quickshell thought the outputs were.

Not new in 4.0.2

git log -S: the locked derivation and the IPC pattern came in with 7ea4e1ab "Switch hyprlock to QS" (2026-05-19), and the premature pendingSessionLockTimer.stop() with 8f5336e0 (2026-06-22). Both are ancestors of v4.0.0. This is a regression relative to hyprlock, not something 4.0.2 introduced.

Related, and not

• Idle-triggered lock silently no-ops; screen never actually locks #9480 — same visible outcome, different point of failure: there the lock module logs nothing at all, so the IPC never reaches it; here it logs lock-requested and then stalls. Both are made invisible by the same exitCode=0.
• omarchy-system-lock reports success when shell IPC never requests a lock #9734 (closed) — proposed the omarchy-system-lock exit-code half as the mechanism, and the reporter withdrew it for that incident. The mechanism itself is real and is still in bin/omarchy-system-lock:8; it is what hides this bug rather than what causes it.
• Lock screen fails: WlSessionLock.surface does not create WlSessionLockSurface #9836, Crash: "Tried to show lockscreen surfaces without active lock" on shell restart #9811, quickshell (Omarchy shell) aborts: "Tried to show lockscreen surfaces without active lock" #9727, Quickshell crashes (SIGABRT) on plugin hot-reload: "Tried to show lockscreen surfaces without active lock" #9736, Quickshell SIGABRT ("Tried to show lockscreen surfaces without active lock") when a plugin live-reloads while the screen is locked #9709, Plugin hot-reload while locked destroys the lock client; Quickshell then SIGABRTs #9441 — Quickshell refusing or aborting a lock. Any of these is a candidate trigger for the stall. This issue is about what Omarchy does for the two hours afterwards.
• Lock-on-suspend runs after PrepareForSleep(true), so pam_fprintd can never install fprintd's sleep delay inhibitor #10252 — same suspend-ordering region, different defect: there the lock starts too late for pam_fprintd to take its inhibitor. Adjacent, not the same.
• omarchy-sleep-lock.service fails on resume: Restart=always re-runs systemd-inhibit while logind's sleep operation is still in flight #7280 — the omarchy-sleep-lock.service restart failure you noted; already filed, separate.
• Lock screen crash: MultiEffect blur with high GPU load causes QML scene crash during plugin reload #10305 / Lock screen crash: MultiEffect blur with high GPU load causes QML scene crash during plugin reload #10304 / Lock screen crash: MultiEffect blur with high GPU load causes QML scene crash during plugin reload #10303 — three identical reports of a MultiEffect blur crash on the lock surface. Not this; being looked at separately.
• Lock screen password field doesn't have keyboard focus until clicked #9292, [Quattro] Lock password field can lose focus after suspend resume #9180, Lock screen accepts no keyboard input after suspend/resume — fcitx5 wedges, presents as a system freeze #9325 — password-field focus after resume. Those are all about a lock that did materialise. Not this.

Waiting on

No fix is proposed here, deliberately. The rearm is straightforward — leave the retry armed at :74-75 until :239-240/:250-251 observe progress, and rearm acquisition when a request arrives with lockRequested true and both real lock properties false — but two parts of it are the maintainer's call, not a defect correction:

• Fail closed or fail open. omarchy-system-sleep-lock currently chooses fail open on purpose, and the reason is written down at :16-20: a hard block would leave a closed laptop awake in a bag. Making the machine refuse to suspend is not obviously better than the current behaviour.
• What locked should mean. Narrowing it so lock() stops reporting "ok" for a bare request also changes the idle screensaver guard at shell/plugins/services/idle/Service.qml:68, since that reads the same property. Codex's read, which I agree with, is that a narrower check inside the IPC method has less fallout than redefining locked globally.

There is also a deadline to pick, and a wrong one in this exact path is worse than the bug, so it wants an owner rather than a guess.

Everything above was verified against the source and on the worker rather than taken from either review; where Codex and I merely agree, its independence is not guaranteed, since its sandbox restricts writes and not reads.

[mechanicsunlocked]

Confirming the latch from a different entry point: a stranded-lock recovery (#6888) that never completes leaves lockRequested latched in exactly the same way, and after the Hyprland failsafe is cleared from a TTY the machine is left fully exposed, with the shell reporting locked.

omarchy 4.0.2-1, quickshell 0.3.1-1, hyprland 0.56.2-1, three outputs.

10:09:16.429 omarchy lock  secure=true                       <- manual lock
10:09:40.114 Local plugin changed, reloading: <plugin>        <- __pycache__ written by a test run
10:09:41.133 omarchy lock  lock-stranded: recovering
10:09:41.133 omarchy lock  lock-requested
10:09:41.133 omarchy lock  lock-pending: screen-stabilizing   <- last `omarchy lock` line of the day
14:40        hl.clear_crashed_lockscreen() from a remote shell; desktop usable again
14:51:07.848 omarchy idle  lock-system: lock-timeout
14:51:08.014 omarchy lock  lock-requested
14:51:08.014 omarchy lock  lock-pending: screen-stabilizing   <- no session-locked, no secure=true
14:51:09.129 omarchy idle  process-exit: lock exitCode=0       <- omarchy-system-lock reports success
14:56:09.150 omarchy idle  lock-system: lock-timeout
14:56:09.311 omarchy idle  process-exit: lock exitCode=0       <- second idle lock, silent no-op
17:31-17:50  user working in a terminal, screen never locked

Observed while it was in that state:

• omarchy-shell lock isLocked → true, for eight hours.
• omarchy-hyprland-session-locked → exit 1 (not locked), and the active window was a terminal the user was typing in.
• The idle service's screensaver step is gated on isLocked, so the screensaver was suppressed as well: nothing at all happened on idle.
• grep secure= shell.log shows one secure=true for the whole day, at 10:09:16.

omarchy restart shell was the only thing that reset it (the new lock service ran checkStrandedLock, got exit 1, and started clean).

So there are two roads into the same latch: a stall on a plain lock() as you describe, and the stranded recovery of #6888. Your suggested deadline on the pending state would cover both. Two small additions that would have caught this on my machine:

• lock() should re-request when requested is true but secure is false for longer than the deadline, instead of returning "ok".
• omarchy-system-lock could verify with omarchy-hyprland-session-locked after the call and log or retry when it disagrees; today it discards the reply entirely.

[kvnloo]

Session lock/idle cluster (omarchy.lock / omarchy.idle — session Hyprland, not the greeter).

• Stalled lock latches lockRequested, so every later lock() returns "ok" without locking — machine suspends unlocked #10299 lockRequested latch so later lock() returns ok without locking
• Screensaver clears the workspace's fullscreen window and never restores it #10788 screensaver fullscreen rule clears the lock path
• Idle screensaver/lock triggers during windowed Firefox video playback #10862 idle screensaver/lock during windowed video
• Lock-on-suspend runs after PrepareForSleep(true), so pam_fprintd can never install fprintd's sleep delay inhibitor #10252 lock-on-suspend after PrepareForSleep(true) races pam_fprintd
• Session lock silently lost on output re-add: desktop exposed without authentication (and quickshell SIGABRT on the same path) #10459 session lock silently lost on output re-add
• omarchy-system-sleep-lock posts a new critical notification per failure, so a repeating fault leaves unbounded reboot-persistent toasts #10651 omarchy-system-sleep-lock posts a new critical notification

Already in flight — do not compete:

• Lock screen: keep fingerprint idle while the display is blanked #11273 fingerprint idle while display blanked
• Recreate lock screen fingerprint PAM file for pre-quattro setups #11322 recreate lock fingerprint PAM for pre-quattro
• Clamp idle timeouts to the int32 millisecond range #11353 / idle: clamp Timer intervals to avoid 32-bit overflow #11136 / Fix idle timer 32-bit integer overflow on large timeout values (#11135) #11194 idle timer int32 clamp
• Allow restarting shell when desktop locked #11240 restart shell while locked
• Restore full-width windows after the idle screensaver #11277 restore windows after screensaver
• Keep screensaver/lock from engaging during Steam games #11083 / Inhibit idle for fullscreen Steam games, not just the Steam client #11272 Steam idle-inhibit (also covers leftover fix: idle-inhibit Steam games matching steam_app_* #9667)

Greeter/SDDM is a different Hyprland (#10454 / #10574). Do not mix. No hyprland-wm PR from me.