Skip to main content
← Back to list
01Issue
BugShippedSwamp CLI
Assigneesstack72

Relationships

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

Opened by sntxrr · 8/7/2026· Shipped 8/7/2026

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
  • #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
02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED+ 1 MOREASSIGNED+ 2 MOREREVIEW+ 4 MOREPR_MERGED+ 2 MORESESSION_SUMMARIZED

Shipped

8/7/2026, 3:06:31 AM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack728/7/2026, 2:19:51 AM
Editable. Press Enter to edit.

stack72 commented 8/7/2026, 3:06:40 AM

Thanks @sntxrr for reporting this! The fix has been merged and a release is on its way. We appreciate your contribution to swamp.

Sign in to post a ripple.