Files
SeedPass/js/packages/cli
thePR0M3TH3ANandClaude Opus 5 17b94d3e26 fix(agent): an empty exec allowlist now fails closed; test the allowlist at all
Mutation slice 2 scored 0% before this, and the reason was blunt: **the exec
allowlist had no test whatsoever.** The clipboard restriction could be
inverted, weakened, or deleted outright and the suite stayed green.

That control matters because the clipboard is readable by every process in the
session. A token restricted to `cat` that may still reach the clipboard is not
restricted to anything — the holder simply copies the secret out, and the
allowlist looks enforced while containing nothing. Now tested: a
command-restricted token is refused the clipboard, a token with no allowlist
is not (so the rule is conditional rather than a blanket ban passing as one),
an allowlisted command is permitted, and one outside the list is refused
without the sink ever running.

**A fail-open found while triaging one of the survivors.** An empty
`exec_allowlist` was DROPPED at issue time, which made the token unrestricted.
Automation that computes an allowlist and arrives at zero entries means
"permit nothing" and was silently handed "permit everything" — a fail-open in
the one field whose entire purpose is restriction. It is now refused at issue
time with an error saying which of the two readings the caller probably
wanted. Reachable only over the raw socket protocol, since commander requires
at least one value.

**An audit-accuracy gap.** A denial and a missing entry deliberately return
the SAME message, so the response cannot be used to enumerate ids — the audit
log is where the difference is supposed to be recorded, and nothing read it.
The two reasons could be swapped with every test passing. Testing it needed
two corrections of my own: the CLI resolves references locally so the request
never reaches the daemon, and the shared token in that file is revoked by an
earlier test, so both calls were refused at the token check instead. It also
needed a stronger assertion than the one I first wrote — checking that both
reasons merely APPEAR passes when they are swapped, which is exactly the
mutation. It now asserts the pairing: which id got which reason.

Three survivors are recorded as genuinely unkillable with reasons, rather than
chased: the two `length > 0` comparisons cannot differ from `>= 0` now that an
empty allowlist cannot be stored, and the capability early-return is redundant
with the length check below it.

agent slices 1-2 (mutants 1-16): 100% of viable mutants caught.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01Vtx94nXDmNgXEeThUZP4QN
2026-08-19 16:07:25 -04:00
..
2026-08-14 21:33:28 -04:00
2026-08-14 21:33:28 -04:00

seedpass-js

The SeedPass command-line interface, TypeScript port.

It reads and writes the same ~/.seedpass profiles as the Python implementation — same derivations, same vault format, same Nostr sync — and adds a session agent plus a scoped-token surface designed for AI agents and automation.

Install

Requires Node.js 22 or newer.

# from a checkout
cd js && pnpm install && pnpm --filter @seedpass/cli build
node packages/cli/dist/seedpass-js.mjs --version

The build produces one self-contained file (dist/seedpass-js.mjs) plus a .sha256 next to it. Copy it anywhere on your PATH; it has no runtime dependencies beyond Node itself.

Quick start

export SEEDPASS_APP_DIR=~/.seedpass          # omit to use the default

# Create a profile (mnemonic and password come from the environment,
# never from the command line)
export SEEDPASS_MNEMONIC="your twelve or twenty-four words"
export SEEDPASS_PASSWORD="your master password"
seedpass-js fingerprint add --name main
unset SEEDPASS_MNEMONIC                      # not needed again

# Unlock once per session through the agent
seedpass-js agent start &
seedpass-js vault unlock --ttl 900

seedpass-js entry add password github.com --length 20 --username you
seedpass-js entry reveal github.com
seedpass-js entry totp-codes
seedpass-js use github.com --clipboard
seedpass-js vault lock

Design: reference-first output

Default output never contains secret values. Entries are addressed by reference (sp://entry/<id>), and secret-bearing fields are reported as has_* flags:

$ seedpass-js entry get api-token
{ "id": "5", "ref": "sp://entry/5", "label": "api-token",
  "kind": "key_value", "has_value": true, ... }

Plaintext leaves the vault only through commands that say so (entry reveal, entry totp-codes, entry export-document, util generate-password), or through a sink, which delivers a secret to its destination without routing it through this process's output:

seedpass-js use api-token --exec ./deploy.sh    # SEEDPASS_SECRET in the child env
seedpass-js use api-token --stdin-to "wc -c"    # quote specs that contain flags
seedpass-js use api-token --clipboard

Scoped tokens for agents

An agent can be given a token that grants exactly what it needs and nothing else. Secrets are materialized inside the session agent, so the token holder never receives the seed and can never escalate to owner operations.

# As the owner:
seedpass-js agent token-issue --scope read use \
    --kind key_value --label-regex '^api-' --uses 2 --ttl 600

# In the agent's process — no mnemonic, no password:
export SEEDPASS_TOKEN=<token>
seedpass-js entry list                       # metadata only
seedpass-js use api-token --exec ./deploy.sh # permitted
seedpass-js entry reveal api-token           # denied: scope 'reveal' not granted

# Back as the owner — every grant, delivery and denial is recorded:
seedpass-js agent audit-verify
seedpass-js agent audit-tail -n 20

Environment

Variable Purpose
SEEDPASS_APP_DIR Profile directory (default ~/.seedpass)
SEEDPASS_MNEMONIC Parent seed; needed for profile creation, otherwise use the agent
SEEDPASS_PASSWORD Master password, for fingerprint add and vault unlock
SEEDPASS_TOKEN Scoped token; puts the CLI in token mode
SEEDPASS_AGENT_SOCK Override the agent socket path
SEEDPASS_SECRET Set by use --exec in the child process only

Compatibility

Interoperability with the Python implementation is verified on every change by scripts/cross_impl_check.py: each side opens the other's profiles, backups round-trip, edits are mutually visible, conflict merges agree, and a snapshot published by Python restores here with secrets intact. See docs/typescript_port_compatibility_matrix.md.

Not yet ported: PGP RSA keys (not byte-reproducible; ed25519 is at parity), and the semantic and api command groups.