[BUG] Cowork VM virtual mouse input leaks into host OS, overriding physical mouse during active tasks (Windows 11 Pro)

Resolved 💬 2 comments Opened Mar 11, 2026 by Gene86-beep Closed Mar 14, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

I'm experiencing an issue on the latest Claude Desktop for Windows (v1.1.6041 (62e193), fresh install March 2026) where Cowork's virtual mouse input appears to leak from the VM into the host OS, interfering with physical mouse control.

Symptoms:

  • While Cowork is actively running a task, my physical mouse clicks stop registering or are ignored
  • Phantom clicks occur that I did not initiate — it's as if something else has taken control of the click command
  • The issue affects multiple physical mice, so it's not a hardware problem
  • Pressing Ctrl+Alt+Delete and selecting Task Manager from the Secure Attention Sequence screen immediately restores normal mouse functionality, suggesting Windows is reasserting physical input priority over the VM's virtual input

Additional findings from troubleshooting:

  • Launching Claude with --disable-gpu (via start shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude --disable-gpu) reduced the frequency of the issue but did not eliminate it
  • After uninstalling Claude Desktop, Hyper-V services (vmcompute, CoworkVMService, etc.) persisted and the mouse issues continued until the hypervisor was manually disabled
  • The cowork-svc process runs in the background even when no Cowork task is active

This appears to be an input isolation issue where the Cowork agent's virtual mouse/keyboard control inside the VM is not properly sandboxed from the host OS input stream. When Claude is executing mouse clicks and keyboard input through the Computer Use API during a Cowork task, those virtual inputs seem to conflict with or override physical hardware input.

Expected behavior: The VM's virtual input should be completely isolated from the host. Physical mouse and keyboard input should always take priority and never be interrupted by the Cowork agent's actions.

Workaround: Pressing Ctrl+Alt+Delete forces Windows to reassert physical input control and temporarily resolves the issue until it recurs.

System: Windows 11 Pro, Claude Desktop (v1.1.6041 (62e193)

What Should Happen?

The Cowork VM's virtual mouse and keyboard input (used by the Computer Use API within the VM) should be fully isolated from the host OS. Physical mouse and keyboard input should always take priority and never be interrupted or overridden by the Cowork agent's actions inside the VM.

Error Messages/Logs

Steps to Reproduce

  1. Install Claude Desktop for Windows (v1.1.6041 or later) from claude.com/download on a Windows 11 Pro system with Hyper-V enabled
  2. Launch Claude Desktop (either normally or via start shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude --disable-gpu)
  3. Switch to Cowork mode and select a working folder
  4. Start a multi-step Cowork task that involves file reading, analysis, or document creation (tasks that take several minutes to complete work best for reproducing the issue)
  5. While Cowork is actively processing the task, attempt to use your physical mouse to click on other windows, taskbar items, or desktop icons
  6. Observe: physical mouse clicks stop registering or are ignored. Phantom clicks may occur at locations you did not click.
  7. Press Ctrl+Alt+Delete and select Task Manager (or any option) from the Secure Attention Sequence screen
  8. Observe: physical mouse control is immediately restored after returning from the SAS screen
  9. The issue will recur intermittently as Cowork continues processing

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Desktop (v1.1.6041 (62e193)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗