DIAGNOSTIC ORDER
Test one input cause at a time.
Quit the Demo completely. Do not use A, D, or S as a permanent workaround: players report that those keys can interrupt the movement only while held.
Disconnect non-standard HID devices before relaunching: gaming keypads, extra controllers, macro pads, CAD mice, and similar peripherals. One current player solved the bug by removing a Razer Tartarus Pro.
Start a new run with only a standard keyboard and mouse connected. Release W after the opening prompt and check whether the character remains still.
If movement is now normal, reconnect one device at a time and retest. That isolates the device or driver injecting the forward input instead of forcing a full reinstall.
If the bug remains with only keyboard and mouse, open their vendor software and switch to an unmodified default profile. A Swiftpoint user fixed the issue by removing custom button bindings; another player reported that merely closing CAD mouse software did not help.
Only after the input test should you verify game files or reinstall. A player reports that reinstalling alone did not clear the behavior, so it is a later diagnostic step rather than the first fix.
If none of these checks work, report the keyboard, mouse, every attached HID device, vendor software, display mode, and Demo build in the pinned bug thread. The developer says the issue was not reproducible in their original QA setup.
WHAT SUCCESS LOOKS LIKE
After releasing W in a new run, the character stays still until you press a movement key again. Reconnecting one peripheral or restoring one custom profile makes the unwanted movement return, identifying the input conflict.
VERSION BOUNDARY
The developer confirmation and fixes here belong to the current pre-launch Demo discussion. The Razer Tartarus and Swiftpoint solutions are independent player reproductions, not an official universal fix; another HID device or the September 10 Early Access input stack may behave differently.