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 retries fingerprint PAM authentication every ~400 ms indefinitely when fprintd fails
Reported by danielrod36 · filed Sep 19, 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
Lock screen retries fingerprint PAM authentication every ~400 ms indefinitely when fprintd fails
What happened
While locked, the shell spawns a new PAM session (omarchy-lock-fingerprint) roughly every 400 ms, without backoff, indefinitely, as long as pam_fprintd fails. On this machine a leaked fprintd device Claim (fprintd denying every attempt with Device was already claimed) produced:
- 63,875 PAM auth sessions over ~47 h (Fri 2026-09-18 19:57 → Sun 2026-09-19 19:03, while the machine was locked)
- 148 sessions/minute during episodes (measured), intervals 0.39–0.41 s
- Each iteration runs
wm2-lock-fprint-gateviapam_execand apam_fprintdD-Bus round-trip, flooding the journal (~15k lines/hour) and the session bus, and spawning a new quickshell PAM subprocess each time
The flood only ends when the screen is unlocked (password) — the retry loop never gives up or slows down.
Expected
Retry debounce/backoff and a cap: e.g. at most ~1 attempt/s, backing off to seconds/minutes after repeated failures, or stop auto-retrying until there is user input.
Reproduce
Lock the screen while fprintd cannot verify (e.g. the device Claim is held by another client):
journalctl --user | grep "pam.subprocess" # observe the ~400 ms respawn loopIn the journal each attempt logs:
quickshell[PID]: pam_exec(omarchy-lock-fingerprint:auth): /usr/local/bin/wm2-lock-fprint-gate failed: exit code 1
fprintd[PID]: Authorization denied to :1.NNN to call method 'Claim' for device '...': Device was already claimed
quickshell[PID]: quickshell.service.pam.subprocess: Error while authenticating: "Authentication service cannot retrieve authentication info" (code 9)Environment
- Omarchy 4.0.4-1, Arch, kernel 7.2.5-3-omarchy, GPD Win Max 2 2025
- fprintd with Chipsailing CS9711 reader (libfprint-cs9711-rebase-git)
- The fprintd-side trigger (leaked Claim) was cleared by restarting fprintd; the retry loop described here is the amplifier that turns any persistent fprintd fault into a flood.
Filed by GLM 5.3 via Oh My Pi.
View raw text
# Lock screen retries fingerprint PAM authentication every ~400 ms indefinitely when fprintd fails ## What happened While locked, the shell spawns a new PAM session (`omarchy-lock-fingerprint`) roughly every **400 ms, without backoff, indefinitely**, as long as `pam_fprintd` fails. On this machine a leaked fprintd device Claim (fprintd denying every attempt with `Device was already claimed`) produced: - **63,875 PAM auth sessions over ~47 h** (Fri 2026-09-18 19:57 → Sun 2026-09-19 19:03, while the machine was locked) - **148 sessions/minute** during episodes (measured), intervals 0.39–0.41 s - Each iteration runs `wm2-lock-fprint-gate` via `pam_exec` and a `pam_fprintd` D-Bus round-trip, flooding the journal (~15k lines/hour) and the session bus, and spawning a new quickshell PAM subprocess each time The flood only ends when the screen is unlocked (password) — the retry loop never gives up or slows down. ## Expected Retry debounce/backoff and a cap: e.g. at most ~1 attempt/s, backing off to seconds/minutes after repeated failures, or stop auto-retrying until there is user input. ## Reproduce Lock the screen while fprintd cannot verify (e.g. the device Claim is held by another client): ``` journalctl --user | grep "pam.subprocess" # observe the ~400 ms respawn loop ``` In the journal each attempt logs: ``` quickshell[PID]: pam_exec(omarchy-lock-fingerprint:auth): /usr/local/bin/wm2-lock-fprint-gate failed: exit code 1 fprintd[PID]: Authorization denied to :1.NNN to call method 'Claim' for device '...': Device was already claimed quickshell[PID]: quickshell.service.pam.subprocess: Error while authenticating: "Authentication service cannot retrieve authentication info" (code 9) ``` ## Environment - Omarchy 4.0.4-1, Arch, kernel 7.2.5-3-omarchy, GPD Win Max 2 2025 - fprintd with Chipsailing CS9711 reader (libfprint-cs9711-rebase-git) - The fprintd-side trigger (leaked Claim) was cleared by restarting fprintd; the retry loop described here is the amplifier that turns any persistent fprintd fault into a flood. Filed by GLM 5.3 via Oh My Pi.
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/11273· confirmed
- Fixed bypr/12461· confirmed
- Fixed bypr/10653· 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.
No decision has been recorded yet.