connections: open a provider and manage it, the way OpenHuman already does

[oxoxDev]

What we want

OpenHuman already has the connections experience this product needs. Port it.

In OpenHuman, a connection is a thing you can open. Click a provider — Notion, GitHub — and you get its own view: whether it is connected, a connect and a disconnect action, what account it is connected as, what has moved through it, and the surrounding detail that makes the connection feel like a managed object rather than a boolean.

In OpenCompany a provider is a row with a button. There is no detail view at all: no way to see what a connection has been used for, no way to inspect it, and disconnect is not consistently offered.

Why this is not a straight copy

OpenCompany has three connection systems where OpenHuman has one, and they do not agree with each other:

• Composio — the path agents actually use. Its OAuth runs on Composio's side; there is no local callback.
• Remote MCP servers — a separate per-tenant OAuth with its own console surface.
• The native OAuth catalog — currently inert: its credential is written and read by nothing (connections: the Connect button stores a credential that no agent can ever use #396).

So the port has to decide what a "connection" means here before it can render one. A detail view that shows a native-catalog connection as healthy would be actively misleading, because nothing consumes it.

Scope

• Open a provider from the Connections page and get its own view.
• That view states: connected or not, which account, through which system, and when it was connected.
• Connect and disconnect are both available and both work, with the disconnect saying plainly what it will and will not revoke.
• Usage — what has actually gone through this connection — shown where the data supports it. Do not invent a number. If per-connection usage is not recorded today, say so on screen and file what it would take, rather than rendering a plausible-looking zero.
• The view is honest about which of the three systems backs the connection, and does not present an inert one as live.

Before building

Read OpenHuman's implementation first — this issue exists because that experience is already right, and the point is to inherit its decisions rather than re-derive them. The checkout is vendored at vendor/openhuman. Take its information architecture, its states, and its wording where they fit; diverge only where OpenCompany's three-system reality forces it, and say where and why.

Related

Sits on top of #402, which makes the Connections page show real providers and give one answer per provider — that is the list this detail view opens from.
#403 must be respected: connect and disconnect are privileged actions, and a member who cannot change a connection should not be offered a control that will fail.
#396 covers the native catalog being inert; a detail view must not paper over it.
#316 settled one operator per connected account — the detail view is where that becomes visible.

[oxoxDev]

Related — cluster:connections

A chain rather than three independent items — settle them in this order, because each constrains the next.

• connections: the Connect button stores a credential that no agent can ever use #396 — the functional core: the Connect button completes an OAuth handshake, shows connected, and no agent gains any ability. oauth_key(provider) is written and never read. An operator can do everything the page asks and get nothing.
• connections: route hosted OAuth through the platform backend instead of per-tenant provider apps #319 — decides where hosted credentials come from: route through the platform backend's existing provider apps rather than per-tenant client ids. Whatever this settles determines what connections: the Connect button stores a credential that no agent can ever use #396's fix has to read.
• connections: open a provider and manage it, the way OpenHuman already does #404 — the management surface: port OpenHuman's provider detail view, so a connection is an object you open rather than a row with a button.

#319 also carries an identity dimension and is tagged cluster:identity.

[CodeGhost21]

One thing this issue doesn't settle, and the detail view can't avoid deciding: what does a second Composio account for the same provider mean?

Surfaced while building the server half (#696). Now that the host returns connections as accounts rather than as a boolean, a real answer for a company with two Gmail connections looks like this:

{ "toolkit": "gmail", "connected": true,
  "accounts": [
    { "id": "conn-gmail-1", "status": "ACTIVE", "account": "ops@acme.test",     "createdAt": "2026-08-01T10:00:00Z" },
    { "id": "conn-gmail-2", "status": "ACTIVE", "account": "billing@acme.test", "createdAt": "2026-08-09T15:30:00Z" }
  ] }

That state is reachable today, and the two references this issue points at disagree about it:

• connections: one operator, one connected account — enforce it, and show live connection state #316 decided one operator, one connected account, and this issue says the detail view "is where that becomes visible". On the native path that decision is enforced — connect_account_mismatch in src/server/ops/connections.rs rejects a callback whose account is not the company's operator.
• OpenHuman, which this issue says to inherit from, treats several accounts per toolkit as ordinary: ComposioConnectModal renders a connectedAccounts (N) list with per-connection disconnect, marks the first as default, and offers "add another account".

The conflict is not a preference, it's structural: Composio runs its OAuth on its own side with no local callback, so OpenCompany has no interception point at which to enforce #316 there. The native enforcement has a callback to hook; the Composio path does not. So multi-account is not a feature anyone chose here — it is a state the system cannot currently prevent.

Which leaves three options, and they produce different screens:

1. Inherit OpenHuman's model — a list of accounts, per-account disconnect, "add another". Diverges from connections: one operator, one connected account — enforce it, and show live connection state #316 for Composio, and should say so on screen and in the code.
2. Treat connections: one operator, one connected account — enforce it, and show live connection state #316 as binding — render more than one account as a misconfiguration, name both, and ask the operator to disconnect one. Honest about the invariant, but the product cannot actually hold the invariant, so the view would be reporting a state it can never prevent from recurring.
3. Show only the effective account and hide the rest. Rejected on this issue's own terms — it is the "looks tidy, is not true" answer, and hidden connections stay live for agents.

I'd lean 2 — this issue explicitly frames the detail view as where #316 becomes visible, and a surfaced misconfiguration is more useful than a silently-tolerated one — but it is a product decision, not an implementation one, and it changes the view's information architecture rather than its styling. @oxoxDev, since #316 was your call: which way?

For reference, the server half is agnostic. GET …/composio/connections returns accounts[] verbatim as Composio reports it, so any of the three renders without a further backend change; option 2 needs no new data either.

(Two smaller findings from the same audit, noted so they aren't rediscovered:

• "when it was connected" is unanswerable for two of the three systems. Composio now carries createdAt. The native path stores only {token, account} — no timestamp — and journals nothing on connect, so there is no event to recover a date from; MCP has no such concept at all. The cheap honest answer is for the view to say the date is not recorded for that system, rather than adding a timestamp column to the native store.
• Usage is now filed as feat: meter MCP tool calls, so per-connection usage is a real number rather than an honest-looking zero #698, per this issue's "file what it would take". Composio usage is real today; MCP is unmetered; native is inert per connections: the Connect button stores a credential that no agent can ever use #396.)