[BUG] Computer use screenshots fully masked (solid gray) on Windows, even for granted frontmost apps

Independent confirmation of the cua-driver.exe overlay root cause — different machine, different app version, and removing it fixed the bug completely.

Environment

• Windows 11 Pro 10.0.26200 (same build as OP)
• Claude desktop app 1.44121.4 (Electron 42.10.0, Node 24.18.1) — note this is a different version from the earlier analysis, so the bug is not version-specific
• Dual monitor: MAG 244F (primary, 1920×1080) + DELL E1916HV
• NVIDIA GPU
• screenshotFiltering: "mask" in every request_access response

Symptom

Every computer_screenshot returned a uniform blank dark frame (~#1a1a1a) on both monitors. Window metadata was always correct — the tool accurately enumerated and named the real on-screen windows and reported their positions — but the pixels were always empty.

The decisive test: I granted Windows Security while it was maximized and in the foreground. It correctly dropped out of the willHide list, confirming the grant applied. The screenshot was still entirely blank. An allowlisted, foreground, full-screen window produced zero pixels.

Root cause — confirmed

cua-driver.exe was running on my machine and appeared in the willHide list of every single screenshot attempt, across ~2 hours and a full OS reboot. Example from a late attempt:

"textinputhost.exe", "lockapp.exe", "(name withheld)", "msedgewebview2.exe", "cua-driver.exe" were hidden.

This matches the described mechanism exactly: its full-screen click-through layered overlay (WS_EX_LAYERED | WS_EX_TRANSPARENT | WS_EX_NOACTIVATE) is invisible to the user, but the mask pass paints its full window bounds with no z-order or occlusion awareness, wiping the entire frame regardless of what is stacked above it.

On my machine it was installed by Hermes Agent (Nous Research), which bundles Cua Driver. It was launched by an elevated scheduled task cua-driver-serve (RunLevel Highest) running cua-driver.exe serve, with the binaries in C:\Users\<user>\.cua-driver\packages\releases\0.22.1-x86_64-pc-windows-msvc\, surfaced via nested junctions at AppData\Local\Programs\Cua\cua-driver\bin.

Fix — verified

Disable-ScheduledTask -TaskName 'cua-driver-serve'   # elevated
Stop-Process -Name cua-driver -Force                  # elevated

Screenshots recovered immediately — full desktop, correct content, both monitors. Confirmed again after uninstalling Hermes Agent, deleting both Cua Driver locations, and rebooting. Nothing respawned; screenshots still work.

Supporting evidence — Windows Event Log

I exported the Application log (391 events, 3 Sep 15:09 → 4 Sep 02:30 UTC) covering the whole failure window. Useful negatives that should help rule out competing theories:

• Zero application crash/hang events (Event ID 1000 / 1001 Application Error / AppHang)
• Zero display-driver TDR or reset events (no nvlddmkm, dxgkrnl, Event ID 4101)
• No mention of cua-driver.exe anywhere in the log, at any severity

The failure is completely silent — no crash, no GPU reset, no log line. This strongly supports the "mask pass paints the frame, capture itself succeeds" explanation over any driver/capture-failure theory, and it is the single worst thing about this bug from a user's perspective.

Things I ruled out (all negative, so nobody else has to)

HDR off · Windows "Screenshots and screen recording access" on · "Let desktop apps take screenshots" on · Claude app restart · full PC reboot · Process Lasso terminated · Defender exclusion added for the .cua-driver folder · granting every process reported as hidden (including msedgewebview2.exe, systemsettings.exe, textinputhost.exe) · both monitors tested · computer use re-enabled via the in-chat prompt · granting COMSOL's real UI process (comsolui.exe) rather than its launcher (comsol.exe)

None of these made any difference. Only killing cua-driver.exe did.

Two side findings, possibly separate issues

1. Grant state is unstable. Grants repeatedly vanished between consecutive tool calls seconds apart — computer_resolve_access returned apps under alreadyGranted, then moments later the same query returned alreadyGranted: [] with computer_list_granted_applications reporting allowedApps: [].

A likely cause appears in the Event Log: an MSIX package servicing pass at 18:43:22 UTC logged

AppXDeploymentServer 2562: MSIXDeployment ... DeleteMachineFolder
Package Claude_1.44121.4.0_x64__pzs8sxrjxfjjc removed machine folder
C:\ProgramData\Microsoft\Windows\AppRepository\Families\ApplicationData\Claude_pzs8sxrjxfjjc:
The system cannot find the path specified.

CoworkVMService stopped at 18:43:26 and restarted at 18:47:45. Immediately after, computer_screenshot returned an error I had not seen at any point earlier in the session: "Computer use is available on this device but not turned on yet." Servicing appears to tear down app state underneath a live session with no notice to the user or the agent.

2. CoworkVMService cannot configure its own SCM recovery actions. On 100% of service starts (observed at 16:58:23, 18:47:45, 01:50:09 UTC) it logs Event ID 1, Level Warning:

Claude VM Service: failed to configure SCM recovery actions; if the service crashes it will not restart until the machine reboots: open service: Access is denied.

and on stop:

Claude VM Service: failed to disarm SCM recovery actions for this stop; if the stop overruns, the service may be auto-restarted during package servicing: open service: Access is denied.

By its own warning text, a crash leaves the service dead until reboot. Unrelated to this bug but worth fixing.

Suggested fixes

Seconding the earlier suggestions, in the same priority order:

1. Mask only each non-granted window's visible region (subtract higher-z windows) rather than its full bounds.
2. Skip click-through transparent overlays (WS_EX_TRANSPARENT | WS_EX_LAYERED) entirely — they contribute no readable pixels.
3. At minimum, fail loudly. When a capture comes back mostly or fully masked, name the window/process responsible in the tool result. A blank image is indistinguishable from "the screen is genuinely dark," which is what sent me through a full OS reboot, disabling a third-party utility, and adding a Defender exclusion before landing on the actual cause.

Diagnostic others can run

Cua Driver is bundled by several agent tools (Hermes Agent among them), and any always-on overlay utility — screen annotation tools, gamma/f.lux-style tools, some remote-control drivers — should reproduce this. If your screenshots are blank on Windows, check whether the willHide list in your tool results contains a process you don't recognise. On my machine cua-driver.exe was in every one. Kill that process and screenshots recover instantly.

OP here — confirming the full-bounds mask painting mechanism from the comment above, but with an important twist: on my machine the offending "overlay" is the Claude desktop app's own maximized window. No third-party software involved.

Environment (same as OP report)

• Windows 10 Pro 10.0.19045, single monitor 2560×1440 @ 125% scaling
• screenshotFiltering: "mask", granted app: Notepad (tier "full")

Diagnostic

Following the cua-driver.exe lead, I enumerated all visible fullscreen layered windows (WS_EX_LAYERED, bounds ≥ screen size) via EnumWindows/GetWindowLong:

• No cua-driver.exe, no Hermes Agent, no third-party overlay of any kind.
• Exactly one match: the Claude desktop app's own main window (claude.exe, Electron Chrome_WidgetWin_1 class, 2578×1408 — i.e. maximized, slightly overhanging the 2560×1440 screen).

Reproduction / proof

1. Claude app maximized (how I, and I suspect most users, run it) → every computer_screenshot is a uniform ~#1E1E1E frame. This held even with the granted Notepad foreground and focused, and with the game/other windows stacked well above Claude's window in z-order.
2. ShowWindow(claudeHwnd, SW_MINIMIZE) → the very next computer_screenshot renders the entire desktop perfectly (wallpaper, icons, taskbar, the "Claude is using your computer" pill).
3. Restore the window → blank frames return.

So the mask pass paints the full bounds of the non-granted Claude window with no z-order/occlusion awareness, exactly as described above — and since the app's own window is (a) never in the user's grant list and (b) very commonly maximized, this reproduces with zero third-party software. That likely explains why this bug is hit so widely: every user running the app maximized on Windows gets a 100% masked frame regardless of what they granted.

Side observation: input was separately blocked for an elevated game process (UIPI, expected), but metadata in screenshot results was always correct — only pixels were wiped, matching the "capture succeeds, mask wipes the frame" theory.

Suggested fix addition

On top of the three suggestions above (visible-region masking, skipping click-through overlays, failing loudly), a trivial targeted fix: exempt the Claude app's own window from the mask pass entirely, or auto-minimize it during capture — it already shows the "Claude is using your computer" indicator while driving, so hiding/shrinking it during computer use would match user expectations.

Same issue here. Every computer-use screenshot is a uniform dark gray (#1E1E1E), on both monitors, even with a granted app (Notepad / ChatGPT) frontmost.

Environment:

• Windows 11 Pro 25H2 (build 26200)
• Claude Desktop 2.7032.0.0 (Microsoft Store / MSIX)
• GPU: NVIDIA GeForce RTX 5060 (both monitors connected) + AMD Radeon iGPU
• 2 monitors, 1920x1080 each

Already tried (no change):

• Restarting Claude Desktop (fully quit from tray)
• Setting Claude to "High performance (RTX 5060)" in Windows Graphics settings
• Closing other screen-capture apps (PicPick)
• Granting msedgewebview2.exe / lockapp.exe / systemsettings.exe
• Windows Defender shows no detection of cua-driver.exe

It worked on my previous PC with the same account, so this looks like a regression.