Connected dashboard tells users to run ocx start while awaiting hub browser authentication #4206

Client or integration

OpenCodex dashboard

Area

Dashboard

Summary

A local connected-client dashboard awaiting hub browser pairing simultaneously tells the user to run ocx start, even though the local process is running and the client connection is established. Authentication state is presented as a stopped proxy.

This causes users to restart healthy software when the next meaningful action is authorizing the dashboard session.

Reproduction

1. Use a connected client with managementTransport: relay and a healthy hub.
2. Open http://127.0.0.1:10100/ without an established hub browser session.
3. Observe the pairing panel and the dashboard error below it.
4. Independently confirm ocx connect status --json is connected and both services are reachable.

Observed together in the Korean UI:

• sidebar action: “허브 연결 해제” (disconnect hub);
• panel: “이 대시보드를 허브에 연결” (connect this dashboard to the hub), one-time code field;
• error: “프록시에 연결할 수 없습니다. 실행 중인가요?” followed by an instruction to run ocx start.

The remote hub tab also displayed an administrator-token prompt together with generic model-load/proxy-running errors. That is supporting UX evidence; this report does not assert that both surfaces have the same underlying authentication defect.

Version

Client 2.50.0; hub 2.51.0, dev 6d3ad12e3fbfd8423f1515a467db4d3349732886.

Operating system

Windows 11 25H2 browser/client; macOS 27.0 hub.

Provider and model

Not provider-specific.

Logs or error output

CLI connection: connected
Local process: healthy
Hub authenticated usage read: HTTP 200
Browser: connect this dashboard to the hub
Browser: cannot connect to proxy; run ocx start

Screenshots and supporting files

gui/src/pages/Dashboard.tsx:29 renders the same cannot-connect/start message whenever useDashboardData exposes an error. gui/src/connect-pairing.ts:33 renders the separate authentication panel.

Acceptance criteria:

• Distinguish local process unavailable, hub unreachable, browser session required/expired, permission denied, and failed data load.
• When pairing is required, show “Local client connected; authorize this dashboard” with one primary recovery action. Do not also suggest starting or stopping the running proxy.
• Preserve and label stale data rather than presenting cached counters as fully current during authentication failure.
• Recheck state after successful authorization; errors must clear without a process restart.

Related: closed #3279 has similar generic offline copy but described an intermittent loopback-origin/session issue in 2.40.0. This report is the connected-client relay/pairing state observed in 2.50.0. #4055 concerns session lifetime; this report does not request changing authentication lifetime or weakening its checks.

Redacted configuration

{"runtimeRole":"client","client":{"managementTransport":"relay"}}

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.