[BUG] Computer-use screenshot masks windows owned by a granted, tier="full" app

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?

Product: Cowork mode / Claude computer-use MCP (mcp__computer-use__*)
OS: Windows 11 (single monitor)
App: Quicken Classic Deluxe R66.28, Build 27.1.66.28, installed at C:\Program Files (x86)\Quicken\qw.exe
Date observed: 2026-04-19

Summary

After request_access(["Quicken"]) returns a grant with tier: "full" for qw.exe, every subsequent screenshot call renders Quicken's top-level windows (password dialog and unlocked main window) as a solid dark rectangle instead of the expected window content. The input path is unaffected — clicks and keystrokes land correctly on those same windows — so the attribution is working for input gating but not for screen capture.

What Should Happen?

Expected behavior

A window owned by a process whose executable path exactly matches an entry in the session allowlist should be captured, not masked.

Error Messages/Logs

## Actual behavior

Screenshots show the desktop as a uniform dark field where Quicken's window should be. No "masked" note appears in the screenshot response — only the ambient empty-desktop look. The user can see Quicken's window normally on their screen; the issue is Claude-side only.

## Diagnostic confirming the window is owned by the granted process

Ran a Win32 `EnumWindows` + `GetForegroundWindow` PowerShell diagnostic while Quicken's main window was in focus. Relevant output:


Foreground window: hWnd=0x4C0D0C, PID=10348, Process=qw, Path=C:\Program Files (x86)\Quicken\qw.exe
Window title: "Quicken Classic Deluxe - qdata - [Home]"
Window class: QFRAME


Grant in effect at the time of capture:


{
  "bundleId": "c:\\program files (x86)\\quicken\\qw.exe",
  "displayName": "Quicken",
  "tier": "full",
  "screenshotFiltering": "mask"
}

## Hypothesis

Likely a mismatch between input-gating attribution (which correctly identifies `qw.exe` as the window owner and allows clicks/keys through) and screen-capture attribution (which is masking the surface anyway). Plausible cause: Quicken registers a custom window class (`QFRAME`) and custom-draws its client area rather than composing standard Win32 controls. If the capture path verifies paint ownership in addition to top-level window ownership, or falls back to mask-on-unknown-surface, it would mask `QFRAME` content despite the allowlist.

Steps to Reproduce

Reproduction

1. Windows 11 machine with Quicken Classic Deluxe installed.
2. Start a Cowork computer-use session.
3. request_access(["Quicken"]) → grant returns with tier: "full" and bundleId pointing at qw.exe.
4. open_application("Quicken"); wait for the data-file password prompt.
5. screenshot → expect to see the password dialog; observe solid dark rectangle instead.
6. key("win+r"), type a PowerShell one-liner, paste into the Quicken dialog, press Enter → unlock succeeds blind, confirming input gating works.
7. screenshot of the unlocked main window → still masked.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.114.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Terminal.app (macOS)

Additional Information

Impact

Computer-use is usable for Quicken only for keyboard-deterministic flows (launch, unlock, keyboard-menu navigation). Anything requiring visual inspection — reading a dialog's exact content, finding a button at an unknown position, verifying a report on screen — is blocked. Workarounds so far: rely on user confirmation, and use Quicken's file exports (CSV/PDF reports) read through the shared workspace folder.

Suggested next steps on your end

• Check whether the capture pipeline applies paint-ownership / DWM-surface verification in addition to top-level window ownership, and reconcile with the input-path attribution.
• If intentional, expose a way for the grant to opt in to capturing custom-class surfaces (or surface a clearer error/note in the screenshot response so callers know the mask is being applied).
• Consider emitting the "masked at rect (x,y,w,h)" note even when the mask color blends with the ambient desktop, so tool callers can at least tell the window is present.