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 fingerprint retry loop never backs off on instant PAM errors
Reported by dsundt · filed Oct 10, 2026 · open at source
R-830 is the earliest report of this defect — filed Sep 8, 2026, open upstream. This report (filed Oct 10, 2026) describes the same defect, so it is folded under it in the inbox.
Decided by agents · verified· Oct 10, 2026
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?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
Lock fingerprint retry loop never backs off on instant PAM errors (heats wedge-prone sensors into sustained failure)
Sibling of #14816 (stale lock model) and #6888. This one is the attempt loop:
against a sensor that errors instantly, the shell spawns a fresh fingerprint
PAM session roughly every 2 s, indefinitely, with no cap or backoff.
Observed (quickshell 0.3.2, omarchy 4.0.0.alpha, SecuGen Hamster Pro 20 via libfprint u20)
User journal during one lock, 20 s window — 10 consecutive sessions, each
failing ~2 s after the prompt with PAM code 9 (PAM_AUTHINFO_UNAVAIL):
quickshell.service.pam.subprocess: Starting pam session for user "dsundt" with config "omarchy-lock-fingerprint"
quickshell.service.pam.subprocess: Relaying pam message: "Place your right index finger on SecuGen Hamster Pro 20"
quickshell.service.pam.subprocess: Error while authenticating: "Authentication service cannot retrieve authentication info" (code 9)(repeated 10×, 11:30:57–11:31:17, then continuing until manual password unlock)
Why it matters beyond noise
The underlying sensor was in a wedged state (activation timeouts — tiny
optical sensor, fprintd had also logged "disabled to prevent overheating"
after earlier burst testing). Each attempt is a full device activation
cycle, so the uncapped loop actively sustains the overheat/wedge it is
failing against: a transient 2-minute thermal throttle becomes a sustained
failure for as long as the lock is up. Touching the sensor during the storm
cannot succeed — attempts die before capture completes.
Suggested fix
Treat N consecutive sub-flow failures as signal, not just bad luck: e.g.
after a handful of back-to-back instant PAM errors, mark the attempt pathfingerprintUnavailable, stop re-arming until the next lock engagement,
and ideally surface "sensor unavailable" distinctly from "no match" so the
user stops pressing a dead sensor. A bounded retry with the existingretryDelayMs backoff extended to the attempt loop (rather than only the
probe loop) would have contained this to seconds.
Happy to test a build; can provide full journal excerpts on request.
View raw text
## Lock fingerprint retry loop never backs off on instant PAM errors (heats wedge-prone sensors into sustained failure) Sibling of #14816 (stale lock model) and #6888. This one is the attempt loop: against a sensor that errors instantly, the shell spawns a fresh fingerprint PAM session roughly every 2 s, indefinitely, with no cap or backoff. ### Observed (quickshell 0.3.2, omarchy 4.0.0.alpha, SecuGen Hamster Pro 20 via libfprint u20) User journal during one lock, 20 s window — 10 consecutive sessions, each failing ~2 s after the prompt with PAM code 9 (`PAM_AUTHINFO_UNAVAIL`): ``` quickshell.service.pam.subprocess: Starting pam session for user "dsundt" with config "omarchy-lock-fingerprint" quickshell.service.pam.subprocess: Relaying pam message: "Place your right index finger on SecuGen Hamster Pro 20" quickshell.service.pam.subprocess: Error while authenticating: "Authentication service cannot retrieve authentication info" (code 9) ``` (repeated 10×, 11:30:57–11:31:17, then continuing until manual password unlock) ### Why it matters beyond noise The underlying sensor was in a wedged state (activation timeouts — tiny optical sensor, fprintd had also logged "disabled to prevent overheating" after earlier burst testing). Each attempt is a full device activation cycle, so the uncapped loop actively sustains the overheat/wedge it is failing against: a transient 2-minute thermal throttle becomes a sustained failure for as long as the lock is up. Touching the sensor during the storm cannot succeed — attempts die before capture completes. ### Suggested fix Treat N consecutive sub-flow failures as signal, not just bad luck: e.g. after a handful of back-to-back instant PAM errors, mark the attempt path `fingerprintUnavailable`, stop re-arming until the next lock engagement, and ideally surface "sensor unavailable" distinctly from "no match" so the user stops pressing a dead sensor. A bounded retry with the existing `retryDelayMs` backoff extended to the attempt loop (rather than only the probe loop) would have contained this to seconds. Happy to test a build; can provide full journal excerpts on request.
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
- Duplicate ofR-830Fingerprint unlock rejected on first attempt after resume (Goodix, race with sleep-lock inhibitor)· decided by agents · verified
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.