Potential Scope Bypass: Web UI client permissions being stripped by Gateway

[A561988]

While auditing the WebSocket communication between the web UI and the gateway, I noticed that the gateway is stripping all scopes when the client connects as bitterbot-desktop.

This results in an infinite loading spinner on chat because the client doesn't have the necessary operator.read permissions to initiate a session. It seems the localhost bypass is currently hardcoded only for bitterbot-control-ui.

Proposed Fix: The logic at message-handler.ts:430-434 should probably be updated to grant standard scopes to the desktop ID when originating from a local loopback.

[VGIL77]

Confirmed — this is a real bug. Looked at the current code at src/gateway/server/ws-connection/message-handler.ts:345:

const isControlUi = connectParams.client.id === GATEWAY_CLIENT_IDS.CONTROL_UI;
...
const localControlUiBypass = isControlUi && isLocalClient;
const allowControlUiBypass =
  allowInsecureControlUi || disableControlUiDeviceAuth || localControlUiBypass;

And at line 434 scopes get stripped when allowControlUiBypass is false. This means any non-control-UI client connecting from localhost (including bitterbot-desktop, bitterbot-macos, bitterbot-ios, bitterbot-android, and webchat-ui) loses its scopes and gets the infinite spinner.

Your proposed fix is right — the bypass should apply to any trusted local-loopback client, not just bitterbot-control-ui. The full set of client IDs is defined in src/gateway/protocol/client-info.ts. Likely the cleanest fix is introducing an isTrustedLocalClient helper that covers the UI/webchat/desktop/native family.

Leaving open — this needs real review of the security implications (which clients should be trusted on loopback?) before we patch it. PR welcome if you want to take a shot.