sudo-touchid puts a fingerprint in front of every sudo prompt on macOS

The design decision is a separate PAM file, not a patched sudo

The mechanism on macOS 14 and later is the part worth understanding. The script creates /etc/pam.d/sudo_local with TouchID configuration, and it never modifies the system managed /etc/pam.d/sudo file. That is a deliberate architectural choice with two consequences. The first is durability. Because the configuration lives in its own file, a macOS system update that replaces the managed sudo file does not remove the Touch ID setup, which is the reliability claim the README makes about persistent configuration across system updates. The second is reversibility. Removing the setup means removing a file you added rather than restoring a file you edited, which is a much smaller thing to get wrong on a machine where a broken PAM stack means a broken sudo. The consequence for anyone who wants to understand what happened on their machine is that the change is auditable in one known location, and the script is a Bash script you can read before running it.

Everything the tool does is in one Bash file with no dependencies

The project is described as written in Bash with no dependencies, and the repository layout backs that up. The top level holds sudo-touchid.sh, which is the whole implementation, plus install.sh, a Makefile, a Brewfile and its lock file, a com.user.sudo-touchid.plist, res/ for the icon and preview image, docs/ for the legacy document, tests/, a SECURITY.md and the LICENSE. The stated advantages are productivity, in that it automates TouchID setup, lightness, as a small Bash script with no builds or Xcode required, and reliability through persistent configuration across system updates. The absence of a build step is the point. Most PAM based biometric setups for sudo on macOS involve compiling a module against the Security framework, and this avoids that entirely, which is also why it can be tried without installing anything.

You can run the whole thing from a curl pipe before installing it

The README leads with a try it out section that skips installation entirely. The command pipes a script straight into sh:

curl -sL git.io/sudo-touch-id | sh

The link is a shortener that resolves to the install script, and the script is bundled with macOS, so nothing needs to be installed to run it. The same trick is available for the main tool, and it accepts the same arguments such as -d or -v:

sh <( curl -sL git.io/sudo-touch-id )

The prompt for this section notes that you can reverse it, which is the sensible caveat. Piping a script from the internet into a shell that touches your authentication configuration is a reasonable thing to want and a reasonable thing to be careful about, and this project is candid enough that the option to undo it is mentioned right next to the command. For a permanent installation, Homebrew is the route, with the formula published in the author's tap:

brew install artginzburg/tap/sudo-touchid

A manual install is also possible, saving sudo-touchid.sh as /usr/local/bin/sudo-touchid with execute permissions.

The flag set covers version, removal, migration and verbosity

The usage text is the complete API, and it is short enough to read once:

# Usage:
sudo-touchid [options]
             [-v,  --version]   # Output installed version
             [-d,  --disable]   # Remove TouchID from sudo config
             [--with-reattach]  # Include pam_reattach.so for tmux/screen support
             [--migrate]        # Migrate from legacy configuration
             [--verbose]        # Show detailed output
             [-q,  --quiet]     # Show minimal output (errors only)
             [-y,  --yes]       # Skip confirmation prompts (non-interactive mode)

The two that matter operationally are --disable, which removes all TouchID configurations, and --migrate, which handles the case where you are coming from an older setup. The --with-reattach flag adds the pam_reattach.so module for tmux and screen compatibility, which is the problem of a GUI authentication prompt inside a terminal multiplexer, and the --yes flag is what makes the script usable from an automated provisioning run. Running the tool with no arguments adds TouchID to the sudo configuration, or migrates an existing legacy configuration if you are upgrading from macOS 13 or below.

The legacy path and the reattach option are the two fiddly edges

Two things in this tool need care, and the README links to a separate document for the first. The legacy document exists because macOS 13 and below behave differently, and the repository links to LEGACY_MACOS.md for additional considerations on older systems, with a separate docs/LEGACY_MACOS.md path in the tree. On those systems, the old approach edited the system managed sudo file, which is why the migration path and the backup behaviour exist at all, since the script creates backup files during migration and automatically detects and migrates legacy configurations. The second edge is the terminal multiplexer. Touch ID needs a GUI session to present its prompt, so inside tmux or screen the normal flow breaks, and the pam_reattach module is the fix, built in via --with-reattach. The related work section names the projects it draws on, including pam_reattach and pam_watchid for Apple Watch unlocking, and the pam_watchid entry points to a different module for a different biometric. If you work in tmux regularly, that flag is not optional for you.

There is a documented way to remove the password prompt entirely

The related section is worth a second look, because it contains a change that is more consequential than anything the script does. Alongside the tmux and screen support, there is a line about disabling the password prompt, which is done by changing the sudoers rule from %admin ALL=(ALL) ALL to %admin ALL=(ALL) NOPASSWD: ALL in /etc/sudoers. That is a different thing from what this project does. Touch ID replaces the password with a fingerprint, which still proves who is at the keyboard. NOPASSWD: ALL removes the authentication step for members of the admin group entirely, so anyone who can get a session as an admin user becomes root without proving anything. The script deliberately does not do that, and the difference is the point of the tool. It is mentioned in the README as a related option rather than a feature, and it is the kind of edit that belongs in a change ticket with a rollback plan rather than in a curl pipe.

The maintenance record is uneven across the three releases

The repository is not archived and the last push was on 2026-07-30, so the code is being touched. The release history is less regular. Version 0.5 is dated 2025-09-17, and before that version 0.4 is from 2022-02-20 with a note about usage help and a bugfix, and version 0.3 is from 2021-11-10 with an interface and shell update. So there is a long gap between 0.4 and 0.5, roughly three and a half years, and then a burst of work in September 2025. The macOS 14 and later design with its own sudo_local file appears to be the newer approach, and the legacy branch of behaviour is what 0.4 and earlier used, which is why the migration path exists. The licence is EPL-2.0, which is a copyleft licence with a file-level exception character, and the tree carries a SECURITY.md, which is a good sign for a project that modifies a security related file on your machine. The Makefile is two targets, bundle for brew bundle and check for running shellcheck against sudo-touchid.sh.

Where sudo-touchid is the wrong choice

Three cases argue against it. The first is a non-macOS machine, since this is Touch ID and PAM on macOS, and the Linux equivalent is a different configuration entirely with different modules and a different security conversation about what the fingerprint proves. The second is a shared or managed Mac, where the administrator may not want per-user PAM configuration on a machine that several people use, and where the fingerprint authenticates a person rather than a session, which changes the threat model for anyone who can put their finger on the sensor. The third is an environment where sudo is not how you get root, such as a machine where the admin uses a managed deployment tool, because this tool edits the local sudo configuration on one machine and does not scale to a fleet. There is also a limit worth stating plainly. Touch ID is a convenient factor, though not a stronger one than a good password in every sense. For a personal machine where the person who owns it is the person using it, that trade is clearly worth it. For a shared build server, the reasoning runs the other way, and the honest alternative there is not a different script but a different answer to the question, namely not putting sudo in the daily path at all.

Editorial conclusion

Adopt sudo-touchid if you are on macOS and want Touch ID for sudo without a third party PAM build of your own, and skip it if you are on Linux, where the equivalent is a different PAM configuration, or if your security policy forbids biometric elevation of a root shell. Verify first that your macOS version is 14 or newer, or read the legacy document if it is 13 or below, and check what your existing /etc/pam.d/sudo_local contains before running the script, since it creates that file.

Frequently asked questions

Official sources

1. artginzburg/sudo-touchid on GitHub
2. License: EPL-2.0
3. Project website
4. README
5. Releases