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.
Fingerprint unlock stops working after suspend/resume (fprintd claim never released)
Reported by efecege · filed Sep 23, 2026Closed upstream on 2026-10-04 by the bot omarchybot; the closing comment says it was fixed by PR #7158. GitHub close reason: completed.
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
What happened: After suspending and resuming, fingerprint unlock silently stops working. journalctl -u fprintd shows a burst of Authorization denied ... Claim ... Device was already claimed errors starting right at resume, repeating every ~250ms (matching the lock screen's fingerprint retry interval) until fprintd.service is manually restarted. fprintd-list also accumulates multiple stale Device at /net/reactivated/Fprint/Device/N entries for the same physical sensor across repeated suspend cycles, suggesting the claim/device state isn't being cleaned up across suspend.
Expected: Fingerprint unlock keeps working after resume, or fprintd recovers on its own.
Steps to reproduce: Suspend and resume the laptop a few times, then try fingerprint unlock.
Workaround found: Restarting fprintd.service after each resume (e.g. via an /etc/systemd/system-sleep/ drop-in) reliably fixes it — device count drops back to 1 and claims succeed immediately.
System: Omarchy 4.0.4-1 (quattro), Hyprland 0.56.2-2, fprintd 1.94.5-2, libfprint 1.94.100-1, kernel 7.2.3-arch1-3. Lenovo 20QDS3DT00 (ThinkPad), Synaptics Prometheus MIS Touch Fingerprint Reader (USB 06cb:00bd).
View raw text
**What happened:** After suspending and resuming, fingerprint unlock silently stops working. `journalctl -u fprintd` shows a burst of `Authorization denied ... Claim ... Device was already claimed` errors starting right at resume, repeating every ~250ms (matching the lock screen's fingerprint retry interval) until `fprintd.service` is manually restarted. `fprintd-list` also accumulates multiple stale `Device at /net/reactivated/Fprint/Device/N` entries for the same physical sensor across repeated suspend cycles, suggesting the claim/device state isn't being cleaned up across suspend. **Expected:** Fingerprint unlock keeps working after resume, or fprintd recovers on its own. **Steps to reproduce:** Suspend and resume the laptop a few times, then try fingerprint unlock. **Workaround found:** Restarting `fprintd.service` after each resume (e.g. via an `/etc/systemd/system-sleep/` drop-in) reliably fixes it — device count drops back to 1 and claims succeed immediately. **System:** Omarchy 4.0.4-1 (quattro), Hyprland 0.56.2-2, fprintd 1.94.5-2, libfprint 1.94.100-1, kernel 7.2.3-arch1-3. Lenovo 20QDS3DT00 (ThinkPad), Synaptics Prometheus MIS Touch Fingerprint Reader (USB 06cb:00bd).
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.