[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)

Preflight Checklist

• [x] I have searched existing issues — see #42153 for the same symptom, filed 2026-04-01, still open, zero comments/labels/PRs. This report adds the CG window signature, regression timing, a proposed filter rule, and a third-party-interference exclusion.
• [x] This is a single bug report.
• [x] I am using the latest version of Claude Code (2.1.114) and Claude Desktop (1.3109.0).

What's Wrong?

On macOS 26.4 / 26.4.1, every pixel-coordinate click from computer-use (left_click, right_click, double_click, triple_click, computer_batch with any click action) is rejected with:

Click at these coordinates would land on "程序坞", which is not in the allowed applications. Take a fresh screenshot to see the current window layout.

This happens at every coordinate on the display, regardless of:

• which app is frontmost (verified with System Events frontmost=Mail, still blocked);
• which apps are granted (Mail at tier full, still blocked);
• whether Stage Manager is on or off (toggled both ways, no effect);
• whether com.apple.WindowManager HideDesktop / EnableStandardClickToShowDesktop / any Enable*HotKey is toggled;
• whether Dock is respawned (killall Dock re-creates the offending window immediately);
• whether specific third-party overlay apps are quit (tested with Atoll, Ice, superwhisper — no effect).

request_access for "Dock", "程序坞", or com.apple.dock returns not_installed, so the user cannot grant their way out. Keyboard tools (key, type, scroll, hold_key) continue to work. screenshot, request_access, open_application, list_granted_applications, cursor_position all work. Only pixel-coordinate clicks are blocked.

Root cause (verified via CGWindowListCopyWindowInfo)

On macOS 26.4+, Dock.app owns a structural, non-interactive, full-display tracking window at CGWindow layer 20:

kCGWindowOwnerName    = 程序坞              (com.apple.dock, pid N)
kCGWindowNumber       = <fresh every Dock launch>
kCGWindowLayer        = 20                  ← ABOVE layer-0 app windows
kCGWindowBounds       = (0, 0, Wpx × Hpx)   ← covers the entire display
kCGWindowName         = ""                  (no title)
kCGWindowAlpha        = 1
kCGWindowSharingState = 0                   (kCGWindowSharingNone)

The MCP's pre-click gate walks the CG Z-order top-down and attributes the click to whichever app owns the topmost window at that pixel. On 26.4+, every pixel's topmost window is this Dock layer-20 surface, so every click resolves to "Dock" and is refused. The surface is invisible in MCP screenshots because kCGWindowSharingState=0 excludes it from capture — the user sees a normal-looking app while every click errors.

This surface is structural to the macOS 26 Dock, not something created on demand or triggered by a user setting. It's created on every Dock launch (killall Dock respawn test produces the identical window as window #N+1, same layer 20, same sharingState=0, same empty title, same full-display bounds) and persists across all toggle permutations of com.apple.WindowManager I could find. The Dock startup log shows com.apple.dock.fullscreen and com.apple.dock.spaces XPC services activating immediately at launch — this is the canvas those subsystems animate into.

Ruled out — not caused by a third-party app

• vmmap <Dock pid> — no non-Apple dylibs loaded into Dock.
• Dock process env — no DYLD_INSERT_LIBRARIES / DYLD_* injection.
• systemextensionsctl list — only network extensions (Loon, Tailscale, Surge), none UI-touching.
• Enumerating every layer ≥ 1 window with CGWindowList — only system-owned windows (Dock, Window Server Menubar, Control Center, Stage Manager daemon WindowManager) touch the click coordinates; no third-party window does.
• Individually quitting suspected overlay apps (Atoll, Ice, superwhisper) — zero effect on the Dock layer-20 surface.
• Ice uses private CoreMenuExtra APIs for menu-bar management only. CleanMyMac FinderSync touches Finder only. ToDesk/Loon/Surge/Tailscale are network-only. Paste/Easydict/Amphetamine/TG Pro/Immersive Translate are menu-bar floating widgets.

What Should Happen?

Clicks within a granted application's window should succeed. The MCP's pre-click pixel hit-test must not attribute a click to a Dock-owned non-interactive tracking surface on macOS 26.4+.

Error Messages/Logs

Click at these coordinates would land on "程序坞", which is not in the allowed applications. Take a fresh screenshot to see the current window layout.

Reproduces identically for every coordinate on the display, including those provably inside a granted app's bounds per a fresh screenshot call.

Steps to Reproduce

1. On macOS 26.4 or 26.4.1, open Claude Code (or Claude Desktop).
2. Enable the computer-use MCP server.
3. mcp__computer-use__request_access({ apps: ["Mail"], reason: "..." }) → granted at tier full.
4. mcp__computer-use__open_application({ app: "Mail" }) → Mail comes forward.
5. mcp__computer-use__screenshot() → Mail is visible, occupies the full display except the menubar.
6. mcp__computer-use__left_click({ coordinate: [100, 400] }) — coordinates unambiguously inside Mail's window per the screenshot.
7. Observed: error Click at these coordinates would land on "程序坞", which is not in the allowed applications.
8. mcp__computer-use__request_access({ apps: ["com.apple.dock"] }) → not_installed, so no user-side workaround exists.

Independent verification that the hit-test is the cause (run this in any terminal on macOS 26.4+):

// swift /tmp/probe.swift
import Cocoa
let info = CGWindowListCopyWindowInfo(.optionOnScreenOnly, kCGNullWindowID) as? [[String:Any]] ?? []
for w in info {
    let layer = w[kCGWindowLayer as String] as? Int ?? 0
    let owner = w[kCGWindowOwnerName as String] as? String ?? ""
    if layer == 20 && (owner.contains("Dock") || owner.contains("程序坞")) {
        print(w)
    }
}
// → one hit: full-display bounds, sharingState=0, title="", alpha=1

Claude Model

Not applicable — this is a tool-level bug in the computer-use MCP's hit-test gate. Any model that calls left_click hits it.

Is this a regression?

Yes, this worked in a previous version.

Last Working Version

Worked for this user on pre-26.4 macOS builds (macOS 26.3.x / earlier) with earlier Claude Code releases. Broken after upgrading to macOS 26.4.1 on 2026-04-12 (confirmed via system_profiler SPInstallHistoryDataType). The window-server/Dock changes in the 26.4 → 26.4.1 branch are the trigger — the current /System/Library/CoreServices/Dock.app binary mtime is 2026-04-06, consistent with ship in 26.4.x.

Community observation: macOS 26 Tahoe reworked the Dock's in-process window-management stack (the Dock process now hosts WindowManager preferences and the com.apple.dock.fullscreen / com.apple.dock.spaces XPC services) and added new Dock-owned surfaces that did not exist on pre-26.4 builds. The same CG signature (sharingState=0, memoryUsage=2368) on Tahoe windows is independently documented in trycua/cua#870 and trycua/cua#912 — those issues concern screen capture in Tahoe VMs but confirm the same Dock/compositor behavior pattern.

Claude Code Version

2.1.114 (Claude Code) — also reproduces in Claude Desktop 1.3109.0 (both use the same computer-use MCP implementation).

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2 — but this reproduces regardless of terminal, because the bug is in the computer-use MCP's hit-test gate, not in the CLI shell. Also reproduces in Claude Desktop (no terminal involved).

Additional Information

Full environment

• macOS: 26.4.1 (Darwin 25.4.0), Build 25E253, Apple Silicon
• Claude Code CLI: 2.1.114
• Claude Desktop: 1.3109.0
• System install history relevant dates:
• 2025-09-24 — original macOS 26.0 install
• 2026-03-31 — macOS 26.4
• 2026-04-12 — macOS 26.4.1 (current)
• 2026-04-17 17:39 — last reboot
• Dock.app mtime: 2026-04-06 (ships with 26.4.x)
• Stage Manager: off (GloballyEnabled=0, GloballyEnabledEver=1)
• Relevant WindowManager flags tested: HideDesktop=0, EnableStandardClickToShowDesktop=0, all Enable*HotKey defaults
• Hot corners: only wvous-br-corner = 14 (Quick Note)
• Dock autohide: 0 (off), magnification on, Chinese locale (zh_CN)

Proposed fix (MCP-side, ~4 lines)

When walking the CGWindow Z-order top-down to determine the target of a click, skip a window if all of the following hold:

1. kCGWindowOwnerName / kCGWindowOwnerPID resolves to com.apple.dock; AND
2. kCGWindowBounds equals the current display bounds; AND
3. kCGWindowSharingState == kCGWindowSharingNone (value 0); AND
4. kCGWindowName is empty or missing.

This filter is specific enough to not false-match any legitimate Dock click target:

• The Dock strip itself is at a different layer/bounds (small strip at screen edge, not display-sized).
• The Dock's Wallpaper windows are at the most-negative layer and have sharingState=1 (observed: both Dock wallpaper windows on my machine are sharing=1).
• Dock menus (trash, folder stacks) are at different layers and have non-empty window names.

So the filter cleanly excludes only the structural tracking surface.

Alternative fix (more robust)

Replace CG-Z-order hit-testing with AXUIElementCopyElementAtPosition rooted at the frontmost granted app. This resolves click target via the accessibility hierarchy, which reflects the app that will actually receive the click's OS-level mouse event. The accessibility API does not expose the Dock's non-interactive tracking surface as a hit element for a user click, so it is immune to this class of false positive.

Interim workaround for end users blocked by this

• Keyboard navigation only: cmd+F / cmd+K for in-app search, arrows / tab for navigation, return / space to confirm, type for text input. All bypass the pixel hit-test.
• No effective system-side workaround: no user-toggleable macOS setting removes the Dock layer-20 surface on 26.4+.

Cross-references

• #42153 — earlier report of the same symptom on Tahoe, state open, 0 comments, 0 labels, 18 days untriaged. This report supersedes it with a concrete CG signature, regression timing, and a proposed filter rule.
• trycua/cua#870, trycua/cua#912 — independent documentation of the same Tahoe CGWindow signature in a competing Computer Use product; corroborates that this is a macOS 26 change, not a Claude-side regression alone.