Once: Cache CLI commands
<code>once</code> is a new CLI utility that caches the output of commands for a specified duration, running them only once per tenant or TTL. It gained traction on Hacker News for its elegant solution to common developer frustrations, particularly reducing repeated biometric prompts for secret retrieval from tools like 1Password. This tool offers a smart balance between convenience and security for frequently accessed, static command outputs in development workflows.
The Lowdown
<code>once</code> is a command-line tool designed to execute a given command and cache its standard output for a specified duration. It operates via a lightweight, per-user background daemon that stores command results in memory, serving subsequent identical requests from the cache until expiration. This significantly speeds up workflows by avoiding redundant computations or prompts.<ul><li><strong>Core Functionality</strong>: Executes a command, captures its stdout, and stores it in a daemon. Future calls with the same command, directory (or <code>--no-dir</code> flag), and tenant key retrieve the cached output.</li><li><strong>Daemon Lifecycle</strong>: The daemon automatically starts on a cache miss and gracefully shuts down once all its cached entries have expired, minimizing resource usage.</li><li><strong>Key Features</strong>:<code>--ttl</code> for cache duration (e.g., <code>8h</code>).<code>--until</code> for absolute expiry time.<code>--tenant</code> for creating isolated cache contexts (e.g., per terminal session or project).<code>--no-dir</code> to make caching directory-agnostic for commands like <code>op read</code>.<code>--refresh</code> to force re-execution and cache update.</li><li><strong>Security Model</strong>: Caches are unencrypted in memory, but core dumps are disabled. Access is restricted to the current user via Unix socket permissions, with tenant keys acting as namespaces rather than strict security boundaries.</li><li><strong>Use Cases</strong>: Primarily targets scenarios like retrieving secrets from password managers (e.g., 1Password's <code>op read</code>) to avoid repetitive authentication prompts.</li><li><strong>Limitations</strong>: Outputs larger than 64 MiB are not cached. Only stdout is cached; stdin/stderr pass through. Commands exiting non-zero are not cached.</li><li><strong>Installation</strong>: Simple <code>go install</code> for macOS and Linux.</li></ul>In essence, <code>once</code> provides a simple yet powerful mechanism for developers to optimize their CLI interactions, especially when dealing with operations that are slow, require user interaction, or fetch static data frequently.
The Gossip
Secret Service Solutions: To Cache or Not to Cache?
The primary use case of caching <code>op read</code> output sparked a lively debate. Many users enthusiastically embraced it as a solution to "fingerprint fatigue" from 1Password agents, seeing it as a massive convenience boost that avoids writing secrets to disk. Conversely, some raised security concerns, questioning the wisdom of caching sensitive secrets in memory, even temporarily, arguing it creates a potential new attack surface and that "security by inconvenience" might be preferable. The author clarified that if an agent is already approved, the risk model doesn't change drastically with caching, and it prevents storing credentials in less secure files.
Caching Kin: Comparisons and Competitors
The discussion quickly turned to similar tools and existing practices for command output caching. Several users shared their own shell scripts (like <code>memo</code>) or mentioned other utilities (e.g., <code>bkt</code>, <code>up</code>), highlighting differences in implementation (daemon vs. disk storage). Others mentioned using <code>tmux</code> buffers or even more abstract concepts like NixOS's build caching as related ideas, showing a clear demand for this type of functionality in various forms and contexts.
Terminal Trajectories: Future of Output Management
Beyond <code>once</code>'s specific implementation, some users envisioned broader improvements in terminal output handling. One user wished for a way to cache or recall output *after* a command has run, without needing to prefix it, akin to piping from a scrollback buffer. Another dreamed of an OS-level solution where metadata inherently dictates cache invalidation, similar to NixOS's functional builds, suggesting a more integrated, intelligent system for managing command output dependencies at a fundamental level.