Once caches a CLI command for a while, to stop fingerprint prompts

A developer who stores API keys in 1Password and reads them from a shell is asked for a fingerprint every time a terminal starts. Once, a small Go tool posted to Hacker News this morning and sitting at 54 points today, caches the output of any shell command in a per-user memory daemon so a repeat call returns the cached answer without running the command again.

The repository at alex0ptr/once was created on 8 October 2026 under an MIT licence. The GitHub API reports 59 stars. The author, who posts as alex0ptr, writes that the tool exists so reads from 1Password's CLI, op read, stop asking for a fingerprint on every shell startup.

What a call looks like

A user wraps the command with once, gives it a time-to-live and a tenant key, and runs it. The first call runs the wrapped command, which asks for the fingerprint and prints the token, and the daemon keeps that output in memory for the time-to-live, by default up to twenty-four hours. Every further shell in the same session, with the same tenant key, gets the cached value without a prompt. The daemon stops by itself once its last entry has expired.

The time-to-live is required and takes forms like 30m, 1h, 24h. An absolute --until sets a hard cap, so a token can be held for up to a day but never past ten in the evening. A --refresh flag skips the cache and overwrites the stored value. A --no-dir flag leaves the working directory out of the cache key, which matters because by default two calls to the same read from two different directories miss each other.

How the cache is kept

Entries live in RAM only. The daemon runs under one user, its Unix socket sits in a runtime directory with mode 0700 and the socket itself at 0600, so other users cannot connect. Values are overwritten before they are dropped and the daemon disables core dumps (RLIMIT_CORE zero, plus PR_SET_DUMPABLE zero on Linux) so a cached secret cannot leave through a core file.

The author is clear about what Once does not protect against. Any process running as the same user can talk to the socket and read the tenant key from the environment, so it can read the cache the same way the owner can. The tenant key is a namespace that separates shells and scripts and makes the cache key hard to guess; the README states it is not a secret. Memory is also not locked against swap.

Only standard output is cached, and only when the command exits zero. Standard input and standard error pass through so interactive prompts keep working, and the exit code is forwarded unchanged. Outputs larger than 64 MiB flow through but are not stored.

Why cache a command at all

The Hacker News thread treats Once as the first supported way to turn a one-fingerprint-per-shell pattern into one fingerprint per working session. The same tool also fits any command whose output is cheap to use and expensive to produce: a slow 1Password lookup, a git rev-parse on a huge repository, a shell helper that reads a slow config. Both mise and direnv can call Once from a project environment file, so every shell inside a project loads its variables from the cache once the first shell has unlocked it.

The project runs on macOS and Linux only, needs Go 1.27, and uses nothing outside the Go standard library.

Source

• alex0ptr: alex0ptr/once on GitHub
• Hacker News discussion: Once: Cache CLI Commands