Mouse clicks stop working system-wide while a VT mouse-mode TUI app is running — stuck capture in Windows.UI.Input.InputSite.WindowClass, only recoverable via secure desktop (Ctrl+Alt+Del)

Environment

• Windows Terminal 1.24.11321.0 (Store)
• Windows 11 25H2, build 26200.8655 (KB5094126 + KB5094135 installed 2026-06-10 — issue first appeared immediately after; the same workload had run for weeks without problems before)
• Shell/profile: PowerShell 7 tab + a tab running Claude Code CLI (a TUI app that enables VT/SGR mouse tracking, mode 1006)
• Hardware: laptop, external USB mouse and built-in precision touchpad (both affected identically — rules out the pointing device)

Summary

While the Claude Code tab is active and busy, mouse clicks intermittently stop working across the entire desktop, not just inside Terminal:

• Pointer movement is normal.
• Left and right clicks anywhere (other apps, taskbar, desktop) do nothing, except that the currently active window is deactivated by the click (focus is lost, nothing is activated).
• Keyboard input keeps working (Alt+Tab etc.).
• Clicks sometimes still work in elevated windows (e.g. Task Manager), consistent with UIPI protecting high-IL windows from a medium-IL process interfering with input.
• The only reliable recovery is switching to the secure desktop (Ctrl+Alt+Del) and pressing Cancel. After that, everything works again until the next occurrence.

Diagnostics performed

I traced the failure with a SetWinEventHook logger covering EVENT_SYSTEM_FOREGROUND, EVENT_SYSTEM_CAPTURESTART/END and menu events, plus a 100 ms poll of GetForegroundWindow() logging NULL transitions.

Key excerpt (annotated):

; normal, healthy capture pairs are ~100 ms (click down/up):
[16:41:32.700] CAPTURE+  PID 8268  WindowsTerminal  class:Windows.UI.Input.InputSite.WindowClass ''
[16:41:32.788] CAPTURE-  PID 8268  WindowsTerminal  class:Windows.UI.Input.InputSite.WindowClass ''

; failure begins: capture taken by the InputSite window and never released
[16:43:17.941] CAPTURE+  PID 8268  WindowsTerminal  class:Windows.UI.Input.InputSite.WindowClass ''

; 25 seconds later the user presses Alt+Tab; the capture is released by the
; foreground change, but clicks REMAIN dead system-wide afterwards:
[16:43:42.893] FG        PID 15128 explorer         class:ForegroundStaging ''
[16:43:42.896] CAPTURE-  PID 8268  WindowsTerminal  class:Windows.UI.Input.InputSite.WindowClass ''
[16:43:42.909] FG        PID 15128 explorer         class:XamlExplorerHostIslandWindow 'Task Switching'
[16:43:43.914] FG        PID 8268  WindowsTerminal  class:CASCADIA_HOSTING_WINDOW_CLASS 'PowerShell 7 (x64)'

; between 16:43:43 and 16:43:53 the user clicks on several windows:
; NO foreground events are generated at all - clicks never reach activation.

; user invokes Ctrl+Alt+Del (secure desktop appears as NULL foreground
; from the default desktop) and presses Cancel:
[16:43:53.850] *** FOREGROUND = NULL ***
[16:44:04.041] *** FOREGROUND BACK after 10.2s *** PID 8268 WindowsTerminal 'PowerShell 7 (x64)'

; after returning from the secure desktop, capture pairs are healthy again:
[16:44:14.243] CAPTURE+  PID 8268  WindowsTerminal  class:Windows.UI.Input.InputSite.WindowClass ''
[16:44:14.380] CAPTURE-  PID 8268  WindowsTerminal  class:Windows.UI.Input.InputSite.WindowClass ''

Additional observations from earlier traces during failure periods:

• GetGUIThreadInfo(0) reports no capture, no menu mode, no move/size loop on the foreground thread (the capture is held on a different thread).
• GetForegroundWindow() is frequently NULL during the failure; clicks briefly activate a window, after which foreground drops again.
• No hung windows (IsHungAppWindow negative for all top-level windows), no stuck modifier keys (GetAsyncKeyState clean), no transparent overlay (WindowFromPoint returns the expected window).
• Injecting synthetic button-up events for all buttons via mouse_event does not recover the state.
• Clicking inside the Terminal window does not recover the state.
• Only the secure desktop transition recovers it.

Interpretation

The stuck CAPTURE+ on Windows.UI.Input.InputSite.WindowClass and the fact that releasing the capture does not restore click delivery suggests the problem lives in the CoreInput/InputSite routing layer used by Terminal's island hosting: pointer input remains routed to Terminal's InputSite even after the capture is released, and only the desktop switch tears down and rebuilds the routing state.

All observed occurrences so far happened while a tab was running a TUI app with SGR mouse tracking (1006) enabled and heavy output, but this may be coincidental (that tab is open during most of the workday) — I have not yet ruled out occurrences without it. What is unambiguous is the timing: the first occurrence was the day after installing the June 2026 cumulative updates, on a Terminal version that previously ran the same workload cleanly, which points to a regression introduced or exposed by an OS input-stack change rather than a Terminal release.

Steps to reproduce (as observed; not deterministic, trigger not isolated)

1. Open Windows Terminal 1.24.11321.0. In all occurrences so far, one tab was running a TUI app with SGR mouse tracking enabled and continuous output (Claude Code CLI), but this has not been confirmed as required.
2. Work in other applications.
3. Within minutes to hours, mouse clicks stop registering desktop-wide; the active window is deactivated by each click but nothing is activated.
4. Verify with a WinEvent trace: EVENT_SYSTEM_CAPTURESTART on Windows.UI.Input.InputSite.WindowClass with no matching CAPTUREEND.
5. Recover via Ctrl+Alt+Del → Cancel.

Expected behavior

Mouse capture taken by Terminal's input window should always be released promptly, and a released capture should never leave system-wide pointer routing in a broken state.

Workarounds found

• Ctrl+Alt+Del → Cancel (reliable).
• Running the same TUI app under conhost avoids the issue entirely (currently verifying long-term).

  Mouse clicks stop working system-wide while a VT mouse-mode TUI app is running — stuck capture in Windows.UI.Input.InputSite.WindowClass, only recoverable via secure desktop (Ctrl+Alt+Del)

  Environment

  • Windows Terminal 1.24.11321.0 (Store)
  • Windows 11 25H2, build 26200.8655 (KB5094126 + KB5094135 installed 2026-06-10 — issue first appeared immediately after; the same workload had run for weeks without problems before)
  • Shell/profile: PowerShell 7 tab + a tab running Claude Code CLI (a TUI app that enables VT/SGR mouse tracking, mode 1006)
  • Hardware: laptop, external USB mouse and built-in precision touchpad (both affected identically — rules out the pointing device)

  Summary

  While the Claude Code tab is active and busy, mouse clicks intermittently stop working across the entire desktop, not just inside Terminal:
  • Pointer movement is normal.
  • Left and right clicks anywhere (other apps, taskbar, desktop) do nothing, except that the currently active window is deactivated by the click (focus is lost, nothing is activated).
  • Keyboard input keeps working (Alt+Tab etc.).
  • Clicks sometimes still work in elevated windows (e.g. Task Manager), consistent with UIPI protecting high-IL windows from a medium-IL process interfering with input.
  • The only reliable recovery is switching to the secure desktop (Ctrl+Alt+Del) and pressing Cancel. After that, everything works again until the next occurrence.

  Diagnostics performed

  I traced the failure with a SetWinEventHook logger covering EVENT_SYSTEM_FOREGROUND, EVENT_SYSTEM_CAPTURESTART/END and menu events, plus a 100 ms poll of GetForegroundWindow() logging NULL transitions. Key excerpt (annotated):

    ; normal, healthy capture pairs are ~100 ms (click down/up):
  

[16:41:32.700] CAPTURE+ PID 8268 WindowsTerminal class:Windows.UI.Input.InputSite.WindowClass '' [16:41:32.788] CAPTURE- PID 8268 WindowsTerminal class:Windows.UI.Input.InputSite.WindowClass ''

; failure begins: capture taken by the InputSite window and never released [16:43:17.941] CAPTURE+ PID 8268 WindowsTerminal class:Windows.UI.Input.InputSite.WindowClass ''

; 25 seconds later the user presses Alt+Tab; the capture is released by the ; foreground change, but clicks REMAIN dead system-wide afterwards: [16:43:42.893] FG PID 15128 explorer class:ForegroundStaging '' [16:43:42.896] CAPTURE- PID 8268 WindowsTerminal class:Windows.UI.Input.InputSite.WindowClass '' [16:43:42.909] FG PID 15128 explorer class:XamlExplorerHostIslandWindow 'Task Switching' [16:43:43.914] FG PID 8268 WindowsTerminal class:CASCADIA_HOSTING_WINDOW_CLASS 'PowerShell 7 (x64)'

; between 16:43:43 and 16:43:53 the user clicks on several windows: ; NO foreground events are generated at all - clicks never reach activation.

; user invokes Ctrl+Alt+Del (secure desktop appears as NULL foreground ; from the default desktop) and presses Cancel: [16:43:53.850] *** FOREGROUND = NULL *** [16:44:04.041] *** FOREGROUND BACK after 10.2s *** PID 8268 WindowsTerminal 'PowerShell 7 (x64)'

; after returning from the secure desktop, capture pairs are healthy again: [16:44:14.243] CAPTURE+ PID 8268 WindowsTerminal class:Windows.UI.Input.InputSite.WindowClass '' [16:44:14.380] CAPTURE- PID 8268 WindowsTerminal class:Windows.UI.Input.InputSite.WindowClass ''

  
  Additional observations from earlier traces during failure periods:
  
  - `GetGUIThreadInfo(0)` reports no capture, no menu mode, no move/size loop on the foreground thread (the capture is held on a different thread).
  
  - `GetForegroundWindow()` is frequently NULL during the failure; clicks briefly activate a window, after which foreground drops again.
  
  - No hung windows (`IsHungAppWindow` negative for all top-level windows), no stuck modifier keys (`GetAsyncKeyState` clean), no transparent overlay (`WindowFromPoint` returns the expected window).
  
  - Injecting synthetic button-up events for all buttons via `mouse_event` does **not** recover the state.
  
  - Clicking inside the Terminal window does **not** recover the state.
  
  - Only the secure desktop transition recovers it.
  
  ## Interpretation

  The stuck `CAPTURE+` on `Windows.UI.Input.InputSite.WindowClass` and the fact that releasing the capture does not restore click delivery suggests the problem lives in the CoreInput/InputSite routing layer used by Terminal's island hosting: pointer input remains routed to Terminal's InputSite even after the capture is released, and only the desktop switch tears down and rebuilds the routing state.
  
  All observed occurrences so far happened while a tab was running a TUI app with SGR mouse tracking (1006) enabled and heavy output, but this may be coincidental (that tab is open during most of the workday) — I have not yet ruled out occurrences without it. What is unambiguous is the timing: the first occurrence was the day after installing the June 2026 cumulative updates, on a Terminal version that previously ran the same workload cleanly, which points to a regression introduced or exposed by an OS input-stack change rather than a Terminal release.
  
  ## Steps to reproduce (as observed; not deterministic, trigger not isolated)

  1. Open Windows Terminal 1.24.11321.0. In all occurrences so far, one tab was running a TUI app with SGR mouse tracking enabled and continuous output (Claude Code CLI), but this has not been confirmed as required.
  
  1. Work in other applications.
  
  1. Within minutes to hours, mouse clicks stop registering desktop-wide; the active window is deactivated by each click but nothing is activated.
  
  1. Verify with a WinEvent trace: `EVENT_SYSTEM_CAPTURESTART` on `Windows.UI.Input.InputSite.WindowClass` with no matching CAPTUREEND.
  
  1. Recover via Ctrl+Alt+Del → Cancel.
  
  ## Expected behavior

  Mouse capture taken by Terminal's input window should always be released promptly, and a released capture should never leave system-wide pointer routing in a broken state.
  
  ## Workarounds found

  - Ctrl+Alt+Del → Cancel (reliable).
  
Related (same symptom reported after an earlier update, November 2025): https://learn.microsoft.com/en-us/answers/questions/5609634/mouse-clicks-stop-working-after-latest-windows-11