Onboarding updates

[khaliqgant]

Summary

Large-scale refactor and feature update that restructures the dashboard into a clean, modular architecture while adding new onboarding and session management capabilities.

Architecture Refactors

• Dashboard as pure UI kit: Removed all direct cloud API dependencies (billing, sessions, workspace status), making the dashboard a standalone UI that receives configuration via an adapter pattern (DashboardConfigProvider)

  • Deleted: CloudSessionProvider, BillingResult, SessionExpiredModal, WorkspaceStatusIndicator, useSession, useWorkspaceMembers, useWorkspaceStatus
  • Net: ~12,600 lines removed, ~2,500 lines added

• Split App.tsx into focused providers: Extracted the 3,500-line App.tsx into four dedicated context providers:

  • SettingsProvider — theme, display, notification preferences
  • CloudWorkspaceProvider — workspace list/selection, cloud user state
  • AgentProvider — agent merging, spawn/release, fleet, decisions
  • MessageProvider — channels, threads, DM, send ops, presence

• Server route extraction: Broke monolithic server.ts into modular route files under routes/ (agents, channels, data, health, reactions, broker-proxy) with a proxy route table

• Relaycast provider migration: Refactored relaycast-provider.ts from 832 → 366 lines by adopting SDK-only transport, removing custom envelope parsing and manual cache invalidation

• Extract business logic to proxy pass-throughs: Metrics, needs-attention, health, and spawned-agents endpoints now proxy to broker/cloud instead of containing business logic

New Features

• Hybrid WebSocket mode: Dashboard connects to broker's /ws endpoint for real-time event streaming instead of polling Relaycast REST API every 3 seconds. Falls back to snapshot polling if broker WS is unavailable. Includes exponential backoff reconnect.

• Resume Previous Session toggle: Added continueFrom support to SpawnModal UI so agents can resume prior sessions

• Centralized model registry: Removed hardcoded model options from SpawnModal — now imports CLAUDE_MODEL_OPTIONS, CURSOR_MODEL_OPTIONS, etc. from agent-relay/broker SDK (source of truth: cli-registry.yaml)

• Onboarding page overhaul: Significantly expanded the onboarding page (~870 lines added, 170 removed) with improved provider setup flows

Server Infrastructure

• New utility modules: cli-auth.ts, file-search.ts, log-reader.ts, spawned-agents.ts, relay-client.ts (1,417 lines)
• WebSocket handlers split into: logs.ts, mock.ts, proxy.ts, standalone.ts
• Snapshot-before-stream ordering: initial snapshot is sent before broker event stream connects so the client always has non-null data
• Dual-send for spawned agents: messages sent via both Relaycast (observer visibility) and broker /api/send (reliable delivery)

Tests

• Added tests for: SpawnModal toggle states, proxy-server, relaycast-provider, spawned-agents, file-search, log-reader, proxy-route-table, useWebSocket, useMessages, utils
• Aligned relaycast-provider mocks with SDK readers
• Simplified metrics and needs-attention test suites to match new proxy architecture

---

84 files changed across packages/dashboard/ and packages/dashboard-server/

---

[devin-ai-integration]

Devin Review found 2 new potential issues.

View 12 additional findings in Devin Review.

[devin-ai-integration]

🔴 Relaycast API key exposed to browser clients via unauthenticated /api/relay-config endpoint

The /api/relay-config endpoint at packages/dashboard-server/src/routes/relay-config.ts:24-31 returns the Relaycast apiKey and agentToken directly to any HTTP client without authentication. The frontend RelayConfigProvider.tsx fetches this endpoint to initialize the @relaycast/react SDK in the browser.

Security Impact

The apiKey is the workspace-level Relaycast API key (rk_...), and agentToken is the agent-scoped token. Both are returned in plaintext JSON to any caller. While the dashboard is typically served on localhost, in cloud deployments or when exposed on a network, any client that can reach the dashboard server can obtain these credentials and use them to:

1. Read all messages in the Relaycast workspace
2. Send messages as the dashboard agent
3. Manage channels

The endpoint has no authentication middleware — no session check, no workspace token validation, no CSRF protection. This contrasts with the auth routes which use validateWorkspaceToken middleware.

The .claude/rules/security-auth-middleware.md rule explicitly states: "All mutation endpoints that modify credentials, tokens, or sensitive configuration must be covered by workspace-token validation middleware." While this is a GET endpoint, it exposes sensitive tokens.

Prompt for agents

In packages/dashboard-server/src/routes/relay-config.ts, add authentication or access control to the GET /api/relay-config endpoint. At minimum, when WORKSPACE_TOKEN is set (cloud deployments), require a valid session cookie or workspace token before returning the apiKey and agentToken. For local-only deployments (no WORKSPACE_TOKEN), the current behavior may be acceptable since the server is on localhost. Consider adding a check like: if (process.env.WORKSPACE_TOKEN && !isValidSession(req)) return res.status(401).json({ error: 'Unauthorized' }).

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[khaliqgant]

Also includes #54

[khaliqgant]

this was in this file but we should support interrupt

  // Agent interrupt — broker does not have this endpoint yet.
  app.post('/api/agents/by-name/:name/interrupt', (req: Request, res: Response) => {
    const name = typeof req.params.name === 'string' ? decodeURIComponent(req.params.name) : '';
    res.status(501).json({
      success: false,
      error: 'Agent interrupt is not yet supported by the broker HTTP API.',
      name,
    });
  });

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 20 additional findings in Devin Review.

[devin-ai-integration]

🟡 Optimistic messages with updated canonical IDs are never cleaned up, causing duplicates

When sendMessage succeeds and the server returns a messageId, the optimistic message's ID is updated to the canonical ID. However, the optimistic message is never removed from optimisticMessages state — it stays in the sending status forever. When the real message arrives via WebSocket with the same canonical ID, the dedup logic in mergedMessages should catch it, but the optimistic message remains with status: 'sending' while the real message has no status or status: 'read'.

Root Cause

At packages/dashboard/src/components/hooks/useMessages.ts:277-285, on successful send, the code updates the optimistic message's ID to the canonical one but never transitions its status from 'sending' to 'sent' or removes it. The comment at the old line 275-276 said "The optimistic message will be cleaned up when the real message arrives via WebSocket" — but after updating the ID to match the canonical one, the dedup logic in mergedMessages (which filters optimistic messages whose IDs match real messages) should work. However, the optimistic message retains status: 'sending' indefinitely, which means the UI shows a perpetual "sending" indicator on the message even after it was successfully delivered.

The test at useMessages.test.ts:36 confirms this: expect(result.current.messages[0]?.status).toBe('sending') — this is the expected behavior per the test, but it means the message never transitions to a delivered state.

Impact: Messages appear stuck in "sending" state in the UI until the WebSocket delivers the same message with the canonical ID, at which point dedup kicks in. If the WebSocket snapshot doesn't include the message (e.g., it was a DM not in the current view), the sending indicator persists forever.

---

Was this helpful? React with 👍 or 👎 to provide feedback.