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-1214GitHub issuePublicFixed

[Quattro] Lock password field can lose focus after suspend resume

Reported by ClGratton · filed Aug 30, 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

[Quattro] Lock password field can lose focus after suspend resumerevision 1 · captured 2026-09-28 21:24 UTC via poll

System details

  • Omarchy 4.0.1-1 (Quattro)
  • Hyprland 0.56.2-1
  • NVIDIA RTX 3080 Ti
  • Two DisplayPort outputs: 2560x1440 at 180 Hz and 200 Hz
  • Linux 7.1.9

What is wrong?

After suspending while the native Omarchy session lock is active, a restored or recreated lock surface can show a password field that does not own keyboard focus. Focus can also be lost while PAM disables the field and then releases it after a failed attempt.

This is separate from the slow-display reblank problem in #7399. It is also separate from the first modifier event lost during input-device restoration, which was later isolated in hyprwm/aquamarine#375.

Steps to reproduce

  1. Suspend through the normal Omarchy path so the session is locked before sleep.
  2. Resume and wait for the displays to return.
  3. Inspect or interact with the visible password field after output recreation.
  4. The field can lack active focus. The same loss can occur after PAM rejects a password and re-enables the field.

Root cause

LockView.qml requested passwordInput.forceActiveFocus() only when the component completed or inputEnabled changed. During resume, ext-session-lock outputs can be recreated while inputEnabled remains true. Service.qml already observes Quickshell.onScreensChanged, but did not ask the recreated view to reacquire keyboard focus.

On a multi-monitor resume, outputs can return sequentially, so one immediate refocus is not sufficient. PAM also temporarily disables the input during authentication, requiring recovery to pause and restart when the field becomes enabled again.

Expected

The password field owns keyboard focus whenever the visible lock surface is ready for input, including after output recreation and after a failed PAM attempt.

Verified fix

A cloned omarchy.lock service sends a focus-generation request when the lock becomes secure, whenever screens change, and after PAM releases the input. LockView is a FocusScope, acknowledges TextInput.activeFocus, and the service retries briefly across sequential output recreation. Focus telemetry confirmed that the field reacquired active focus.

The separate case-sensitive first-password failure was not used to validate this fix; protocol traces attributed it to aquamarine#375.

A focused regression test covers the retry budget, screen-change trigger, failed-PAM transition, disabled-field guard, focus scope, request handoff, and focus acknowledgement. PR #9181 contains the fix.

View raw text
### System details

* Omarchy 4.0.1-1 (Quattro)
* Hyprland 0.56.2-1
* NVIDIA RTX 3080 Ti
* Two DisplayPort outputs: 2560x1440 at 180 Hz and 200 Hz
* Linux 7.1.9

### What is wrong?

After suspending while the native Omarchy session lock is active, a restored or recreated lock surface can show a password field that does not own keyboard focus. Focus can also be lost while PAM disables the field and then releases it after a failed attempt.

This is separate from the slow-display reblank problem in #7399. It is also separate from the first modifier event lost during input-device restoration, which was later isolated in hyprwm/aquamarine#375.

### Steps to reproduce

1. Suspend through the normal Omarchy path so the session is locked before sleep.
2. Resume and wait for the displays to return.
3. Inspect or interact with the visible password field after output recreation.
4. The field can lack active focus. The same loss can occur after PAM rejects a password and re-enables the field.

### Root cause

`LockView.qml` requested `passwordInput.forceActiveFocus()` only when the component completed or `inputEnabled` changed. During resume, ext-session-lock outputs can be recreated while `inputEnabled` remains true. `Service.qml` already observes `Quickshell.onScreensChanged`, but did not ask the recreated view to reacquire keyboard focus.

On a multi-monitor resume, outputs can return sequentially, so one immediate refocus is not sufficient. PAM also temporarily disables the input during authentication, requiring recovery to pause and restart when the field becomes enabled again.

### Expected

The password field owns keyboard focus whenever the visible lock surface is ready for input, including after output recreation and after a failed PAM attempt.

### Verified fix

A cloned `omarchy.lock` service sends a focus-generation request when the lock becomes secure, whenever screens change, and after PAM releases the input. `LockView` is a `FocusScope`, acknowledges `TextInput.activeFocus`, and the service retries briefly across sequential output recreation. Focus telemetry confirmed that the field reacquired active focus.

The separate case-sensitive first-password failure was not used to validate this fix; protocol traces attributed it to aquamarine#375.

A focused regression test covers the retry budget, screen-change trigger, failed-PAM transition, disabled-field guard, focus scope, request handoff, and focus acknowledgement. PR #9181 contains the fix.

Also reported as

This defect is tracked under R-1214 (filed Aug 30, 2026). 8 other reports describe the same defect.

Earliest report of this defect: R-1571 (filed Aug 22, 2026).

  1. Aug 30, 2026R-1214 · this report— tracked here
  2. ·Decided by agents · verified

    Open upstream.

  3. ·Decided by agents · verified

    Open upstream.

  4. ·Decided by agents · verified

    Closed upstream on 2026-10-12 by the bot omarchybot, as a duplicate (target not recorded).

  5. ·Decided by agents · verified

    Open upstream.

  6. ·Decided by arbitration

    Open upstream.

  7. ·Decided by agents · verified

    Open upstream.

  8. ·Decided by agents · verified

    Open upstream.

  9. ·Decided by agents · verified

    Open upstream.

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/13907· confirmed
  • Related PRpr/8560· confirmed
  • Fixed bypr/7471· confirmed
  • Fixed bypr/8930· 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)
  • Decided by agents · verified: matches no known issue

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