Computer use: invisible / click-through overlay windows falsely block clicks (Bartender, menu-bar managers)

Summary

The computer-use permission gate refuses clicks with

Click at these coordinates would land on "<App>", which is not in the allowed applications.

when an invisible or click-through overlay window owned by a non-allowlisted app sits above the intended target. A real click at those coordinates lands on the target app, not the overlay — so the gate is a false positive, and computer use is effectively disabled across whatever screen region the overlay covers.

Bartender is the app I hit this with, but it is not doing anything unusual: transparent, click-through overlay windows are a standard macOS technique.

Environment

• Claude Code 2.1.220
• macOS 26.6 (Tahoe)
• Bartender 6, version 6.6.2

Reproduction

1. Run a menu-bar manager that creates overlay windows (Bartender 6 here).
2. Grant computer-use access to some app — e.g. System Settings.
3. Attempt to click anywhere in the region the overlay covers, including well inside the granted app's own window.

Both of these were refused:

| Click | Intended target | Result |
|---|---|---|
| (1224, 14) | Control Center menu bar item | blocked, "would land on Bartender 6" |
| (251, 53) | System Settings window controls | blocked, "would land on Bartender 6" |

Evidence

CGWindowListCopyWindowInfo(.optionOnScreenOnly) at the time of the refusals:

owner              layer   alpha   bounds
Bartender 6           26    0.00   x=0 y=-1 w=1512 h=34
Bartender 6           25    1.00   x=0 y=0   w=1512 h=500
System Settings        0    1.00   x=205 y=33 w=723 h=886

Topmost window containing each probe point (front-to-back scan):

(1224,14) -> Bartender 6  layer=26 alpha=0.00
(251,53)  -> Bartender 6  layer=25 alpha=1.00

Two things stand out:

1. The click at (1224, 14) was attributed to a window with alpha exactly 0.00. A fully transparent window should never be considered the target of a click.
2. The click at (251, 53) is inside the System Settings window, which is visibly rendered at that point in the screenshots the tool itself returns. The overlay above it is click-through.

That these overlays are click-through is demonstrable from ordinary use: the machine is operated normally, and no user could click any window in the top 500px of the screen if that window actually accepted mouse events.

Impact

Any app that keeps an overlay window above the normal window layer disables computer use for that whole region:

• menu-bar managers: Bartender, Ice, Hidden Bar, Vanilla
• desktop/overlay tools: Übersicht, Hammerspoon
• screen tinting and annotation utilities

Bartender's overlay spans the menu bar and the top third of the display, which covers the menu bar, most window title bars, and most open menus — i.e. much of what one would want to automate.

Working around it means quitting the user's utility, which is intrusive and not always acceptable.

Suggested fix

In the hit-test that backs the gate, skip windows that cannot receive the click:

• kCGWindowAlpha == 0 — invisible; cannot be the click target. This alone fixes the menu-bar case.
• Windows whose owner has set ignoresMouseEvents (click-through). CGWindowListCopyWindowInfo does not expose this directly.

For the general case, the accessibility API answers the real question — "what would actually receive a click here" — rather than "what window geometrically contains this point":

AXUIElementCopyElementAtPosition(systemWide, x, y, &element)

then resolve that element's PID to an application. That is the same resolution the window server performs for a physical click, so it cannot disagree with the user's own experience of clicking.

A narrower mitigation, if the hit-test stays geometric: allow the click when the topmost containing window is fully transparent, and fall through to the next window down.