## What happened

This machine's fingerprint sensor — a Dell XPS 15 7590 with the Goodix `27c6:5395`
("Goodix HTK32") — has no driver in the pinned `libfprint-git` snapshot. The community
fork [`libfprint-goodix53x5`](https://aur.archlinux.org/packages/libfprint-goodix53x5)
([upstream](https://github.com/AndyHazz/goodix53x5-libfprint), built on libfprint tag
`v1.94.10`, `provides=('libfprint' 'libfprint-2')`) adds the driver and works perfectly.

With the fork installed and the reader working, running
`omarchy setup security fingerprint` (also reachable from the launcher's
Setup → Security → Fingerprint row) destroys the working setup:

1. The script's gate is `omarchy-pkg-missing libfprint-git ...`. The helper runs
   `pacman -Q "$pkg"`, which is provides-aware — but **no fork can ever provide the
   literal name `libfprint-git`**, so the check reports "missing" on a correctly working
   machine.
2. The script then runs
   `sudo pacman -S --needed --noconfirm --ask 4 libfprint-git fprintd usbutils`.
   The script's own comment states `--ask 4` exists to "accept the replacement in one
   transaction" — so pacman removes the working fork and installs `libfprint-git`
   without any prompt.
3. The script immediately calls `sudo fprintd-enroll`. fprintd is D-Bus-activated with
   a 30-second idle exit, and the **already-running daemon still has the fork's
   `libfprint-2.so` mapped in memory**. Enrollment and verification therefore *succeed*
   against the replaced driver. The script writes the PAM stacks and prints
   "Perfect! Fingerprint authentication is now configured."
4. When fprintd next starts (idle timeout, reboot, etc.) it loads the on-disk
   `libfprint-git`, which has no driver for `27c6:5395`. `fprintd-list` reports
   `No devices available` — permanently, and silently, since
   `auth sufficient pam_fprintd.so` just falls through to the password prompt.

The same sequence, from this machine's pacman.log and file mtimes (setup day):

```
01:39:34  installed libfprint-goodix53x5   → reader works, enrollment succeeds
01:40:31  removed libfprint-goodix53x5 + installed libfprint-git   (the script's own pacman -S)
01:41:01  /etc/pam.d/{sudo,polkit-1,omarchy-lock-fingerprint} written by the script
          (enroll/verify "passed" via the stale in-memory fork)
          thereafter: fprintd-list → "No devices available" until the fork was
          reinstalled by hand
```

Empirical confirmation that the pinned libfprint cannot drive this reader: with
`libfprint-git` installed, `fprintd-list` reproducibly reports `No devices available`
while the kernel enumerates the USB device normally; replacing the package with the
fork (same `fprintd`, same daemon restart, same user store) makes the device appear
and enroll/verify immediately.

> **Related observation (enroll UX):** the journal also shows
> `fprintd: Authorization denied ... to call method 'Claim' for device 'Goodix HTK32
> Fingerprint Sensor': Device was already claimed` when enrollment is attempted while
> the lock screen holds the reader. Setup-time enrollment competing with hyprlock's
> claim makes the wizard's interactive step hang or misreport state; worth handling
> (e.g. release/skip the lock claim during enrollment) in whatever enroll flow the
> setup uses.

## What was expected

A setup command should never tear down a driver that is currently working, and should
not certify success with an enrollment that a 30-second-old daemon process performed
using a library that no longer exists on disk.

## Steps to reproduce

1. On a machine whose reader is only supported by a libfprint fork that
   `provides=('libfprint')` (e.g. `libfprint-goodix53x5` for Goodix `27c6:5395`),
   install the fork and confirm `fprintd-list "$USER"` shows the device.
2. Ensure fprintd is running (any `fprintd-*` call starts it; it exits 30s after last use).
3. Run `omarchy setup security fingerprint`.
4. Observe: the pacman transaction removes the fork; enrollment "succeeds"; PAM is written.
5. Wait ~30 seconds; run `fprintd-list "$USER"` → `No devices available`.

## Proposed fixes

1. **Gate on the device, not on a package name.** The real question is "can fprintd
   enumerate the reader right now?" If a `fprintd-list`-style probe finds the device,
   skip the package transaction entirely — whatever is installed is, by definition,
   working. (This also fixes the failure class in #11841: a device-based probe can say
   "your reader has no driver in any available libfprint build", instead of the generic
   "Enrollment failed. Please try again.")
2. **If the transaction did replace a libfprint implementation, `systemctl try-restart fprintd` before enrolling.** Success must be judged against the on-disk library;
   otherwise the script's careful ordering (PAM only after enroll+verify passes) is
   defeated by D-Bus socket activation and the 30s exit timeout, and it writes the PAM
   stack for a driver it just removed.
3. **Make the setup entry idempotent, or remap it** — #11841 covers diagnosis for
   unsupported readers; this covers the supported-by-something-else case. A
   machine with `fprintd` working and PAM already configured gains nothing from a
   package re-install; the launcher row could offer an "add another finger"
   (`fprintd-enroll -f <finger>` / view enrolled fingers) flow when it detects an
   already-configured system, and reserve the full setup for machines that need it.
   As shipped, one stray Enter on `setup.security.fingerprint` reverts a
   community-driver machine to broken.

## System details

- `omarchy version`: 4.0.3-1
- Kernel: 7.2.3-arch1-3 (Arch)
- Laptop: Dell XPS 15 7590 (DMI-confirmed) — Intel i7-9750H, UHD 630
- Reader: Shenzhen Goodix `27c6:5395` "Goodix HTK32 Fingerprint Sensor"
- Packages: fprintd 1.94.5-2; libfprint-goodix53x5 1.94.10-10 (working) vs
  libfprint-git 1:1.94.100.r10.g6f9479c-1 (pinned; no matching driver)

---

Filed by qwen/qwen3.8-flash via pi (agent-generated report; evidence gathered interactively with the user on the affected machine).