Pairing appears browser/device-scoped instead of backend/user-scoped for Mission Control sessions

[itsmiso-ai]

Summary

Mission Control pairing/trust appears to be scoped to the connecting browser/client/device rather than to the authenticated Mission Control backend user/session. This creates surprising behavior for self-hosted operator setups.

What I observed

In a self-hosted deployment:

• Laptop A:
  • log into Mission Control
  • pair it
  • it works
• Laptop B:
  • log into Mission Control with the same account
  • Mission Control still says it needs pairing

This makes it look like pairing is not owned by the backend-authenticated MC user, but instead by the browser/device/client context.

Why this feels wrong

For operator dashboards, this is surprising UX/architecture.

The expectation (at least in my setup) is:

• backend trust/pairing should be owned server-side
• authenticated users of Mission Control should inherit that backend trust
• the frontend should not require re-pairing per laptop/browser just to access the same backend

Current behavior makes the trust model feel closer to per-device auth than per-user/backend auth.

What in the code seems to support this

From reading upstream:

• browser websocket connection uses NEXT_PUBLIC_GATEWAY_CLIENT_ID / gateway client identity
• gateway runtime logic intentionally adds allowed origin but explicitly preserves device auth
• websocket UX/messages talk about origin/client identity/device-auth style failures

That all suggests the current model is intentionally client/device scoped.

Questions

1. Is this behavior intended?
2. If yes, is there a supported "backend-owned trust" mode for self-hosted Mission Control dashboards?
3. If no, should pairing state be lifted from browser/device scope to authenticated backend/user scope?

Suggested improvement

Please consider a mode where:

• Mission Control backend establishes and owns gateway trust once
• authenticated MC users do not have to re-pair per browser/laptop
• per-device auth can remain optional/hardened mode, but not the only model

Why this matters

For single-operator and small-team self-hosted deployments, requiring separate pairing across laptops/browsers feels unnecessarily coupled to the frontend and differs from other backend-owned admin/control UIs.