Screenshots return black/masked images on Windows — screenshotFiltering: mask blocks all computer-use
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?
Environment
- OS: Windows 11 Pro 10.0.26200
- Claude Code: Desktop App (Windows)
- Session type: Interactive (Claude Code desktop)
Problem
Every screenshot taken via computer-use tools returns a completely black image.
The request_access response shows screenshotFiltering: "mask" which appears
to be blocking all screen capture.
This has persisted across multiple sessions. I have reported this many times
with no resolution.
Impact
Claude cannot see the screen at all, making computer-use tasks impossible.
Every task that requires screen reading (clicking, verifying UI, reading values
from browser) requires me to manually relay information, massively slowing work.
Steps to reproduce
- Open Claude Code desktop on Windows 11
- Ask Claude to use computer-use tools
- Claude calls
request_access— response showsscreenshotFiltering: "mask" - Any screenshot taken returns a solid black image
Expected
Screenshots should show actual screen content.
Actual
All screenshots are black. Claude is completely blind.
What Should Happen?
Expected
Screenshots should show actual screen content.
Error Messages/Logs
## Problem
Every screenshot taken via computer-use tools returns a completely black image.
The `request_access` response shows `screenshotFiltering: "mask"` which appears
to be blocking all screen capture.
This has persisted across multiple sessions. I have reported this many times
with no resolution.
## Impact
Claude cannot see the screen at all, making computer-use tasks impossible.
Every task that requires screen reading (clicking, verifying UI, reading values
from browser) requires me to manually relay information, massively slowing work.Steps to Reproduce
Steps to reproduce
- Open Claude Code desktop on Windows 11
- Ask Claude to use computer-use tools
- Claude calls
request_access— response showsscreenshotFiltering: "mask" - Any screenshot taken returns a solid black image
Claude Model
Sonnet (default)
Is this a regression?
Yes, this worked in a previous version
Last Working Version
UNKNOWN
Claude Code Version
- Claude Code version: 2.1.185
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
_No response_
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
THIS IS HAPPENING IN CLAUDE CODE AND IN COWORK
I hit this exact symptom (Windows 11 Pro 10.0.26200, desktop app 1.40609.0.0) and traced it to root cause. It is not
screenshotFiltering: "mask"blocking capture per se — capture succeeds, but the mask pass paints the whole frame.Mechanism (from inspecting the app bundle): the win32 screenshot path captures the full screen via
desktopCapturer, asks the native binding (cuMaskedWindowRects(allowedBundleIds)) for the bounds of every top-level window not owned by a granted app, and paints each rect with the mask color (BGRA 30,30,30 — a very dark gray that reads as "black") over the flat bitmap. The rects are raw window bounds with no z-order / occlusion / transparency awareness.Consequence: any visible, uncloaked, monitor-sized window belonging to a non-granted process masks 100% of every screenshot — including granted apps stacked visually above it. And because nothing errors, there is zero log output or diagnostic; the failure is completely silent.
Trigger on my machine:
cua-driver.exe(the Cua agent framework's driver, bundled by a Hermes agent install) parks a click-through full-screen overlay (WS_EX_LAYERED | WS_EX_TRANSPARENT | WS_EX_NOACTIVATE). Invisible to the user; wiped every screenshot for two months. Many common utilities create similar always-on overlays (screen-annotation tools, gamma/f.lux-style tools, some remote-control drivers), so this likely explains a good share of "all screenshots are black on Windows" reports. Probably the same window-enumeration blind spot as #85110, which is about overlays falsely blocking clicks.Repro: from any non-granted process, create a full-screen transparent layered top-level window; grant any app; take a screenshot → entire image is mask-colored.
Workaround for anyone hitting this: enumerate visible top-level windows (EnumWindows + GetWindowRect + DWMWA_CLOAKED) and look for a monitor-sized, uncloaked window owned by a process you haven't granted — then close/kill that process. Screenshots recover immediately.
Suggested fixes, in order of preference:
WS_EX_TRANSPARENT | WS_EX_LAYERED) — they contribute no readable pixels to the capture.Same root cause as #91079 — posting here since this issue describes the identical symptom and names screenshotFiltering: "mask" as the suspected mechanism.
It isn't that masking blocks capture. Capture succeeds; the mask pass paints the whole frame. The mask is applied to each non-granted window's raw bounds with no z-order or occlusion awareness, so any visible, uncloaked, monitor-sized window belonging to a non-granted process wipes 100% of every screenshot — including granted apps stacked visually above it.
On my machine the culprit was cua-driver.exe (Cua Driver, bundled by Hermes Agent). It parks a full-screen click-through layered overlay (WS_EX_LAYERED | WS_EX_TRANSPARENT | WS_EX_NOACTIVATE) — invisible to the user, but enough to blank every capture. It appeared in the willHide list of every single screenshot attempt I made.
Diagnostic: check whether the willHide list in your tool results contains a process you don't recognise. Any always-on overlay utility can do this — screen annotation tools, gamma/f.lux-style tools, some remote-control drivers.
Fix, verified:
powershell
Disable-ScheduledTask -TaskName 'cua-driver-serve' # elevated
Stop-Process -Name cua-driver -Force # elevated
Screenshots recovered immediately, and still work after a full uninstall and reboot.
My environment: Windows 11 Pro 10.0.26200 (same build as OP), Claude desktop app 1.44121.4 — a different version from OP's 2.1.185, so this isn't version-specific.
Full details in my comment on #91079, including Windows Event Log evidence (no crash, no GPU TDR, nothing logged at all — the failure is completely silent), the full ruled-out list, and two side findings about grant-state volatility and a CoworkVMService SCM permissions defect.
@at865 — worth checking whether you have cua-driver.exe or another overlay process running.