Summary

Commit 3e2b3bd2c5 ("Fix Control UI operator.read scope handling", #53110) regressed the fix from 9c142993b ("fix: preserve operator scopes for shared auth connections").

Backend operator clients that authenticate with a valid gateway token but without device identity (e.g. the AlphaClaw chat bridge using gateway-client / backend mode) have their self-declared scopes unconditionally cleared during the WebSocket handshake. This causes all scoped method calls (e.g. chat.history requiring operator.read) to fail with missing scope: operator.read.

Root Cause

clearUnboundScopes lost its !sharedAuthOk guard when #53110 refactored the call site:

// clearUnboundScopes — no longer checks sharedAuthOk
const clearUnboundScopes = () => {
    if (scopes.length > 0) {
        scopes = [];
        connectParams.scopes = scopes;
    }
};

The call site condition inverts the intent — it clears scopes for authMethod === "token" instead of preserving them:

if (
    !device &&
    (decision.kind !== "allow" ||
        (!controlUiAuthPolicy.allowBypass &&
            !preserveInsecureLocalControlUiScopes &&
            (authMethod === "token" || authMethod === "password" || trustedProxyAuthOk)))
) {
    clearUnboundScopes();
}

The inline comment ("Device-less clients only keep self-declared scopes on the explicit allow path, including trusted token-authenticated backend operators") confirms the intent is to preserve scopes for token auth, but the code does the opposite.

Reproduction

1. Start a gateway with auth.mode: "token".
2. Connect a WebSocket client as gateway-client / backend / operator with a valid token, requested scopes ["operator.admin"], and no device identity.
3. Call chat.history — fails with missing scope: operator.read.

Fix

Restore the !sharedAuthOk guard inside clearUnboundScopes itself (belt-and-suspenders), so token-authenticated connections never have their scopes wiped regardless of call-site logic.

Affected Versions

Introduced in the commit tree leading to 2026.3.24. The original fix (9c142993b) was present since v2026.2.26.