Skip to content

No way to rename an authorized client or pairing link after it's created #13054

Closed

Description

@jaypopat

What happened

i cant even rename the tokens i issued

The user created pairing links/authorized client sessions with labels (e.g. via the "Client label" field in the Create pairing link dialog, Settings → Connections → Authorized clients), but found no way to rename them afterward.

Diagnosis

Traced the full stack at commit 719a76ca (tag v0.0.42) — this isn't a hidden or broken button, the capability doesn't exist anywhere in the chain:

  • UI (apps/web/src/components/settings/ConnectionsSettings.tsx): ConnectedClientListRow (the row for each already-paired client, ~line 968) renders only a Revoke button for a non-current session. A label can only be entered once, in the AuthorizedClientsHeaderAction dialog's "Client label (optional)" field, at creation time (createServerPairingCredential({ label, scopes })).
  • Server service (apps/server/src/auth/EnvironmentAuth.ts, EnvironmentAuth["Service"] interface, ~line 440): the full method list is createPairingLink, issuePairingCredential, issueStartupPairingCredential, listPairingLinks, revokePairingLink, issueSession, listSessions, revokeSession, revokeOtherSessionsExcept, listClientSessions, revokeClientSession, revokeOtherClientSessions — no update/rename method.
  • Persistence (apps/server/src/persistence/AuthSessions.ts): client_label is written once in the INSERT (createSessionRow, ~line 220-235). Every UPDATE auth_sessions statement in the file (setLastConnectedAtRow, setClientConnectionRow, revokeSessionRows, revokeOtherSessionRows, the replacement-session revoke) touches revoked_at, last_connected_at, client_surface, or client_app_version — none touch client_label. Same pattern in AuthPairingLinks.ts.

So a client label (and a pairing link's label) is write-once by design/omission: set at creation, never editable, with no path to change it short of revoking and re-creating the credential.

Checked upstream: closest related issue is #5623 (closed) about environment display names defaulting to hostname — a different feature (environments, not authorized clients/pairing links). No existing issue covers renaming an authorized client or pairing link. Not a duplicate.

Steps to reproduce

  1. Settings → Connections → Authorized clients → Create link, giving it a label.
  2. Once the client has paired and appears in the Authorized clients list, look for a way to edit its label.
  3. Observe: only "Revoke" is available. No edit/rename action exists in the UI, and no backend method supports it either.

Version

0.0.42

Environment

Linux x64, Node v26.8.2

Related issues

None found to be a duplicate; #5623 is adjacent (environment naming) but distinct.

Fix applied or workaround

None. Revoking and re-issuing a new pairing link/session with the desired label is the only option, which also changes the credential.

Filed by

claude (sonnet-5) via t3 triage

Activity

  1. juliusmarminge commented on Sep 22, 2026

    @juliusmarminge
    Member

    Triage confirmation

    Confirmed on both the reported release and current main. This is a missing capability, not a broken control: client/pairing labels are write-once, and there is still no rename path in UI, auth service, or persistence.

    Verified against

    • Reported: v0.0.42 / 719a76ca
    • Current main: aff9318bf (newer than v0.0.42; nightlies through 0.0.43-nightly.20260922.* do not add rename)

    Source check (still true on main)

    • UI: ConnectedClientListRow and PairingLinkListRow in apps/web/src/components/settings/ConnectionsSettings.tsx expose create-time label entry and Revoke only — no edit/rename action for an existing authorized client or pairing link.
    • Auth service: EnvironmentAuth exposes create/list/revoke for pairing links and client sessions; there is no update/rename method for labels.
    • Persistence: auth_sessions.client_label is set on INSERT in AuthSessions.ts; session UPDATEs only touch connection/revoke fields. AuthPairingLinks.ts likewise only updates consumed_at / revoked_at, never label.

    Not a duplicate

    Classification
    Enhancement / UX gap. Workaround remains revoke + re-issue with a new label (rotates the credential).

    Suggested fix shape (for whoever picks this up)

    1. Persistence + EnvironmentAuth APIs to update pairing-link label and session client_label.
    2. Connections settings UI affordance to rename both list row types.
    3. Wire through contracts/RPC; cover with persistence + UI tests.
  2. locked and limited conversation to collaborators on Oct 11, 2026
  3. converted this issue into a discussion #18002 on Oct 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementRequested improvement or new capability.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions