Touch ID for sudo stopped working: the causes and the fixes

When Touch ID for sudo stops working, sudo has not forgotten your fingerprint. One of three things has happened: a macOS update replaced /etc/pam.d/sudo and took your pam_tid.so line with it, the sudo is running somewhere detached from your login session (tmux, screen, an IDE terminal), or Touch ID is unavailable for that request (SSH, a closed lid) and PAM did what it was told and fell through to your password. Each has a different fix, and none of them needs a reinstall.

This post is the diagnosis. If you have never set it up, start with Touch ID for sudo on macOS Sonoma and later, which walks through the files line by line. The studio's Touch ID for sudo is an MIT-licensed script that makes the same edit and reports which state you are in, and it comes up below where it saves a step.

Symptom, cause, fix

First, check what is actually configured

Three commands tell you which row you are on. Start with the include line, which has to be there for anything else to matter:

grep sudo_local /etc/pam.d/sudo
cat /etc/pam.d/sudo_local
bioutil -c

On the Mac this was written on, running macOS 27.0.1, the first prints auth include sudo_local, the second prints the pam_tid.so line, and bioutil -c prints User 501: 1 biometric template(s). No include line means a macOS older than 14, which has no sudo_local and is outside the scope of this fix. No sudo_local, or one whose pam_tid.so line still starts with #, means it was never enabled here, or was enabled in the wrong file. Zero templates means pam_tid has no fingerprint to match against, so it fails and the chain moves on to your password.

If you installed the studio's tool, touchid-sudo --status does the same reading without root. It prints state: as ENABLED or disabled and a tmux/screen: line that is one of supported (pam_reattach active), pam_reattach installed but not configured — re-run to enable, or not supported (pam_reattach not installed).

Then test properly. man sudo says -k "invalidates the user's cached credentials for the current session", and by default the cache is per terminal and lasts five minutes (man sudoers, timestamp_timeout: "The default is 5"). Without it, a sudo that runs silently tells you nothing about Touch ID:

sudo -k
sudo true

It stopped after a macOS update

This is the oldest cause, and the reason sudo_local exists. Before macOS 14 Sonoma the only place to put auth sufficient pam_tid.so was /etc/pam.d/sudo itself, and as Six Colors put it in August 2023, "the file would get overwritten by the stock file every time macOS released a new version". Sonoma added an include of a second file that macOS does not manage. The template Apple ships, /etc/pam.d/sudo_local.template, says so in its first line:

# sudo_local: local config file which survives system update and is included for sudo
# uncomment following line to enable Touch ID for sudo
#auth       sufficient     pam_tid.so

You can see the difference on disk. Here, every Apple-managed file in /etc/pam.d, including sudo and the template, is dated 24 September, the day of the last system update. sudo_local is dated 15 August, the day it was written, and still holds its lines:

ls -l /etc/pam.d/

So if Touch ID went away after an update, look for your line in /etc/pam.d/sudo. It will not be there any more, because that file is now Apple's again. Write the same line into sudo_local and leave /etc/pam.d/sudo alone; the setup post has the exact commands, including the second root shell to keep open while you edit. The include is the first auth line, so sudo_local is consulted before the smart-card and password checks, and man 5 pam.conf defines sufficient as: "If this module succeeds, the chain is broken and the result is success. If it fails, the rest of the chain still runs."

That second sentence explains most of the table above. A pam_tid failure is never an error you see. It is a quiet step down to the next module, which asks for your password.

Touch ID in Terminal, password in tmux or an IDE

The pam_reattach README gives the cause: services tied to the GUI, "such as pasteboard and Touch ID", are "strictly tied to the login session of a user and as such unavailable for programs in the background session". A tmux server outlives the terminal that started it, so a sudo running under it has no route to the session that draws the dialog. The Touch ID for sudo README says the same of editors: VS Code and JetBrains IDEs "run sudo in an embedded terminal that may not be attached to your GUI session".

The fix is the pam_reattach module, installed with brew install pam-reattach and listed in sudo_local above pam_tid.so:

auth       optional       /opt/homebrew/lib/pam/pam_reattach.so
auth       sufficient     pam_tid.so

Three details are where this usually goes wrong:

• Order. Below pam_tid.so, the reattach happens after the prompt has already failed.
• The path. PAM does not search /opt/homebrew, so the pam_reattach README says to give the full path on Apple silicon. Homebrew on Intel uses /usr/local/lib/pam/, and MacPorts /opt/local/lib/pam/. A sudo_local written on one kind of Mac and carried to another can name a prefix that is empty on the new one.
• iTerm2. Its Advanced setting "Allow sessions to survive logging out and back in" is on by default, and its own description says it "breaks the 'auth sufficient pam_tid.so' hack". Turn it off, or keep it and rely on pam_reattach.

From the studio: Touch ID for sudo looks for pam_reattach.so under /opt/homebrew, /usr/local and /opt/local, writes the full path of the one it finds as optional above pam_tid.so, and touchid-sudo --status says installed but not configured when the module is present but sudo_local does not name it.

Open a fresh tmux pane after the change and run sudo -k; sudo true there, not in the pane you edited from.

Over SSH, with the lid closed, or while sharing the screen

Some of the password prompts are correct behaviour rather than faults.

Over SSH. The pam_reattach README notes that "The pam_tid module will try to avoid prompting for a touch when connected via SSH or another remote login method." The person at the keyboard may not be you, so the password is the right answer. If you attach to the same tmux session both at the desk and over SSH, pam_reattach takes an ignore_ssh argument; its man page says it detects "probable SSH sessions" from $SSH_CLIENT, $SSH_CONNECTION or $SSH_TTY and "helps prevent erroneously prompting for a touch when SSH and a terminal multiplexer like tmux(1) is in use".

With the lid closed. In clamshell mode the built-in sensor is unavailable. The Touch ID for sudo README lists it with SSH and Macs without a sensor as cases where Touch ID being unavailable "costs you nothing": pam_tid fails, sufficient passes the request on, and you type your password.

While sharing or recording the screen. A Time Doctor support article reports that "when screen recording, screen sharing, or display capture is active, Touch ID for sudo authentication may be unavailable". Apple does not document this, and we have not found a supported setting that changes it, so the honest fix is the password until the capture stops. Treat any defaults write recipe for it with suspicion until you have seen it work on your own macOS version.

Everywhere at once. Apple's Touch ID guide says "you need to enter your password when you start your Mac", and that "users must re-enter their password every 48 hours and after five incorrect fingerprint attempts". If Touch ID is refusing in other places too, not only in sudo, these rules or an empty bioutil -c are the likely reason, and nothing in sudo_local can change them.

sudo will not run at all

A typo in sudo_local is different in kind: instead of falling through to the password, sudo can report a PAM error and refuse, which leaves you unable to use sudo to fix its own configuration. If a root shell is still open, delete the file from it, and sudo reverts to password-only, because the include then has nothing to add:

rm /etc/pam.d/sudo_local

If not, use macOS Recovery. On Apple silicon, shut down, then press and hold the power button until the startup options appear and choose Options; on an Intel Mac, hold Command-R as it starts. Terminal is in the Utilities menu.

Where to find the file is the part that trips people up. /etc is a symlink to private/etc, and /private is listed in /usr/share/firmlinks, which means it lives on the startup disk's data volume, not on the read-only system volume. The Touch ID for sudo README's Recovery step names /Volumes/Macintosh HD/etc/pam.d/sudo_local, which points at the system volume; the copy to remove is on the data volume. diskutil apfs list shows it as the volume with the (Data) role, and on this Mac it is called "Macintosh HD - Data", though yours may be named differently. In Recovery, unlock and mount it from Disk Utility, check its name with ls /Volumes, then:

rm "/Volumes/<your data volume>/private/etc/pam.d/sudo_local"

Restart normally, and sudo asks for your password again.

Never offered on one account after a password reset

One report does not fit any of the above. On Apple's community forums, a user on macOS 26.5 describes Touch ID never being offered for sudo on one account after a forgotten-password recovery, while new accounts on the same Mac worked. Re-enrolling fingerprints, resetting the keychain and signing out of iCloud Keychain did not fix it, and the reply in the thread (German; paraphrased here) points out that Apple documents no way to reset that state for a single user, leaving a new user account as the only workaround anyone reported.

It is one thread, not a known bug with a cause, so rule out the ordinary rows first: the include line, sudo_local, bioutil -c, and a test after sudo -k. If all four are right and a second account on the same Mac gets the prompt with the same sudo_local, the problem is in that account's Touch ID state, not in PAM, and editing PAM files will not reach it.

Where to start

Run the three checks at the top, then find your row in the table. If you would rather have a script write sudo_local and tell you which state it is in, Touch ID for sudo does both; if you have not set it up at all yet, the setup walkthrough is the place to begin.