[computer-use] Every click blocked — hit-test resolves all coordinates to the Dock (程序坞); survives reboot

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Every computer-use click is blocked. The computer-use MCP rejects all coordinate-based actions (left_click, etc.) with:

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

...even when the coordinate is clearly INSIDE the granted, frontmost app window, and even over empty desktop wallpaper. The server's hit-test resolves EVERY screen coordinate to the macOS Dock ("程序坞"), so no click ever lands. screenshot and mouse_move work fine — only clicks are blocked. computer-use is therefore completely unusable for any click-driven task.

What Should Happen?

A left_click at a coordinate inside the frontmost, granted application window should be delivered to that app (here: Feishu / 飞书). The Dock occupies only the bottom strip of the screen, so a click in the middle of a granted app window must not be hit-tested as landing on the Dock.

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.

Steps to Reproduce

1. request_access(["飞书"]) -> granted, tier "full".
2. open_application "飞书" -> Feishu is frontmost, fully visible, no overlay (confirmed via screenshot).
3. left_click on a coordinate clearly inside the Feishu window (e.g. a top-bar button at ~1038,177).
4. Result: error — the click "would land on 程序坞 (Dock), not in the allowed applications."
5. The SAME error occurs for ANY coordinate, including blank desktop wallpaper (e.g. 60,400).

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.178 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Resets attempted — ALL failed:

• Opened a NEW Claude conversation window -> same error (the new window shares the same stuck computer-use host).
• killall Dock (restart the Dock process) -> same error (the bad state survives a Dock restart, so it is not in the Dock process itself).
• FULL macOS reboot -> same error.
• Tried to allowlist the Dock: request_access(["程序坞","Dock","com.apple.dock"]) -> all returned "notInstalled"; the Dock cannot be added to the allowlist.

Key clue: after the full macOS reboot, request_access returned an IDENTICAL grantedAt timestamp (1782286771769) to before the reboot — suggesting the computer-use host's state did not refresh across the reboot (the host appears to be out-of-process / persisted / decoupled from the controlled Mac).

Environment: Claude desktop app (Cowork) with computer-use MCP (mcp__computer-use__*). macOS 26.5.1 (build 25F80), kernel Darwin 25.5.0, Apple Silicon (arm64). Claude Code 2.1.178. Target app 飞书 (Feishu) granted at tier "full". This is a tool/bridge-layer bug, not model-specific.

Impact: no user-side reset (new window / killall Dock / full reboot) clears it; computer-use is fully blocked for click-driven tasks.