sudo

2026-01-12

From the changelog for 2023's macOS Sonoma:

Touch ID can be allowed for sudo with a configuration that persists across software updates using /etc/pam.d/sudo_local. See /etc/pam.d/sudo_local.template for details.

Right now, open your terminal and run:

sudo sh -c "echo 'auth sufficient pam_tid.so' >> /etc/pam.d/sudo_local"

The next time you run a command with sudo, instead of typing your password:

sudo echo "hi." with a password prompt

You can use your fingerprint:

sudo echo "hi." with a Touch ID prompt

Mostly Unrelated Thing #1

Apparently /etc is supposed to be read "et cetera"¹. 70s programmers had style.

Mostly Unrelated Thing #2

You can actually store and retrieve arbitrary KV pairs from the macOS Keychain programmatically:²

security add-generic-password \
    -a "project name" \
    -s "key name" \
    -U -T "" -w

Normally, -w is followed by the password to store. An argument-less -w at the end causes security to prompt for the password, instead, keeping it out of shell history.
-U updates the item if it already exists.
Without -T "", the security program itself is granted future access to the item, without prompting for permission.

To retrieve:

security find-generic-password -a "project name" -s "key name" -w

-w prints the password to stdout.

Check man security for details, it's a surprisingly full-featured service. I haven't yet found a way to have security prompt for Touch ID instead of the login password; I'll update this post if I figure it out.

https://archive.org/details/unixprogramminge0000kern/page/62/, although it's tragically omitted from a modern man hier. ↩︎
This can be nice if you have some coding agent trying various things out, and you'd rather pause for reflection before it starts doing anything serious enough to warrant accessing your secrets.
When I say "secrets", although API keys are the obvious example, it really can be any piece of information that gates access to some sensitive operation, remote or local. Think: keys to decrypt local files (for running automation on finances, whatnot), sentinel values for operations like "ALLOW_DB_RESET", "ALLOW_DISK_FORMAT", etc.
This way, too, the contents of your .env file are a bit less likely to end up on Anthropic's servers. Honestly though, .env files full of API keys have been an abysmal idea since well before LLMs. Secrets shouldn't exist on the same data-plane as code. Replace "keychain" with "a python script that reads and writes to a plain-text csv in /var", and it's basically the same gain. ↩︎