Computer use refuses clicks under an invisible, click-through overlay window (Wispr Flow "Status" dialog)

Summary

The desktop app's computer-use tools (mcp__computer-use__computer_batch) refuse clicks and drags whose coordinates fall under a window that belongs to a non-allowlisted app, even when that window is a fully transparent, click-through overlay. Wispr Flow (a dictation utility) keeps a permanent invisible AXDialog window titled "Status", 512 × 586 pt, over the lower middle of the screen. Every automation step that lands inside that rectangle is rejected with:

FAILED — Click at these coordinates would land on "Wispr Flow", which is not in the allowed applications.

The user never sees this window and clicks through it all day. The allowlist check treats it as a real target.

Screenshot: the red rectangle is the invisible window, drawn at the exact frame macOS reports (position 704,431 size 512,586, subrole AXDialog, title "Status").

Environment

• Claude desktop app 1.52386.3, Code tab, macOS 26.6.2 (25G83), Apple M2 Max
• Claude Code 2.1.245
• Wispr Flow 1.6.827
• Target app granted at tier "full" (a native macOS app, not a browser or terminal)

Steps to reproduce

1. Run Wispr Flow so its floating status indicator exists (it is present whenever the app runs, even idle).
2. Grant Claude access to any native app whose window covers the lower middle of the screen.
3. Ask Claude to click or drag at a point inside the rectangle 704,431 to 1216,1017 pt on a 1920 × 1080 display.

Observed: the action is refused with the message above, naming Wispr Flow. app_batch background clicks on the same app succeed, because they go through AX rather than the screen hit-test.

Why it matters

1. It blocks legitimate automation over a large screen region with no visible cause; the user cannot tell why "the app in front" is not clickable, since nothing is drawn there.
2. It can interrupt a gesture with the mouse button held. In my session a left_mouse_down succeeded, a subsequent mouse_move inside the rectangle was refused, and the batch stopped with the button still down. The next actions resized the user's window by dragging its edge.

Suggested behavior

• When the window under the point has alpha 0, or its owning app declares the window as ignoring mouse events, do not treat it as the click target; fall through to the next window in z-order, or at least report both the blocking window and the app underneath so the user can decide.
• On any refusal inside a batch, release a held mouse button before returning, or refuse the left_mouse_down up front when the planned path crosses a non-allowed window.
• Surface the blocking window's title, frame, and transparency in the error so the user can find and close it. "Wispr Flow" alone sent us looking for a visible window that does not exist.

Workaround

Quit Wispr Flow (or disable its floating status indicator). The refusals stop immediately.

🤖 Generated with Claude Code