Consent for command-line credentials
secreq wraps the CLIs you use every day — gh, aws, kubectl, psql — so each invocation pulls its credentials from your own secret store. Every release is gated by a prompt that names the process asking, and every value is masked on the way back out.
It is a PATH shim, not a shell alias, so it catches the requests you did not type: an npm postinstall, a Makefile, an agent running in your editor.
$gh auth login
GITHUB_TOKEN •••••••••••• released, masked
gh wants to use GITHUB_TOKEN
secreq installs itself ahead of the real binary on your PATH. Every execvp("gh", …) lands here first — including the ones inside npm, make, cargo and your editor, which a shell alias would never see.
The prompt walks the process tree and shows it to you: the shell, the script it launched, the binary at the end of the chain. Approval is scoped to that direct parent, so answering yes for your shell does not answer yes for a postinstall hook.
The secret is fetched from your provider, handed to the binary, and redacted from its stdout and stderr. It never lands in your shell history or your scrollback.
Provenance
A credential request tells you nothing on its own — "something wants your GitHub token" is not a question you can answer. secreq reconstructs the process chain that led to the request and puts it in front of you, so the answer is obvious.
The consent window →Rules
Approving the same request all afternoon is how consent prompts become noise you click through. Save a rule and secreq answers for you — matched on the wrap, the arguments and the ancestor process, so it stays narrow.
Rules and suggestions →Audit
What asked, what it wanted, where from, and how it went — your answers, rule auto-fires, and the requests that were abandoned before you got to them. Searchable across every field at once.
Reading the audit log →SSH
Point SSH_AUTH_SOCK at secreq and it becomes your agent. Each signature shows the key fingerprint and the reason before it happens; the private key is resolved from your provider, used in memory, and zeroized.
The SSH agent →SSH_AUTH_SOCK at secreq and every signature is gated. You see the key fingerprint and the reason before git push signs, plus quiet grants covering a 30-minute session.Sandboxes
A guest has no host process tree, so there is no caller chain to verify — the scope you declared when you opened the socket is the principal instead. If a guest volunteers a chain, it is shown as a claim and marked unverifiable.
The secret agent →secreq agent open you started.Ad hoc
secreq run is op run for every store: resolve ambient secret:// references from the environment or an --env-file, then exec your command with the values injected and masked. No wrap required.
CLI reference →secreq run carrying 42 variables leads with the count and groups the secrets by locator prefix. The body scrolls; the decision buttons never leave the window.Two minutes
secreq wrap gh asks what the wrap should do, which provider holds the secret, and where. It resolves the locator against your store before writing anything, so a mistyped path fails while you are still looking at it — not the first time you run gh next week.
gh.curl -fsSL https://craigory.dev/secreq/install.sh | shInstalling creates no wraps — nothing on your PATH changes until you ask for it. secreq init sets up the shim directory and walks you through your first wrap.
The full platform matrix and signature verification are in the install guide.