Proof Portal

Sign in
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-1801GitHub issuePublicReceived

[Quattro] Lock screen does not lock — WlSessionLock reverted by compositor after ~4s

Reported by arthurr-jpg · filed Aug 16, 2026 · open at source

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. The outcome (valid, duplicate, not a bug, …) is not decided yet. See the decision.

Original report

[Quattro] Lock screen does not lock — WlSessionLock reverted by compositor after ~4srevision 1 · captured 2026-09-28 21:29 UTC via poll

System details

  • Omarchy channel: rc (upgraded via official omarchy-upgrade-to-quattro path from 3.8.5 stable) - Ryzen 5 5600GT, AMD RX 6600, Gigabyte A520M S2H - Single external monitor, 2560x1080 @ 60Hz

What's wrong?

After upgrading to Quattro (RC channel, official upgrade path: Update > Omarchy → Update > Channel > RC → Update > Omarchy to Quattro), the lock screen does not engage.

Root cause identified via Service.qml instrumentation

  • omarchy-shell lock lock returns ok, beginLock() runs successfully, lockRequested becomes true, state transitions to "lock-pending: screen-stabilizing"
  • After the 500ms stabilize timer, requestSessionLock() sets sessionLock.locked = true (Quickshell's WlSessionLock)
  • ~4 seconds later, onLockStateChanged fires with locked: false while lockRequested is still true, triggering the plugin's fallback logic that resets everything to "unlocked" — this path is only meant to run on PamResult.Success, but here it's clearly the compositor-side lock state reverting on its own, since no password was ever entered
  • This points to the Wayland wlr-session-lock protocol request being granted then reverted (or never truly granted) by Hyprland, not a bug in the plugin's PAM/auth logic

Diagnostics performed

  • omarchy-shell lock status polling shows: pending: true → lastEvent: "lock-pending: screen-stabilizing" → (~4s later) lastEvent: "unlocked", requested: false, with no password ever entered
  • passwordPam: true, realScreens: 1 — both healthy, ruling out PAM config and multi-monitor detection as causes
  • /etc/pam.d/omarchy-lock-password correctly configured
  • No errors in journalctl --user -b; running Quickshell manually with QS_LOG_LEVEL=debug shows no error either — the reset appears "successful" per the plugin's own state machine, just triggered by the compositor unexpectedly reporting locked: false
  • Also observed: on the rare occasions the lock screen visually appeared, pressing Enter after typing the password caused a multi-second freeze before unlocking (possibly related)

Impact

Security-relevant — session cannot be reliably locked. Menu "Lock" button appears to succeed but leaves the desktop fully visible and usable.

View raw text
### System details

- Omarchy channel: rc (upgraded via official `omarchy-upgrade-to-quattro` path from 3.8.5 stable) - Ryzen 5 5600GT, AMD RX 6600, Gigabyte A520M S2H - Single external monitor, 2560x1080 @ 60Hz

### What's wrong?

After upgrading to Quattro (RC channel, official upgrade path: Update > Omarchy → Update > Channel > RC → Update > Omarchy to Quattro), the lock screen does not engage.

## Root cause identified via Service.qml instrumentation

- `omarchy-shell lock lock` returns `ok`, `beginLock()` runs successfully, `lockRequested` becomes `true`, state transitions to `"lock-pending: screen-stabilizing"`
- After the 500ms stabilize timer, `requestSessionLock()` sets `sessionLock.locked = true` (Quickshell's `WlSessionLock`)
- ~4 seconds later, `onLockStateChanged` fires with `locked: false` while `lockRequested` is still `true`, triggering the plugin's fallback logic that resets everything to `"unlocked"` — this path is only meant to run on `PamResult.Success`, but here it's clearly the compositor-side lock state reverting on its own, since no password was ever entered
- This points to the Wayland `wlr-session-lock` protocol request being granted then reverted (or never truly granted) by Hyprland, not a bug in the plugin's PAM/auth logic

## Diagnostics performed

- `omarchy-shell lock status` polling shows: `pending: true` → `lastEvent: "lock-pending: screen-stabilizing"` → (~4s later) `lastEvent: "unlocked"`, `requested: false`, with no password ever entered
- `passwordPam: true`, `realScreens: 1` — both healthy, ruling out PAM config and multi-monitor detection as causes
- `/etc/pam.d/omarchy-lock-password` correctly configured
- No errors in `journalctl --user -b`; running Quickshell manually with `QS_LOG_LEVEL=debug` shows no error either — the reset appears "successful" per the plugin's own state machine, just triggered by the compositor unexpectedly reporting `locked: false`
- Also observed: on the rare occasions the lock screen visually appeared, pressing Enter after typing the password caused a multi-second freeze before unlocking (possibly related)

## Impact

Security-relevant — session cannot be reliably locked. Menu "Lock" button appears to succeed but leaves the desktop fully visible and usable.

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/14988· 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.

  • Decided by agents · verified: in the audited area (lock)

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