Windows: system-wide repeating/stuck key (space) after chrome-devtools-mcp usage, persists after keyboard disconnect, requires OS restart

[Fakiros]

Summary

After periods of using chrome-devtools-mcp (connected as an MCP server to Claude Code, running headful on a Windows client machine), the Windows machine occasionally enters a state where a keystroke (space bar) starts auto-repeating system-wide — in every application that has focus, not just the automated browser tab. Clicking into a different window/app does not stop it; the repeated space keeps appearing wherever focus goes next.

Critically: physically disconnecting the keyboard does not stop the repeat, which suggests the "held key" state is being tracked at the OS input level as a synthetic/injected event, not coming from real hardware. The only remedy found so far is a full OS restart. This has now recurred 3 separate times over a period of working with the MCP server.

Environment

• chrome-devtools-mcp, connected over HTTP transport (http://<windows-host>:8932/mcp) from a remote Claude Code session (Linux host) via SSH/Remote-SSH
• Windows client machine, real (headful) Chrome window driven by the server
• @playwright/mcp (microsoft/playwright-mcp) is also configured on the same Windows machine on a separate port (8931), so I cannot 100% rule out an interaction between the two, but chrome-devtools-mcp is the one with active tool usage in this session's history around the time of at least one occurrence.

Hypothesis (unconfirmed)

If a keyboard tool (e.g. a key-press action) dispatches a keyDown for Space but, due to an exception, timeout, or lost connection, the matching keyUp is never sent, the OS itself may continue to treat the key as physically held and apply its own key-repeat — which would explain why the repeat:

• targets whatever window currently has OS focus (not just the browser), and
• continues even with the physical keyboard unplugged.

This would align with the input-reliability issues already reported in #2199 (injected input silently stops reaching a tab) and #2290 (server can steal foreground window focus) — both suggest the input/focus state tracking between the MCP server and the OS/browser isn't always consistent.

Reproduction

Not yet reliably reproducible on demand — it happens "after some time" / under conditions I haven't fully isolated. I don't have a minimal repro script yet. Filing this now because of severity (requires a full OS restart each time) in case others have hit the same thing or maintainers have insight into whether any code path sends a keyDown without a guaranteed matching keyUp (e.g., on an error/timeout branch).

Impact

High — the affected machine becomes effectively unusable (phantom input in every focused window) until a full restart.

Happy to gather more diagnostic info (e.g. instrumenting for keyDown/keyUp pairing) if that would help narrow this down.

[Liohtml]

I went looking for the unpaired-keyDown path you asked about and found one concrete instance in the server — opened #2347 for it.

Confirmed: a browser-level unpaired-keyDown in press_key

press_key presses modifiers down, presses the main key, then releases the modifiers, in three sequential steps with no try/finally (src/tools/input.ts). If keyboard.press(key) rejects (CDP hiccup / target crash / dropped connection), the release loop never runs and the modifier keys are left logically held down. I reproduced it with a real-browser test that injects a press() failure mid-sequence: on main the page sees dControl, dShift and no keyups; with the fix it sees the matching uShift, uControl. PR #2347 wraps the sequence in try/finally.

But I don't think this fully explains your symptom — and I want to be honest about why

Your report is a bare Space that repeats system-wide and keeps repeating after you physically unplug the keyboard. That points at the OS input layer, and CDP-injected input doesn't route through it: Input.dispatchKeyEvent is delivered into Chromium's renderer input pipeline, not through the Windows OS input queue (SendInput/SetKeyboardState). So a leaked keyDown from this server should manifest as a key stuck inside the driven page/tab, not as phantom Space in Notepad that survives a keyboard disconnect. The fix in #2347 closes a real defect, but I'd be overselling it to claim it resolves the OS-wide behavior you saw.

Two things make me suspect the OS-level vector is elsewhere:

• You're running @playwright/mcp on the same machine on a separate port. Worth checking whether the occurrences correlate with its usage rather than this server's.
• The session is driven remotely (Remote-SSH into a headful Windows box). Remote-session stuck-key states (a synthetic key whose keyUp is lost at the RDP/remote-input layer) are a known Windows phenomenon and match "system-wide + survives unplug + needs restart" better than a renderer-scoped CDP key does.

One datapoint would disambiguate

Next time it happens, before rebooting: does the phantom Space stop if you close only the Chrome window this server was driving?

• Stops → it was renderer/CDP-scoped (and fix: release held modifiers when press_key key event fails #2347 or a sibling path is the likely culprit).
• Keeps going → it's OS-level, and the fix won't be the whole story.

Non-reboot workaround

A stuck key at the OS level can usually be cleared by injecting keyUps via SendInput instead of restarting. This PowerShell releases Space + the common modifiers (releasing a key that isn't held is a harmless no-op); I confirmed it runs on Windows 11 (SendInput released 6 key-up event(s).):

Add-Type @"
using System;
using System.Runtime.InteropServices;
public static class Kb {
  [StructLayout(LayoutKind.Sequential)]
  public struct INPUT { public uint type; public KEYBDINPUT ki; public int pad; }
  [StructLayout(LayoutKind.Sequential)]
  public struct KEYBDINPUT { public ushort wVk; public ushort wScan; public uint dwFlags; public uint time; public IntPtr dwExtraInfo; }
  [DllImport("user32.dll", SetLastError=true)]
  public static extern uint SendInput(uint nInputs, INPUT[] pInputs, int cbSize);
}
"@
$KEYUP = 0x0002
foreach ($vk in 0x20,0x11,0x10,0x12,0x5B,0x5C) {   # Space, Ctrl, Shift, Alt, LWin, RWin
  $x = New-Object 'Kb+INPUT'; $x.type = 1; $x.ki.wVk = [uint16]$vk; $x.ki.dwFlags = $KEYUP
  [Kb]::SendInput(1, [Kb+INPUT[]]@($x), [Runtime.InteropServices.Marshal]::SizeOf([type]'Kb+INPUT')) | Out-Null
}
Write-Output "Released stuck keys."

Happy to dig further into the OS-level path if the close-the-tab test above points that way.