psst v0.2.0: Environments, Scanning, and psst run

Jan 12, 2026

psst started as one thing: let agents use secrets without seeing them. v0.2.0 makes it a proper secrets workflow.

`psst run`

The original pattern was psst SECRET -- command. Fine for one or two secrets. Awkward for commands that need five.

Now there’s psst run:

psst run -- docker-compose up

Every secret in your vault gets injected into the command’s environment. No listing them individually. The command runs with full access, the agent sees nothing.

Environments

Real projects have dev keys and prod keys. v0.2.0 adds --env:

psst set STRIPE_KEY --env dev
psst set STRIPE_KEY --env prod

psst run --env dev -- npm test
psst run --env prod -- npm run deploy

Same secret name, different values per environment. Switch contexts without juggling vaults.

Secret Scanning

Secrets leak. They end up in git commits, config files, logs. v0.2.0 catches them before they ship:

psst scan .
# Scans current directory for secrets

psst install-hook
# Adds pre-commit hook that blocks commits with secrets

The scanner checks if any of your vault secrets appear in your codebase. It knows what to look for because it knows what you’re hiding.

Tagging

Organize secrets however you want:

psst tag STRIPE_KEY payment api
psst tag DATABASE_URL storage

psst list --tag payment

Useful when you have 30 secrets and need to find the right one.

Local Vault

Vaults now live in .psst/ by default. Commit-safe (encrypted), project-scoped, no global state to manage.

cd my-project
psst init        # Creates .psst/vault.json
psst set API_KEY

Add .psst/ to your repo if you want encrypted secrets in version control. Or .gitignore it. Your call.

The goal hasn’t changed: agents orchestrate, secrets stay invisible. v0.2.0 just makes the workflow less painful.

github.com/Michaelliv/psst