Windows computer use minimizes all non-allowlisted windows before screenshots and never restores them, breaking TextInputHost (emoji/clipboard panel) and the lock screen

Summary

On Windows, computer use minimizes every window that is not in the session allowlist before it takes a screenshot, and never restores them. This includes system UI windows. Once the CoreWindow of TextInputHost.exe (the host of the Win+. emoji panel and Win+V clipboard history) has been minimized, the input panel stays broken until TextInputHost is restarted. The lock screen curtain (LockApp.exe) appears to break the same way.

Environment

• Claude Desktop 2.26454.2.0 (MSIX), Code tab sessions using the built-in computer-use MCP (mcp__computer-use__*)
• Windows 11 Home 25H2, build 26200.9457, two monitors

Steps to reproduce

1. Confirm that Win+. (emoji panel) works in any text field.
2. From a session in the desktop app, call request_access with only ["Notepad"], then take one screenshot.
3. The screenshot result itself says: "textinputhost.exe", "msedgewebview2.exe", "batterybar.exe", "systemsettings.exe", "nvidia overlay.exe", "asus_framework.exe" were also hidden.
4. Press Win+. again. The panel no longer opens.

What we observed

• TextInputHost's Windows.UI.Core.CoreWindow is left minimized (IsIconic = true, at -32000,-32000). Before the screenshot it was a normal 1920x1080 window.
• Restoring it with ShowWindowAsync(SW_SHOWNOACTIVATE) does not help. The panel stays broken until TextInputHost.exe is restarted; one of its threads was stuck for minutes waiting on an internal COM call.
• In day-to-day use, depending on timing, the panel either does not open, or opens frozen: clicks do nothing and Esc does not close it. #69887 (closed as stale) looks like the same mechanism, since the IME candidate window is also hosted by TextInputHost and restarting TextInputHost fixed it there too.
• The same screenshot also minimized these windows and never restored them: the user's Chrome and file-manager windows, the SystemSettings and Realtek Audio Console CoreWindows, BatteryBar, NVIDIA GeForce Overlay, and IME status windows.
• Windows' own Win+D and Win+M do not minimize TextInputHost's CoreWindow (tested), so this behavior is specific to computer use.
• Lock screen: we matched the "were also hidden" lists in our session transcripts against Winlogon lock/unlock events. When a list included lockapp.exe, the next lock showed only the background image (no clock, no sign-in prompt) until Ctrl+Alt+Del. 3 of 4 incidents matched, and both periods in which LockApp was not hidden had only normal locks. Two incidents overall (one panel, one lock) had no logged screenshot before them; they may come from computer use outside the Code tab, which our transcripts do not cover.

Expected

• Computer use never minimizes shell or system windows (TextInputHost, LockApp, SystemSettings and other Windows.UI.Core.CoreWindows, overlays).
• Every window it hides is restored when the action, turn or session ends.
• Prefer masking or excluding windows in the screenshot over minimizing the user's real windows.

Workaround

Restart TextInputHost (Stop-Process -Name TextInputHost -Force). Adding textinputhost.exe to request_access keeps it from being hidden. We now also run a watcher that restarts TextInputHost whenever its CoreWindow becomes minimized.