- memo doesn't need to be built (its a shell script)
- once keeps output cache in a running daemon. By contrast, memo stores content under /tmp with whatever the best compression available is (it prefers zstd). There's trade-offs in that. More pareto-optimal from the security front may be to have a sort of session key and to compress-then-encrypt files on disk.
I dream of applications that expose sufficient metadata about their outputs such that the OS can know if rerunning is necessary without me needing to specify.
I wish this worked without prefixing the commands with "once". Especially if I ran a command with verbose output and afterwards decided I wanted to grep something from it. Terminals have the output in their scrollback buffer and maybe it's just a matter of writing an "output" command that lets me run:
Yes - but I'm out of ideas. How else support long running agents without leaving secrets in files or by default exposed in the environment. That way I get notified the first time before they ask for credentials.
If I already approved it once I already have to assume it could have been leaked. The cache doesn't change much about it if the agent / tenant is asking for something it already has.
I have a small fish function that does something similar. It saves output to a file in XDG_CACHE_HOME. I wouldn’t use it for sensitive items like passwords or tokens in the examples, but I do use it for scripts that need to fetch some data from the network.
For example, I have a script for automating the creation of PRs which fetches the available labels for a repo from github and presents them with fzf multi select. I store the labels with a TTL of a week so that I don’t have to fetch them every time and the script compares the file’s age against the desired TTL to invalidate.
I find it useful for augmenting other programs, but I’m not typically using it on the cli directly.
From the example in the Readme, I guess retrieving a token from an API, using a secret fetched from a secure vault that requests a password or TouchID validation.
Not sure if there could be other interesting uses. I can’t think of one anyways.
Yes, exactly. This is especially frustrating when I leave an agent running for a long time and it gets stuck on my build scripts because it's waiting for my approval.
I just want to avoid leaving my credentials and secrets on the filesystem.
EDIT: I use a lot of direnv / mise. So reloading credentials with different values is common.
I have the same question, especially since any CLI output can be stored explicitly in some variable or temp file. What's the advantage of storing the output implicitly?
I don't want to store them in a file since I don't trust my agents with that data. Instead, the daemon secures the values using/under an HMAC key, making them virtually impossible to guess.
It was discussed in https://news.ycombinator.com/item?id=45670052 and others chimed in with their own (like bkt(1) and up(1)).
The main differences I see:
Edit: Nope, looks like you can't. You only get the invoked command and no output.
Uh I dont know about that one chief.
I'll take security by inconvenience over building what becomes the primary reason for a security incident.
For example, I have a script for automating the creation of PRs which fetches the available labels for a repo from github and presents them with fzf multi select. I store the labels with a TTL of a week so that I don’t have to fetch them every time and the script compares the file’s age against the desired TTL to invalidate.
I find it useful for augmenting other programs, but I’m not typically using it on the cli directly.
Not sure if there could be other interesting uses. I can’t think of one anyways.
I just want to avoid leaving my credentials and secrets on the filesystem.
EDIT: I use a lot of direnv / mise. So reloading credentials with different values is common.