Windows-MCP: control gate stuck permanently in 'user' state blocks every tool — fix?

3 answers

• Best answerAgentArmorHQ teamTeam4d ago

  Status: fixed in PR #460, confirmed by the reporter in the original environment; the thread does not state whether it has shipped in a released version.

  Root cause: in desktop/control.py, _tick_locked() only releases the gate to ready when _pressed/_mouse_down are empty and the 10-second idle window has elapsed. A missed key-up leaves a stale entry that never times out, so the gate stays latched in state: "user" with wait_seconds: 0 and a frozen generation, and every tool call — including non-GUI tools like Clipboard, WaitFor, and DisplayInventory — is rejected with {"code":"USER_CONTROL",...}. On the affected machine, the elevated Alt+Tab switcher AltTaber 0.5.0.0 swallowed the key-up of an Alt+Tab press; any low-level hook earlier in the chain that returns non-zero can do the same. ControlConfig exposes no flag to disable the gate.

  PR #460 changes the release logic: after the configured idle wait, residual key/button holds are cleared only after five consecutive OS queries, at least 100 ms apart, all report the inputs released; a reported held input or new physical input resets the confirmation. The reporter ran the PR head as a standalone stdio server and the previously latching sequence self-cleared about 11 seconds after the last input, with no restart and without re-pressing the stuck key.

  Workaround on stock 0.8.8: press and release the stuck key again — the reporter cleared the latch by pressing/releasing Alt+Tab again, and in a later test Tab alone cleared it, while ordinary letters, mouse clicks, and Alt alone did not. Restarting the server also recovers.

  Per the README, the takeover mechanism is "best-effort, not a security boundary" — do not rely on it as a security control.

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam4d ago

  What a GitHub user tried on GitHub (Worked)

  While the gate was latched (state "user", generation frozen at 38), the reporter pressed and released Alt+Tab again: state returned to "ready", generation advanced to 39, and the process was not restarted, proving a stale key entry caused the latch.

  Source: https://github.com/CursorTouch/Windows-MCP/issues/456 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam4d ago

  What @HenryYves tried on GitHub (Worked)

  The reporter ran PR #460 head as a standalone stdio server in the original environment (same machine, same AltTaber 0.5.0.0 switcher, same keystrokes): the sequence that latched stock 0.8.8 self-cleared about 11 seconds after the last input, with no restart and no key re-press.

  Source: https://github.com/CursorTouch/Windows-MCP/issues/456#issuecomment-6144550872 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport