[BUG] Windows: computer-use screenshot sends TextInputHost.exe into a 97-99% CPU loop
Summary
On Windows 11, a screenshot taken by the computer-use tool in the Claude desktop app (Code tab) sends TextInputHost.exe into a loop. One of its threads then holds one CPU core at about 97-99 % until the process is ended. The laptop runs hot and nothing on screen shows why. The screenshot result lists textinputhost.exe among the windows it hides during capture, and the loop starts within 15-30 seconds of that capture.
Environment
- Windows 11 Home, build 26200.9457, Intel Core i7-1255U (12 logical processors), Lenovo ThinkPad L15 Gen 3
- Claude desktop app, Code tab, computer-use tools (
mcp__computer-use__screenshot), 2026-09-28 TextInputHost.exefromC:\WINDOWS\SystemApps\MicrosoftWindows.Client.CBS_cw5n1h2txyewy\(packageMicrosoftWindows.Client.CBS1000.26100.360.0), signedCN=Microsoft Windows
Steps to reproduce
- End any running
TextInputHost.exe(Task Manager > Details). Windows starts a fresh one on demand. - Take no screenshots for a few minutes and sample the new process's CPU time. It stays flat.
- Take one screenshot with the computer-use tool.
- Sample the process's CPU time again.
Measured (process CPU time, sampled with Get-Process)
| Time | Event | TextInputHost CPU-seconds |
|---|---|---|
| 18:39:33-18:42:03 | no screenshots, sampled every 30 s | 1.6, flat |
| 18:42:10 | one screenshot (the result lists textinputhost.exe as hidden) | - |
| 18:42:26 | | 19.7 |
| 18:42:41 to 18:44:11 | 15 s steps | 34.3, 48.6, 63.0, 77.4, 92.0, 106.5, 121.2 (about 97 % of one core) |
- Second deliberate reproduction at 18:57: a copy at 1.8 CPU-seconds was at 97 % of one core 30 s after one screenshot.
- The same pattern was seen earlier at 18:35 with a copy that had been idle for 8 minutes.
- Earlier the same day, after a session with many screenshots, one copy had used 14,594 CPU-seconds. 14,520 of those were in a single thread; its other 40 threads were idle.
Impact
- One core pinned indefinitely, meaning higher temperature, fan noise and battery drain. Measured: 48.1 C and 20 % total load while stuck, against 41.1 C and 2 % two minutes after ending it.
- It keeps happening for as long as the tool keeps taking screenshots.
- Users have no visible sign that anything is wrong.
Expected
Hiding or masking windows during a capture should not leave a system process spinning. If the masking is what triggers the loop, excluding TextInputHost.exe windows from masking, or restoring them in a way that doesn't trigger it, may avoid it.
Workaround in use
A per-user scheduled task checks every 10 minutes and ends TextInputHost.exe only if it used at least 90 % of one core over a full minute. Windows restarts it on demand.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗