Windows-MCP 0.8.8 USER_CONTROL blocks agent: disable gate or workaround?
After upgrading Windows-MCP to v0.8.8 (run via uvx on Windows 11 with Claude Desktop 2.31226.1), tool calls are refused with USER_CONTROL. The new control gate requires 10 seconds of idle time, and any physical mouse or keyboard activity resets the timer, so background jobs get blocked while I keep working on the same PC. Is there a way to disable or configure this gate?
Originally asked on GitHub: https://github.com/CursorTouch/Windows-MCP/issues/457
3 answers
The issue is closed as completed. A commenter confirms the opt-out (PR #458) was merged, but the thread does not name the flag, environment variable, or release version that contains it. In v0.8.8 itself there is no documented way to disable the gate: PR #445 introduced the USER_CONTROL refusal, which requires 10 seconds of system idle time and resets whenever the physical mouse or keyboard is touched, so background jobs get blocked while you keep working on the same PC.
The workaround given in the issue is to pin to
windows-mcp==0.8.7, which had the pre-gate behavior. The reporter also asks for a configurable idle timeout and for exempting non-UI tools (PowerShell, FileSystem, Registry, Process, Clipboard) from the gate; a commenter repeats that request, suggesting the gate remain only on input/screen tools (Click, Type, Move, Scroll, Shortcut, App), but the thread does not confirm that behavior shipped. General advice: check the project changelog for the first release after 0.8.8 to find the exact opt-out name. The gate exists to avoid mixed input, so disabling it means the agent can act while you are actively using the mouse or keyboard.Did this work for you?What a GitHub user tried on GitHub (Outcome unclear)
Issue body: pin to windows-mcp==0.8.7 to keep the pre-0.8.8 behavior, which the reporter says worked fine. Proposed as a workaround, but the thread does not state it was actually tested.
Source: https://github.com/CursorTouch/Windows-MCP/issues/457 (opens external site)
Did this work for you?What @ms400msaa-ops tried on GitHub (Outcome unclear)
A commenter confirms PR #458 (the opt-out) was merged and says it will help, but gives no flag name, version, or test result. They also request that the gate stay on UI-driving tools only so background tools can run without waiting for idle.
Source: https://github.com/CursorTouch/Windows-MCP/issues/457#issuecomment-6168382618 (opens external site)
Did this work for you?
Related questions
- Windows-MCP State-Tool fails with 'Taskbar' error – correct install method?
- Windows-MCP State-Tool fails with 'Taskbar' error on German Windows 11 — how to fix?
- How to fix Windows-MCP State-Tool vision error 'Tool result is too large. Maximum size is 1MB' on 2560x1440?
- Anthropic MCP directory: required tool annotations and manifest version?
- Windows-MCP times out MCP initialize handshake with Claude Desktop (-32001) on cold start