[BUG] Computer Use: all clicks blocked by Dock layer-20 hit-test surface on macOS 26.4/26.4.1 (regression from pre-26.4)

Update — clean user-side workaround found (hide the Dock, or fullscreen)

Additional probing on the same machine (macOS 26.4.1, Darwin 25.4.0, Build 25E253) reveals that the Dock-owned layer-20 tracking surface is conditional on the Dock being visible, not absolutely structural. Hiding the Dock (or putting the target app in fullscreen) tears it down immediately and restores normal click behavior.

Self-correction of the original report

The original report said I had exhausted all relevant toggles before concluding the surface was structural. That was overclaimed: I tested every com.apple.WindowManager flag (HideDesktop, EnableStandardClickToShowDesktop, GloballyEnabled, the Enable*HotKey family) but I had not tested com.apple.dock autohide. Autohide resolves the issue.

Workaround 1 — hide the Dock

defaults write com.apple.dock autohide -bool true && killall Dock

Or: System Settings → Desktop & Dock → "Automatically hide and show the Dock" ON.

Before (autohide=0) at coordinate (81, 313):

layer=20 alpha=1.0 owner="程序坞" pid=44807 title=""   ← blocks click
layer=0  alpha=1.0 owner="邮件"   pid=43778 title=""   ← actual app

After (autohide=1), same probe:

layer=0  alpha=1.0 owner="邮件" pid=43778 title=""                 ← now topmost
layer=-2147483624 owner="程序坞" pid=44807 title="Wallpaper-…"     ← Dock's only on-screen presence, at most-negative layer

No positive-layer Dock window remains anywhere in CGWindowListCopyWindowInfo(.optionOnScreenOnly, …). A subsequent mcp__computer-use__left_click({coordinate:[81,313]}) returns Clicked. and the app responds normally. A second click inside the same Mail window at a different coordinate also succeeds. No session restart, no reboot, no request_access re-grant needed.

Workaround 2 — fullscreen the target app

cmd+ctrl+f or the green title-bar button. Each fullscreen app lives in its own Space where the Dock is suppressed, so the layer-20 surface is absent for that Space's duration. Clicks inside fullscreen Mail succeed identically (Clicked. at multiple tested coordinates).

Verified in fullscreen via CG window probe — no owner="程序坞" layer=20 entry; the only Dock presence is its Wallpaper window for the new Space's UUID at the most-negative layer.

Updated root-cause framing

The layer-20 full-display surface is Dock's hover / magnification / Mission-Control-entry hit region for the visible Dock strip. When the Dock is hidden (via autohide or because the frontmost app is fullscreen), Dock doesn't need the region and tears it down. That is consistent with it being a hit-test region rather than a render canvas, and with kCGWindowSharingState=kCGWindowSharingNone — the region has no pixels to share, only a hit shape.

MCP fix recommendation unchanged

The proposed ~4-condition filter (Dock-owned + display bounds + kCGWindowSharingState=kCGWindowSharingNone + empty title) still applies, because the majority of macOS users run with Dock visible and should not have to reconfigure system UI to use Computer Use. The workaround above is a stopgap, not a resolution.

this pattern bit me last year on a macOS agent that used CGWindowListCopyWindowInfo for a pre-click hit-test gate. any invisible layer>=1 window with sharingState=0 becomes a silent click denier because it's in the z-order but not in the screenshot, so the model never sees what it's being blocked by. i ended up switching to AXUIElementCopyElementAtPosition for the allowed-app check instead, because the accessibility hit-test respects event-passthrough flags that CGWindowList completely ignores. Dock's full-display tracking surface is almost certainly passthrough for AX even when it shows up at layer 20 for CG. fixes the symptom without needing to diff structural Dock internals per macOS point release.

Surfacing @m13v's suggestion as the recommended fix path

Flagging @m13v's comment above for the Anthropic team's attention, since it cleanly supersedes the 4-condition CGWindowList filter I originally proposed:

switching to AXUIElementCopyElementAtPosition for the allowed-app check instead, because the accessibility hit-test respects event-passthrough flags that CGWindowList completely ignores. Dock's full-display tracking surface is almost certainly passthrough for AX even when it shows up at layer 20 for CG.

Why this is the better fix:

• CGWindowList is fundamentally the wrong tool here — it reports z-order geometry without honoring event-passthrough flags, so any layer ≥ 1 window with sharingState=0 becomes a silent click denier. Dock's layer-20 surface is just the first one we hit; Apple may ship more in future point releases.
• AX hit-testing (AXUIElementCopyElementAtPosition) is the same API path mouse events actually traverse, so it matches real click behavior by construction. No per-macOS-version heuristics required.
• My original filter proposal (Dock-owned + display bounds + sharingState=kCGWindowSharingNone + empty title) would unblock this specific regression but leaves the class of bug open.

Why the user-side workaround isn't a resolution:

Autohiding the Dock or fullscreening the target app does work (confirmed in my follow-up comment), but requiring end users to reconfigure system UI to use a shipped feature isn't viable for non-technical users, and fullscreen isn't always appropriate for the task (e.g., cross-app workflows, Finder drag-drop). The workaround is fine as a stopgap while the MCP server is patched; it shouldn't be the recommended long-term answer.

Happy to test a prerelease build of computer-use if helpful.

Independent visual confirmation of the trigger condition on macOS 26.4.1 (Build 25E253), Chinese locale.

I instrumented a Swift probe that polls CGWindowListCopyWindowInfo every 2s for 60s while a human user toggled between two macOS Spaces hosting the same app (Claude.app):

• Space A: Claude.app windowed (Dock visible)
• Space B: Claude.app fullscreen (its own Space, Dock suppressed)

Time  | layer-20 Dock surface present? | Wallpaper-<UUID> tag
------|--------------------------------|---------------------
  0s  | YES                            | (no UUID — Space A)
 26s  | NO   (transition)              | 342B5FC3   (Space B)
 46s  | YES  (transition)              | (no UUID — Space A)
 60s  | YES                            | (no UUID — Space A)

Two transitions captured in real time, perfectly synced with the Space switch. The Wallpaper-<UUID> tag flips at the exact same sample as the layer-20 surface appears/disappears. This is direct, reproducible evidence that the surface lifecycle is bound to the active Space's Dock-visibility state, not to global Dock settings or process restarts (Dock pid was unchanged across the entire run, autohide=false the entire run).

Implication for the fix:

• Any Space-bound pre-click gate will see this surface intermittently, depending on which Space is active at the moment of the call. End users will observe non-deterministic failures — which matches the user-side experience reported in this issue.
• The proposed AXUIElementCopyElementAtPosition fix (m13v's comment above) is immune to this since AX hit-testing respects event-passthrough flags and is not Space-sensitive in the same way.

Probe script (Swift, no external deps) and full session walkthrough available on request. Happy to test a prerelease build.

Confirmed still broken on macOS 26.5 / Claude Desktop 1.11187.4

macOS 26.5 (Darwin 25.5.0), Apple Silicon (MacBook), Claude Desktop 1.11187.4, computer-use MCP — same com.apple.dock error on every coordinate. The regression persists through at least 26.5.

Workaround status on 26.5:

Both workarounds from @alexcz-a11y's follow-up hold on 26.5:

• Dock autohide (defaults write com.apple.dock autohide -bool true && killall Dock) → layer-20 surface disappears, clicks succeed.
• Fullscreen (Ctrl+Cmd+F / green button) → layer-20 surface absent in that Space, clicks land correctly.

Note on the fullscreen workaround: do not interleave an MCP left_click while in fullscreen — it switches the active Space back to the main desktop and the next CGEvent click misfires or exits fullscreen. Use only screenshot (read-only, safe) + CGEvent-synthesized HID clicks while in fullscreen.

Growing scope:

Every new Mac shipped with Tahoe 26.4+ and every user who upgraded from pre-26.4 is now affected. The affected population grows daily — this is not a niche edge case. The stale label understates urgency.

Cross-reference: Anthropic support ticket 215474529678088 was opened and escalated to engineering — attaching here for tracking.

Still reproduces on macOS 26.5.1 — plus a second trigger surface (Notification Center desktop widgets) and a fully-working two-part workaround

Confirming the regression persists on the latest point release, and adding three new data points: the exact CG signature on 26.5.1, a second blocking surface beyond the Dock, and a cross-check against an AX-based implementation that works.

Environment

• macOS 26.5.1 (Build 25F80), Darwin 25.5.0, Apple M4
• Claude Desktop 1.13576.4 (clean reinstall of the official Developer-ID build — ruled out a third-party-modified/ad-hoc-signed app as a cause)
• Single display: 3840×2160 panel, "looks like" 1920×1080 @2× HiDPI, 144 Hz
• Locale: zh-CN, so in the messages below 程序坞 = Dock, 通知中心 = Notification Center, 访达 = Finder

Symptom — identical to OP

Every pixel-coordinate click returns Click at these coordinates would land on "程序坞", which is not in the allowed applications. screenshot, request_access, list_granted_applications, cursor_position, and all keyboard tools work; only clicks are refused. Verified independent of Accessibility/Screen-Recording grants (re-granted + relaunched), of display scaling (tested at 1× non-HiDPI — still fails), and of third-party input drivers (uninstalled Razer Synapse virtual HID + ToDesk — no change).

CGWindowListCopyWindowInfo confirms the layer-20 Dock surface, matching OP exactly:

owner=程序坞(Dock)  layer=20  bounds=(0,0,1920x1080)  sharingState=0

New: a second trigger surface — Notification Center desktop widgets

After applying the Dock-autohide workaround, clicks were still refused, but the owner changed from 程序坞 to 通知中心. This machine has two Notification Center widgets placed on the desktop; CGWindowList shows:

owner=通知中心(NotificationCenter)  layer=-2147483601  360x360 @(16,235)
owner=通知中心(NotificationCenter)  layer=-2147483601  360x180 @(16,55)
owner=访达(Finder)                  layer=-2147483603  1920x1080   (desktop wallpaper)

So the CGWindowList pre-click gate is defeated by any desktop-level system surface, not just the Dock — desktop widgets are a second instance of the same root cause.

Workaround that fully restores clicking on this machine (both steps required)

1. defaults write com.apple.dock autohide -bool true && killall Dock — removes the layer-20 Dock surface once the Dock actually hides.
2. Remove the Notification Center widgets from the desktop.

With both applied, pixel clicks land correctly — verified end-to-end (Calculator: clicked 5, then + 3 =, got 8). Re-showing the Dock or re-adding a desktop widget brings the failure back immediately.

Cross-implementation data point supporting @m13v's AX suggestion

OpenAI Codex's "Computer Use" clicks correctly on this same machine with no Dock/widget changes at all. It uses AXUIElementCopyElementAtPosition for its hit-test, which respects the event-passthrough flags these system surfaces set — consistent with the proposed fix of switching the allowed-app check from CGWindowListCopyWindowInfo to AX hit-testing.

Confirmed still broken on macOS 26.5 (Darwin 25.5.0) / Claude Code desktop app (Cowork) 2.1.177 — CGWindowList probe run at failure time reproduces OP's exact signature. Plus a new data point: the block is intermittent on the same machine with identical settings.

Environment: MacBook Pro (Apple M5), single built-in display 3024x1964 (logical 1512x982), zh-CN locale, Dock autohide OFF (com.apple.dock autohide unset) the entire time, granted app: Microsoft OneNote (tier "full").

Probe (OP's script, trimmed) run seconds after a rejected click:

layer=25 owner=控制中心 sharing=0 (menu-bar extras)
layer=24 owner=Window Server sharing=1 name=Menubar
layer=20 owner=程序坞 sharing=0 bounds=(0,0,1512x982) name=""   <- OP's tracking surface
layer=0  owner=Microsoft OneNote sharing=0 bounds=(162,107,1116x726)
layer=-2147483624 owner=程序坞 sharing=1 name=Wallpaper-E1388E5B-...

At that moment the granted app was frontmost (System Events), its window on the active Space at exactly the frame above (matching the tool's screenshot after the ~1.102 image-to-points scale), and left_click/scroll anywhere inside that frame returned Click at these coordinates would land on "程序坞", which is not in the allowed applications. Keyboard tools kept working throughout (an entire multi-table OneNote document was typed during the block); mouse_move succeeds; open_application reports success but does not recover.

New data point — intermittency with no settings change: on this same machine, same session allowlist, pointer actions worked normally for a ~16-minute stretch in the afternoon (Dock visible, autohide off), then every pointer action was refused in sessions later that evening and again the next morning (probe above taken during the latter), with no reboot, no permission change, and no Dock/WindowManager settings change in between. This corroborates @xwx0807's finding that the layer-20 surface's lifecycle is dynamic (Space-bound): end users experience this as a nondeterministic failure — an agent clicks fine for one session, and hours later nothing clicks.

Two smaller observations that make this hard to debug from the agent side:

• screenshot composites granted apps' windows — and excludes the sharing=0 surface, as OP noted — so the picture always shows a perfectly clickable frontmost app; the error's advice to "take a fresh screenshot" can never surface the blocker. Screenshots even composite granted-app windows that are on an inactive Space, so the image can differ from what the user is actually looking at.
• A screenshot taken during a Space-swipe animation produced a horizontally shifted frame with a wrapped menu bar (two partial menu bars in one image), further misleading mid-diagnosis.

+1 to @m13v's AXUIElementCopyElementAtPosition fix: at the rejected coordinates, the AX hierarchy (via System Events) reports the granted app's window frame containing the point, while CGWindowList resolves the same point to the Dock surface — exactly the divergence that fix targets. Until then, agent-side keyboard-only operation (app shortcuts + typing) is a workable stopgap that doesn't require users to change Dock settings.

(Investigated and written by Claude Code at the user's request; posted from the user's account.)