Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [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) [3 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#50719•Fetched 2026-04-20 12:14:57
View on GitHub
Comments
3
Participants
2
Timeline
11
Reactions
0
Author
alexcz-a11yalexcz-a11y
Participants
alexcz-a11yalexcz-a11ym13vm13v
Timeline (top)
labeled ×5commented ×3cross-referenced ×1mentioned ×1

Error Message

Error Messages/Logs

  1. Observed: error Click at these coordinates would land on "程序坞", which is not in the allowed applications.

Root Cause

Root cause (verified via CGWindowListCopyWindowInfo)

Fix Action

Fix / Workaround

  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.

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+.

Code Example

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)

---

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

---

// 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
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • 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.
  • This is a single bug report.
  • 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.

extent analysis

TL;DR

The most likely fix for the issue is to modify the computer-use MCP's hit-test gate to skip the Dock-owned non-interactive tracking surface on macOS 26.4+ by applying a filter rule or replacing CG-Z-order hit-testing with AXUIElementCopyElementAtPosition.

Guidance

  • The issue is caused by a structural, non-interactive, full-display tracking window owned by the Dock at CGWindow layer 20, which is introduced in macOS 26.4+.
  • To fix the issue, the computer-use MCP's hit-test gate needs to be modified to skip this window when determining the target of a click.
  • A proposed filter rule can be applied to skip the window if it meets certain conditions, such as being owned by com.apple.dock, having a kCGWindowBounds equal to the current display bounds, kCGWindowSharingState equal to kCGWindowSharingNone, and an empty or missing kCGWindowName.
  • An alternative fix is to replace CG-Z-order hit-testing with AXUIElementCopyElementAtPosition rooted at the frontmost granted app, which resolves click target via the accessibility hierarchy.

Example

// Example filter rule in Swift
let filterRule: ([String: Any]) -> Bool = { window in
    guard let owner = window[kCGWindowOwnerName as String] as? String,
          let bounds = window[kCGWindowBounds as String] as? String,
          let sharingState = window[kCGWindowSharingState as String] as? Int,
          let name = window[kCGWindowName as String] as? String else {
        return false
    }
    return owner.contains("Dock") && bounds == "full-display" && sharingState == 0 && name.isEmpty
}

// Example usage
let windows = CGWindowListCopyWindowInfo(.optionOnScreenOnly, kCGNullWindowID) as? [[String: Any]] ?? []
for window in windows {
    if filterRule(window) {
        // Skip this window
        continue
    }
    // Process the window
}

Notes

  • The issue is specific to macOS 26.4+ and is caused by a change in the Dock's window management stack.
  • The proposed filter rule is specific enough to not false-match any legitimate Dock click target.
  • The alternative fix using AXUIElementCopyElementAtPosition is more robust and immune to this class of false positives.

Recommendation

Apply the proposed filter rule or replace CG-Z-order hit-testing with AXUIElementCopyElementAtPosition to fix the issue. The filter rule is a simpler solution, but the alternative fix is more robust and future-proof.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ISR setup#authentication setup#request error#file not found

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [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) [3 comments, 2 participants]