[BUG] computer-use left_click/computer_batch clamps Y to ~0 (menu bar) while X stays accurate — macOS 15.7.7, single internal display

Preflight Checklist

• [x] I have searched existing issues. Related-but-distinct reports: #50719, #42153, #82191, #76918 — see "Why this isn't a duplicate" below.
• [x] This is a single bug report.
• [x] I am using the latest version of Claude Code / Claude Desktop.

What's Wrong?

computer-use mouse-click tools (left_click, computer_batch, mouse_move, and manual left_mouse_down+left_mouse_up pairs) land at the correct X but a Y near 0 (the menu-bar row), no matter what Y value is requested. X-only accuracy plus a Y that always resolves to the same tiny band rules out a display-offset or scaling bug — it looks like the Y component is being clamped somewhere in the coordinate pipeline before the click is dispatched.

Evidence

Requested Y values that all landed in the menu bar: 5, 348, 549, 571, 697. Not a constant offset (the deltas from target aren't fixed) and not a scale factor (they don't land proportionally lower) — every one collapses to ~0.

X is unaffected — three independent examples:

• (289, 571) opened the Help menu, which sits at x=289 in the menu bar.
• (255, 549) opened the Window menu, which sits at x=255.
• (255, 697) also opened the Window menu (same x=255), confirming this isn't a one-off.

No hover highlight appears at the intended target either — consistent with the real pointer never being there.

cursor_position is not useful for diagnosing this: it echoes back the coordinate it was asked about rather than reading the actual pointer location, so it can't be used to confirm or deny where the pointer really went.

The server's own pre-click safety check appears to already see the clamped Y: a click aimed at (700, 180) — empty desktop wallpaper, no windows there — was rejected with Click at these coordinates would land on "Notification Center", which is not in the allowed applications. Notification Center's clickable surface only occupies the very top of the screen (menu-bar height), which only makes sense if the check itself evaluated (700, ~0).

Diagnostic: is this Claude-side or system-wide?

To rule out a system-level pointer hijack (e.g. an accessibility tool or driver intercepting CGEvents), I warped the OS pointer directly, bypassing Claude Code entirely:

import CoreGraphics
import Foundation
CGWarpMouseCursorPosition(CGPoint(x: 700, y: 500))
usleep(300_000)
print(CGEvent(source: nil)!.location)

Result: (700.0, 500.0) — exact match. The OS places and reads back the pointer correctly outside of Claude Code. This confirms the bug is in Claude Code's own coordinate handling for computer-use, not a system-wide pointer-interception problem.

Steps to Reproduce

1. Grant computer-use access to any application at "full" tier.
2. Take a screenshot to get current window layout / target coordinates.
3. Call left_click (or computer_batch with a click action) at any coordinate with Y well below the menu bar, e.g. (400, 400).
4. Observe: the click registers in the menu bar (Y≈0) instead of at the requested Y. X is correct.
5. Repeat with mouse_move, then left_mouse_down + left_mouse_up as separate calls — same result on every path.
6. Repro is stable: reproduced 6+ times, including after restarting the app and re-granting access (~6 hours apart).

Expected Behavior

A click requested at (x, y) should land at (x, y) on screen, matching the OS-level behavior confirmed by CGWarpMouseCursorPosition above.

Actual Behavior

X lands correctly; Y is clamped to ~0 (menu-bar row) regardless of the requested value, across every click/move code path computer-use exposes.

Environment

• macOS 15.7.7 (Sequoia), build 24G720
• MacBook Pro 13" 2019, Model Identifier MacBookPro15,4, Intel Core i5, Intel Iris Plus Graphics 645, 2x Thunderbolt 3 ports (T2 chip)
• Single built-in display only, 1440×900, no external display, no display offset
• Screenshots come back at 1389×868 — a uniform downscale of the real resolution (same ratio on both axes), so screenshot scaling itself is not implicated
• Keyboard events (key, type) are unaffected — only pointer Y is wrong

Ruled Out

• Multiple displays / origin offset — only one internal display, no external display ever connected
• Karabiner-Elements — enabled rules are keyboard-only; the built-in trackpad/pointing device is not managed by it
• ELECOM_Mouse_Util — not running (it auto-exits without a supported mouse attached, and none was)
• Logi Options+ — not fully ruled out; could not verify because the systemKeyCombos permission prompt needed to quit it was never approved

Why this isn't a duplicate

• #50719 and #42153: clicks are outright rejected by the Dock layer-20 hit-test gate on macOS 26.4+. This report is different — clicks are accepted and dispatched, they just land at the wrong Y. Also a different OS major version (26.4 vs 15.7.7 here).
• #82191: describes unrelated background apps repeatedly stealing frontmost status during a session, not a coordinate-transform error.
• #76918: clicks/keystrokes are silently dropped with no on-screen effect at all; here every click has an effect, just at the wrong Y.