Skip to main content
← Back to list
01Issue
FeatureShippedSwamp CLIPublic
Assigneesstack72

Relationships

#1691 feat(serve): use identifiable OAuth client_name instead of random UUID

Opened by stack72 · 8/17/2026· Shipped 8/18/2026

Context

When swamp serve registers an OAuth client via POST /api/auth/oauth2/register, it uses swamp-serve-${crypto.randomUUID().slice(0, 8)} as the client_name (src/serve/oauth_registration.ts L186). This produces names like swamp-serve-a3f1b2c9 that can't be traced back to a host, repo, or deployment.

Even if a collective adds a UI or API to list registered OAuth clients (see #1683), the names are unactionable — an operator can't tell which entries are live and which are abandoned.

Proposed change

  • Default client_name to swamp-serve-{repoName}-{hostname} so registrations are identifiable without any extra configuration.
  • Add an --oauth-client-name flag to swamp serve that overrides the default. This lets k8s operators set it via env var in their deployment spec for environments where hostname isn't meaningful.

Not a breaking change

client_name is a registration-time label sent to the server — it's not used as an identifier afterward. The server uses client_id (the UUID it returns) as the actual identifier. Old registrations keep their existing names; only new registrations get the improved format.

Spun out from #1683. The core re-registration behavior described there is working as designed (vault persistence is required), but an identifiable client name is independently useful.

02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED+ 1 MOREASSIGNED+ 2 MOREREVIEW+ 4 MOREPR_MERGED+ 2 MORESESSION_SUMMARIZED

Shipped

8/18/2026, 2:00:12 AM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack728/18/2026, 1:12:56 AM

Sign in to post a ripple.