01Identify where the failure occurs
If no Connect Cube action is available, the issue is browser capability or permission. If the device chooser opens but no GAN entry appears, the cube is asleep, out of range, low on power or already connected elsewhere.
If you can select the cube but SupaKewber reports a service or GATT error, discovery began but the Bluetooth session did not initialize. A connected label with no live turns is a fourth state: pairing succeeded but move notifications are not flowing.
02Why the clean retry order matters
Repeatedly clicking Connect while CubeStation or another tab holds the cube creates more overlapping failures. One clean tab, one awake cube and one chooser action give the browser the best chance to complete service discovery.
SupaKewber retries common first-attempt GATT failures, particularly on Windows. Wait for that process instead of immediately creating a second chooser request.
03Verify the Bluetooth layer and cube state separately
Use several live turns to confirm transport reliability, then compare physical and virtual solved states. Reliable packets with the wrong starting state require synchronization; missing packets require a connection reset.
A generated scramble should only be trusted after the viewer follows turns accurately. Otherwise stage detection and automatic solved-state timing may be based on a different pattern from the physical cube.
04Escalate only after the basic checks
Replace or recharge the battery, reboot the computer or phone and test a second supported Chromium browser. This separates a cube-specific failure from a damaged browser profile or blocked site permission.
Older Linux setups or legacy Windows versions may need experimental Web Bluetooth support, but flags should not be the first recommendation on a normally supported platform.