Enabling Fingerprint Unlock for Bitwarden (Desktop Flatpak + Browser Extension) on CachyOS / (Arch)-based Distros with KDE Plasma
Symptoms this fixes — there are two separate issues, encountered in sequence:
- Connection issue: Bitwarden browser extension shows “Awaiting confirmation from desktop” and just hangs — the desktop app never responds at all.
- Auth method issue: once the connection issue above is fixed, the extension successfully reaches the desktop app, but the resulting OS-level prompt only offers a system password, not fingerprint — even though
fprintdalready has fingerprints enrolled.
These are caused by two unrelated things, and you may only need to fix one depending on where you’re stuck. Read both sections below; fix Part 2 (connection) first if you’re seeing the “Awaiting confirmation” hang, then Part 5 (fingerprint-vs-password) if the prompt itself shows up but only takes a password.
Background / why this happens
Bitwarden’s biometric unlock relies on the OS-level polkit authentication framework, not its own fingerprint handling. Polkit in turn delegates to PAM (typically via a polkit-1 service file that includes system-auth). If system-auth doesn’t have pam_fprintd.so configured, polkit (and therefore Bitwarden) will only ever offer password auth — even if fingerprint already works for login/sudo elsewhere. This is issue #2 above, and it can only be diagnosed once the dialog actually appears.
If you’re running Bitwarden as a Flatpak, there’s a separate, earlier problem: the sandbox needs explicit filesystem access to your browser’s native-messaging-host directory, or the extension-to-desktop handshake never completes and you never even get to an OS prompt. This is issue #1 above — it’s what causes the “Awaiting confirmation from desktop” dialog to hang indefinitely with no system prompt appearing at all.
In other words: if you’re stuck on a hang with no OS prompt, you’re dealing with issue #1 (Part 2 below). If you’re getting an OS prompt but it’s password-only, you’re dealing with issue #2 (Part 5 below). It’s normal to hit and fix #1 first, then immediately run into #2 once the connection actually works.
Note on file locations: paths below (especially the PAM file location) vary across distros and even across individual setups depending on how your system was installed/customized. Always check both /etc/pam.d/ and /usr/lib/pam.d/ (see Part 5) rather than assuming one or the other.
Part 1 — Polkit policy file (lets Bitwarden register a polkit action at all)
sudo wget -O /usr/share/polkit-1/actions/com.bitwarden.Bitwarden.policy https://raw.githubusercontent.com/bitwarden/clients/main/apps/desktop/resources/com.bitwarden.desktop.policy
sudo chown root:root /usr/share/polkit-1/actions/com.bitwarden.Bitwarden.policy
Note: skip any chcon step from official Bitwarden docs — that’s SELinux-specific and doesn’t normally apply to Arch-based systems (generally speaking; you can run it and see what happens, though), which typically use AppArmor or nothing at all.
Part 2 — Flatpak sandbox permissions (fixes issue #1: the “Awaiting confirmation” hang)
Only needed if using the Flatpak build of Bitwarden desktop.
Check current permissions:
flatpak info --show-permissions com.bitwarden.desktop
If your browser isn’t Chrome/Edge/Chromium/Firefox (e.g. Brave), its native messaging host path likely won’t be in the default allowlist. Add it manually — adjust the path for your actual browser:
flatpak override --user --filesystem=~/.config/BraveSoftware/Brave-Browser/NativeMessagingHosts com.bitwarden.desktop
Verify it stuck:
flatpak info --show-permissions com.bitwarden.desktop
You should see the path now listed under filesystems= in [Context].
Restart both apps fully - Change the letter p in pill to a k, since the forum won’t allow that word:
flatpak pill com.bitwarden.desktop
(then fully quit and relaunch your browser too — not just close the window)
Part 3 — Verify the polkit/KDE auth agent is running
ps aux | grep polkit-kde
You should see polkit-kde-authentication-agent-1 running. If not, your DE session isn’t running the KDE polkit agent and dialogs won’t appear at all (this is normally automatic under Plasma).
Part 4 — Confirm fingerprint is enrolled
fprintd-list $USER
Should list at least one enrolled finger. If empty, enroll one first:
fprintd-enroll
Part 5 — Wire fingerprint into PAM (fixes issue #2: “password prompt instead of fingerprint”)
First, find where your polkit-1 PAM service file actually lives — this is the part that varies by distro/setup:
ls /etc/pam.d/ | grep polkit
ls /usr/lib/pam.d/ | grep polkit
On many modern Arch-based systems, system-shipped PAM configs live under /usr/lib/pam.d/, with /etc/pam.d/ reserved for local overrides (which take precedence if both exist). Some setups will have it under /etc/pam.d/ directly. Either way, check its contents:
cat /usr/lib/pam.d/polkit-1 # or /etc/pam.d/polkit-1, whichever exists
A typical version just includes system-auth for everything:
#%PAM-1.0
auth include system-auth
account include system-auth
password include system-auth
session include system-auth
If that’s the case, the real fix happens in system-auth, not in polkit-1 itself. Check it the same way:
ls /etc/pam.d/ | grep system-auth
ls /usr/lib/pam.d/ | grep system-auth
cat /etc/pam.d/system-auth # use whichever path actually exists on your system
If there’s no pam_fprintd.so line anywhere in that file, that’s the gap. Back up the file first:
sudo cp /etc/pam.d/system-auth /etc/pam.d/system-auth.bak
Edit it (sudo nano /etc/pam.d/system-auth or your preferred editor — adjust path if yours is under /usr/lib/pam.d/ and you’ve confirmed there’s no local override mechanism, though editing under /etc/pam.d/ as an override is generally safer and update-proof). Add this line after any pam_faillock.so preauth line and before the pam_systemd_home.so / pam_unix.so lines:
auth sufficient pam_fprintd.so max_tries=3 timeout=15
Example of what the top of the auth block should look like afterward:
auth required pam_faillock.so preauth
auth sufficient pam_fprintd.so max_tries=3 timeout=15
-auth [success=2 default=ignore] pam_systemd_home.so
auth [success=1 default=bad] pam_unix.so try_first_pass nullok
auth [default=die] pam_faillock.so authfail
auth optional pam_permit.so
auth required pam_env.so
auth required pam_faillock.so authsucc
(Your exact file may differ slightly — just insert the pam_fprintd.so line in the same relative position, before the main password-checking line.)
Safety check before logging out or rebooting: keep a second terminal/SSH session open, and in your original terminal run:
sudo -k && sudo true
This should now prompt for fingerprint first, falling back to password if it fails or times out. If something’s broken and you get locked out of sudo, restore the backup from your second session:
sudo cp /etc/pam.d/system-auth.bak /etc/pam.d/system-auth
Once sudo correctly uses fingerprint-first, polkit will typically inherit the same behavior automatically via its include system-auth line — no separate polkit-specific PAM edit needed in most setups.
Security note: using sufficient (fingerprint-first with password fallback) rather than fingerprint-only is intentional — fingerprint-only auth for polkit/sudo has been flagged as a potential security issue (background processes could request authorization without a deliberate fingerprint prompt). The fallback structure above avoids that.
Part 6 — Final test
- Fully quit Bitwarden desktop and browser
- Relaunch desktop app, then browser
- Open browser extension → Settings → Security → “Unlock with biometrics”
- You should now get a fingerprint prompt (falling back to password after ~15s / 3 failed attempts)
Quick troubleshooting summary
| Symptom | Issue # | Likely cause |
|---|---|---|
| Extension hangs on “Awaiting confirmation from desktop” forever, no OS prompt ever appears | #1 | Flatpak sandbox can’t see browser’s native messaging host dir (Part 2) |
| Desktop app never shows any auth prompt, even after fixing Part 2 | #1 (related) | KDE polkit agent not running (Part 3) |
| OS prompt now appears, but only offers password | #2 | pam_fprintd.so missing from system-auth (Part 5) |
fprintd-list shows nothing |
— | No fingerprint enrolled yet (Part 4) — needed regardless of which issue you’re on |
Support provided by Claude.