Surface OneCLI app connections in Humr UI

[matoushavlena]

Problem Statement

Humr's Connections page treats OneCLI OAuth apps (Google Drive, Gmail, GitHub, Slack, etc.) as a black box — a single link card that sends users to the OneCLI dashboard. Users cannot see which apps are connected, their status, or which agents have access to which apps without leaving Humr. Setting up an agent with an OAuth app requires context-switching to OneCLI, finding the right agent, and mapping the connection there — with no feedback in Humr that it worked.

Solution

Surface OneCLI app connections as first-class objects in Humr's UI, progressively adding capability across three phases:

• Phase 0 (Read-only): Show individual app connection cards in the Connections view and display them as a separate "Apps" group in the Edit Agent Secrets dialog. Users can see what's connected and which agents have access, without leaving Humr.
• Phase 1 (Assign/Unassign): Allow users to assign and unassign existing OneCLI app connections to agents directly from Humr, eliminating the need to visit OneCLI for this workflow.
• Phase 2 (Full Management): Initiate OAuth flows, disconnect/revoke apps, and manage app lifecycle entirely from Humr.

User Stories

• As a user, I want to see which OAuth apps are connected to my account so that I know what's available to my agents without visiting OneCLI. (feat(ui): surface OneCLI app connections in Connections view #181)
• As a user, I want to see app connection status (connected/expired) and identity (email/username) so that I can diagnose issues at a glance. (feat(ui): surface OneCLI app connections in Connections view #181)
• As a user, I want to see which apps are assigned to a specific agent (in the Edit Agent Secrets dialog) so that I understand what the agent can access. (feat(ui): assign/unassign OneCLI app connections from agent dialog #184)
• As a user, I want to assign an existing OneCLI app connection to an agent from Humr so that I don't have to context-switch to OneCLI for routine setup. (feat(ui): assign/unassign OneCLI app connections from agent dialog #184)
• As a user, I want to unassign an app connection from an agent from Humr so that I can revoke access without visiting OneCLI. (feat(ui): assign/unassign OneCLI app connections from agent dialog #184)
• As a user, I want to connect a new OAuth app (e.g. Google Drive) directly from Humr so that the entire setup flow stays in one place.
• As a user, I want to disconnect/revoke an OAuth app from Humr so that I can manage the full lifecycle without OneCLI.

Implementation Decisions

OneCLI API dependency

OneCLI already has:

• GET /api/connections — lists all user app connections (id, provider, label, status, scopes, metadata, connectedAt)
• GET /api/apps — lists available apps with config and connection status
• AgentAppConnection join table and service functions (getAgentAppConnections, updateAgentAppConnections) in agent-service.ts
• GET /api/agents/{agentId}/connections and PUT /api/agents/{agentId}/connections — per-agent assignment read/write (added upstream in onecli#7, shipped in v0.0.12).

Phase boundaries

• Phase 0 requires only GET /api/connections (already exists) and read access to per-agent assignments (shipped in OneCLI v0.0.12).
• Phase 1 additionally requires write access to per-agent assignments (the PUT side, also in v0.0.12).
• Phase 2 requires proxying OneCLI's OAuth flows (/api/apps/{provider}/authorize, /api/apps/{provider}/callback, /api/apps/{provider}/connection DELETE) through the Humr API server.

UI treatment

• Connections view: replace the single "Apps" link card with individual cards per connection, showing provider icon/name, account label, status badge, and connected date.
• Edit Agent Secrets dialog: add a fourth "Apps" group (alongside Provider, MCP Servers, Secrets) showing app connections with checkboxes for selective assignment.
• Retain a "Manage in OneCLI" link as a fallback for Phase 0/1 (for actions not yet supported in Humr), remove it in Phase 2.

Authentication

Reuse the existing RFC 8693 token exchange pattern (Keycloak JWT → OneCLI-scoped token) already implemented in packages/api-server/src/onecli.ts. The new connections endpoints use the same auth mechanism as the existing secrets endpoints.

[matoushavlena]

Closing as this is mostly implemented and the remaining stories lead towards replacing oneCLI with a custom build solution