/connect/<connector> — redesign

The web connect screen is the surface a person lands on from a share link, a cloud workspace, or any machine without the desktop app. It still shows one account and offers no way to add a second — the same shape the desktop had before PR #8003. This proposes bringing it to the connector modal's structure, which already solves both.

Today vs proposed

Today — apps/web · /connect/linear

Linear

Connects for you only.

Connected harshith@tegon.ai · Superset

Disconnect

One account. A second is invisible and unreachable.
No trust copy — it asks for an OAuth grant with no context.
Nothing to rename, nothing to reconnect.

Proposed — the connector modal's shape

S•••L

Linear accounts

Add another account, or disconnect one you no longer use.

WK Workharshith@tegon.ai · Superset ···

SP Side projectharshithmullapudi@gmail.com Reconnect ···

+Connect another account

Every account, each with its own menu and its own state.
Nicknames as the title, provider identity beneath.
An expired account is fixed on its row, not hidden.

First connect keeps the trust panel

Nothing connected yet

S•••L

Connect Linear

Developed by Paradev

You control the accessParadev only receives the permissions this connector asks for.

Credentials stay on the serverTokens are held by Paradev and never written into your local agent config.

Connectors carry riskConnecting lets your agents read and act in Linear on your behalf.

Continue to Linear

Why it matters more on the web

The desktop modal shows this before a first grant and skips it once anything is connected. The web screen shows it never — and the web screen is the one reached from a share link, where the person may not know what Paradev is about to be allowed to do.

The same rule applies: trust copy answers “should I grant this?”, which is decided once. After that the screen is a manage view and the copy is in the way.

What to change

Where	Change
`connect/[connector]/page.tsx:46`	`live.find((row) => row.connector === slug)` → `filter`. This single line is why a second account is invisible; it is the same first-match-wins the desktop hook had.
`ConnectorConnect.tsx:74`	The `if (connection)` branch becomes a list: one row per account with nickname, identity, and a per-row menu of Rename, Reconnect, Disconnect.
Same file, below the list	A “Connect another account” row for user-scoped connectors. Org scope permits exactly one, so it is hidden there rather than shown and refused.
New, above the list	The three trust items, rendered only when nothing is connected yet — same condition the desktop dialog uses.
Shared	The row is the same object in three places now — web, plugin page, connector dialog. Worth one component rather than a third copy of the label rule.

Open questions

Does the web screen get Rename? It needs the connectors.rename mutation, which exists. Cheap, and the nickname is what makes two accounts legible — so probably yes.
Does it share a component with desktop, or copy the shape? Desktop renders in Electron with its own design system; the web app has its own. A shared headless hook with two renderers is the honest middle, but a copy is faster and this is two screens, not twenty.
What does it do about the tool-call gap? Letting someone connect a second account from the web, when a second account still breaks every plugin tool call, is the same foot-gun as on the plugins page — decided separately, but it lands here too.

Not addressed here: the connect screen cannot show whether an account actually works, only that a row exists. A connection whose refresh failed is listed as needing reconnect, but one whose token is live and whose scopes are wrong looks identical to a healthy one.

Mockups are drawn from the shipped desktop ConnectConnectorDialog and the rebuilt ConnectedAccounts rows, so the proposal is the structure that already exists rather than a new invention. Written from this worktree, 2026-10-01.