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 screen password field fills with stray keystrokes (lock key auto-repeat / wake keys)
Reported by FerrySchuller · filed Sep 18, 2026 · open at source
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?
- 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
What happened
When the screen is locked (Ctrl+Super+L) and I return to unlock it, the password field already contains a row of masked characters (● dots) that I never typed while looking at the screen.
What was expected
The password field should be empty when I start typing my password.
Steps to reproduce
- Press Ctrl+Super+L to lock the screen.
- Hold the lock combo slightly longer than a single press (or wait until the display blanks, then press a few keys to wake it).
- Wake/unlock the screen.
- The password field shows several masked characters that came from those keystrokes.
Why this happens (from reading the plugin source)
shell/plugins/lock/Service.qml sets inputEnabled: root.lockRequested immediately, and LockView.qml focuses the TextInput right away (Component.onCompleted / onInputEnabledChanged → forcePasswordFocus). There is no debounce/grace period after locking, and no handling for keystrokes that merely wake the blanked display, so:
- the auto-repeat of the held lock-combo keys lands in the field, and
- any keys pressed to wake the blanked screen land in the field.
Suggested fix
- Ignore input for a short grace period (~300–500 ms) after the lock surface gains focus.
- When the display is blanked and a key press triggers wake, consume that key event (do not insert it) and/or clear the field.
System details
- Omarchy 4.0.4-1
- Hyprland 0.56.2
- CPU: Intel Core i7-8665U
- GPU: Intel UHD Graphics 620 (WhiskeyLake-U GT2)
View raw text
## What happened When the screen is locked (Ctrl+Super+L) and I return to unlock it, the password field already contains a row of masked characters (● dots) that I never typed while looking at the screen. ## What was expected The password field should be empty when I start typing my password. ## Steps to reproduce 1. Press Ctrl+Super+L to lock the screen. 2. Hold the lock combo slightly longer than a single press (or wait until the display blanks, then press a few keys to wake it). 3. Wake/unlock the screen. 4. The password field shows several masked characters that came from those keystrokes. ## Why this happens (from reading the plugin source) `shell/plugins/lock/Service.qml` sets `inputEnabled: root.lockRequested` immediately, and `LockView.qml` focuses the `TextInput` right away (`Component.onCompleted` / `onInputEnabledChanged` → `forcePasswordFocus`). There is no debounce/grace period after locking, and no handling for keystrokes that merely wake the blanked display, so: - the auto-repeat of the held lock-combo keys lands in the field, and - any keys pressed to wake the blanked screen land in the field. ## Suggested fix - Ignore input for a short grace period (~300–500 ms) after the lock surface gains focus. - When the display is blanked and a key press triggers wake, consume that key event (do not insert it) and/or clear the field. ## System details - Omarchy 4.0.4-1 - Hyprland 0.56.2 - CPU: Intel Core i7-8665U - GPU: Intel UHD Graphics 620 (WhiskeyLake-U GT2)
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/9211· confirmed
- Related PRpr/11858· 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.