Summary

After upgrading to v2026.3.7-beta.1, the Control UI can fail with device signature invalid even when the gateway token is valid and present.

In this state, token auth succeeds, but the UI still cannot connect unless gateway.controlUi.dangerouslyDisableDeviceAuth = true is enabled.

This suggests the problem is in the Control UI device identity / signature validation path rather than token persistence.

Environment

• OpenClaw version: v2026.3.7-beta.1
• Gateway mode: local / loopback
• Access path: http://127.0.0.1:18789/
• Auth mode: gateway.auth.mode = token
• Browser: Chrome

Symptoms observed

During and after upgrade, Control UI showed variants of:

• device signature invalid
• device identity required
• gateway token mismatch
• too many failed authentication attempts

The token-persistence issue was addressed separately by PR #39615.

However, even after the token is present and stable, Control UI can still fail with:

• device signature invalid

Key observation

With the same browser, same gateway, and same token:

• dangerouslyDisableDeviceAuth = false -> Control UI can fail with device signature invalid
• dangerouslyDisableDeviceAuth = true -> Control UI connects successfully again

That makes this look like a device identity / signature compatibility or persistence problem, not just an auth-token problem.

Repro (best effort)

1. Upgrade an existing local OpenClaw install to v2026.3.7-beta.1
2. Open Control UI on http://127.0.0.1:18789/
3. Provide a valid gateway token
4. Attempt to reconnect using the existing browser profile / existing stored UI state
5. Observe device signature invalid

Temporary workaround

Set:

{
  "gateway": {
    "controlUi": {
      "dangerouslyDisableDeviceAuth": true
    }
  }
}

After enabling that flag, the same Control UI instance connects successfully again.

Expected behavior

A valid token + previously usable local browser profile should continue to connect after upgrade, without requiring dangerouslyDisableDeviceAuth=true.

Possible areas to inspect

• Control UI device identity persistence across upgrades
• Signature payload/version compatibility
• Handling of stale browser-side device identity after gateway/UI upgrades
• Interaction between token auth and device-auth validation for local loopback Control UI