Skip to main content
← Back to list
01Issue
BugOpenSwamp CLIPublic
AssigneesNone

Relationships

#2325 SWAMP_SERVER_TOKEN is ignored with --server unless SWAMP_SERVER_URL is also set to the same host (and SWAMP_SERVER_URL rejects wss://)

Opened by randybias · 9/21/2026

Summary

SWAMP_SERVER_TOKEN is silently ignored when the server is chosen with --server (or SWAMP_SERVE_URL). It is only honoured when SWAMP_SERVER_URL is also set and normalises to the same server. The failure is a generic Authentication failed — run: swamp auth server-login …, which sends users to the OAuth device flow even on a token-mode serve.

The documentation says otherwise: the serve reference says the token comes "from --token, then SWAMP_SERVER_TOKEN, then ~/.config/swamp/servers.json", the skill's serve guide lists SWAMP_SERVER_TOKEN as the env var for server access tokens, and --token's own help reads "falls back to stored credential or SWAMP_SERVER_TOKEN".

Cause

src/infrastructure/persistence/server_credential_repository.ts, FileServerCredentialRepository.get():

const envToken = this.getServerToken();          // SWAMP_SERVER_TOKEN
if (envToken) {
  const envUrl = this.getServerUrl();            // SWAMP_SERVER_URL
  if (envUrl && normalizeServerUrl(envUrl) === key) { return { … token: envToken … }; }
}

The URL that the command is actually talking to (from --server) is never consulted; only SWAMP_SERVER_URL is. Unchanged in 20260918.211634.0-sha.bcaa9695.

A second, smaller inconsistency on the same path: --server wss://host is accepted, but SWAMP_SERVER_URL=wss://host fails with Unsupported protocol: wss: (expected http: or https:).

Reproduction (token-mode serve, valid admin token)

invocation result
swamp workflow list --server wss://<host> --token <t> works (312 workflows)
SWAMP_SERVER_TOKEN=<t> swamp workflow list --server wss://<host> Authentication failed
SWAMP_SERVER_TOKEN=<t> SWAMP_SERVER_URL=wss://<host> swamp workflow list --server wss://<host> Unsupported protocol: wss:
SWAMP_SERVER_TOKEN=<t> SWAMP_SERVER_URL=https://<host> swamp workflow list --server wss://<host> works

Control: a bogus --token is rejected, so the successful rows are real authentications. On the server side the failing rows log WebSocket auth rejected: no token provided, confirming the client never sent it.

Expected

Either honour SWAMP_SERVER_TOKEN for whichever server the command targets (the documented behaviour), or document that it is scoped by SWAMP_SERVER_URL and make the error say so — e.g. "SWAMP_SERVER_TOKEN is set but SWAMP_SERVER_URL is not / does not match ". Accepting wss:// in SWAMP_SERVER_URL the same way --server does would remove the second trap.

Environment: swamp 20260916.001346.0-sha.600af419, Linux x86_64, serve behind an ingress with TLS.

02Bog Flow
◉OPEN○TRIAGED○IN PROGRESS○SHIPPED

Open

9/21/2026, 6:58:09 PM

No activity in this phase yet.

03Sludge Pulse

Sign in to post a ripple.