Confirmed, and I think I found the mechanism. Input tracks held keys in a set that only clears on the browser losing focus, and Ctrl+Alt+Shift together is a common OS-level shortcut on Windows (input-language switching) that can consume one modifier's key-up without the browser ever seeing it or losing focus — leaving that key stuck 'held' until something else resets it, which matches 'stuck until relog' exactly. Not fixed yet, queuing it. If you get a chance, your Windows display-language / keyboard-layout setup would help confirm the theory.

Fixed and shipped — and thank you for the exact repro, that is what made it findable.

Held keys are tracked as a set, added on keydown and removed on keyup. A keyup that never arrives latches that key for the rest of the session, and ATTACK is bound to Ctrl by default — so a latched Ctrl reads as the attack key held down until you relog. Chords involving Ctrl/Shift/Alt are exactly the ones Windows and the browser intercept for themselves (Ctrl+Shift and Alt+Shift are the keyboard-layout switch, among others), and an interception can swallow the keyup without ever blurring the window, which is why the existing focus-loss handler did not catch it.

The fix is that every keyboard AND mouse event carries the true, current state of the four modifiers. Any later key press, key release or mouse click now reconciles them, so a modifier the event says is up gets dropped. The latch heals itself within one keystroke or one click instead of surviving to a relog. A tab that gets hidden without a window blur also clears now.

The real client gets this for free by polling the key state directly; the browser only offers it on an event, so we take it on every event we see.

LIVE on the published build. Try the chord again and then click once — if anything still sticks, reopen this and say which key.