#1549 access token mint prints an invalid retrieval command (vault get, not vault read-secret)

Summary

swamp access token mint no longer prints the plaintext (per the swamp-club#1466 change noted in #1472). Instead it prints a retrieval hint — but that hint is not a valid command, so the token it just minted cannot be retrieved by following its own instructions.

Minting emits:

Vault: serve-local (key server-token-swamp-ui)

Retrieve the token with: swamp vault get serve-local server-token-swamp-ui

Running exactly that:

Error: Unexpected argument: server-token-swamp-ui

Usage: swamp vault get <vault_name_or_id>

To retrieve a secret value, use: swamp vault read-secret <vault_name> <key>

vault get takes only a vault name. The correct command is vault read-secret (added in #238).

Steps to reproduce

1. swamp vault create local_encryption serve-local
2. swamp access token mint swamp-ui --principal user:sntxrr --duration 365d --vault serve-local
3. Copy the Retrieve the token with: line verbatim and run it
4. It fails with Unexpected argument

Two follow-on papercuts on the same path

Both were hit immediately after correcting the command, so a fixed hint would ideally cover them:

1. read-secret refuses to run non-interactively without --yes: Error: stdin is not a terminal — use --yes (-y) to skip confirmation prompts non-interactively. Any scripted retrieval (CI, entrypoint, deploy script) needs --yes, which the hint would not tell you. Compare #1290, which standardised --yes.

2. The vault stores only the secret half, not the wire format. read-secret returns a bare 64-char secret, but serve expects <name>.<secret>. So even after finding the right command, passing the retrieved value straight to a client fails to authenticate, with no hint that the token name must be prepended. The mint output shows Token: swamp-ui and the vault key separately, but never states that the client format is the concatenation.

Suggested fix

Emit the working command, e.g.:

Retrieve the token with: swamp vault read-secret serve-local server-token-swamp-ui --yes
The client token is <name>.<secret> — prepend the token name: swamp-ui.<secret>

Impact

This is the documented headless path. The container case is exactly where the plaintext cannot be recovered any other way — it was never displayed — so a wrong hint means the operator has a minted, active token they cannot use, and the natural next guess (re-mint) leaves a second live token behind.

Environment

• swamp 20260806.001601.0-sha.5bfddaa2 (also reproduced on 20260805.130625.0-sha.4e45e221)
• swamp serve --auth-mode token, running in a Debian container
• Vault type: local_encryption

Related

• #1472 — docs bug for the same change; it describes the emitted swamp vault get hint as the expected new behaviour, so this one is the hint itself being wrong rather than a duplicate
• #238 — added vault read-secret
• #1290 — --yes as the standard non-interactive confirmation flag