Enable Touch ID for sudo on macOS (sudo_local, Terminal) | Vikas Kapadiya

How to enable Touch ID for sudo in Terminal on macOS. Use /etc/pam.d/sudo_local so it survives OS updates, verify with sudo -k, and fix tmux when fingerprint auth fails.
If you live in Terminal (or iTerm, Ghostty, WezTerm…), sudo is a constant tax. You know the password. You still type it. Or you paste it. Or you fat-finger it and type it again.
Touch ID already unlocks the machine and approves App Store installs. It can authenticate sudo too — use your fingerprint instead of the password, with password still as fallback — and the whole setup takes about a minute.
Omar Shahine (@OmarShahine) laid out the modern path clearly: use Apple’s drop-in file, not the base sudo PAM config older guides still edit.
This post is that idea in my own words: a one-command shortcut if you already use Mole, then the manual sudo_local path so you know what actually changed, plus what to do when Touch ID for sudo is not working (especially inside tmux).
No reboot. The password path does not go away.
Nick Taylor (@nickytonline) pointed out a shortcut on Omar’s thread: if you use Mole (the mo CLI), Touch ID for sudo is one command.
@OmarShahine Mole makes this super easy. `mo touchid`
Install Mole (Homebrew is the straightforward path):
Or with the project’s installer:
That is it. Mole configures Touch ID for sudo for you (still expect a password/Touch ID prompt when it needs admin). Nick covers the same shortcut in his One Tip a Week write-up.
Always verify the result yourself:
Touch the sensor. You should see ok.
Mole is optional. If you prefer zero extra tooling — or you want to see the exact PAM drop-in — use the manual steps below. Same end state: /etc/pam.d/sudo_local with pam_tid.so.
Older write-ups tell you to open /etc/pam.d/sudo and add a pam_tid.so line. That works — until the next macOS update rewrites the file and your change is gone.
On current macOS releases, sudo includes a local drop-in:
You want a line like this near the top of the auth stack:
That include is the whole point. Your custom rules live in /etc/pam.d/sudo_local. Apple can refresh the base sudo file; your local file is meant to stay.
If include sudo_local is missing, you are on an older PAM layout and should not follow this file path blindly.
Skip this if mo touchid already did the job and your verify step printed ok. Useful when you want the durable setup without installing Mole, or you need to debug what is on disk.
Apple ships a template with the right line commented out:
If /etc/pam.d/sudo_local does not exist yet, that is normal. Create it by copying the template and uncommenting the auth line:
Confirm what landed:
You want a single active auth rule (comments above it are fine):
sufficient is the important control word. A successful Touch ID match succeeds auth and stops that part of the stack. A failed or cancelled prompt does not lock you out — PAM continues to the normal password check.
Force a fresh prompt (clear any cached credentials), then run a no-op as root:
Touch the sensor. You should see ok.
Skip sudo -k and you may not get a prompt at all — the previous sudo credentials can still be valid.
If Touch ID still does not appear, open a fresh Terminal tab or window and test again. Cached credentials and a stuck session are the usual false negatives.
Work through this before rewriting files at random:
Inside tmux or screen, Touch ID for sudo often does nothing even when sudo_local looks correct — a common “Touch ID sudo not working” report. The session is detached from the bootstrap namespace Touch ID needs.
Install the reattach helper:
Then put reattach above Touch ID in /etc/pam.d/sudo_local. Order is not decorative — PAM walks the file top to bottom.
Apple Silicon (Homebrew default):
Intel Macs (Homebrew under /usr/local):
If those two lines are reversed, the file can look “right” and still never present Touch ID from a multiplexed shell.
Edit carefully — you need an existing admin session (or a password that still works) to fix a broken PAM file. Make one change, retest with sudo -k; sudo true, then move on.
Coding agents can read /etc/pam.d and draft the exact command, but they usually run without a real TTY. sudo has nowhere to prompt them, so the write has to come from your terminal (or your IDE’s “run in my shell” path).
Hand an agent a tight instruction if you want the setup reviewed first: use sudo_local (not sudo), check existing files, print the command for you to run, and include pam-reattach line order if you use tmux. You still paste and execute the write yourself.
If you already run Mole, the shortest path is mo touchid. If you want the durable setup with no extra tool, skip the one-line edit of /etc/pam.d/sudo that older guides still show. Prefer Apple’s drop-in at /etc/pam.d/sudo_local, one uncommented pam_tid.so line, a hard test with sudo -k, and pam-reattach if your shell lives inside tmux.