GitHub Issue

mac.click() silently has no effect on native AppKit apps (Finder, Calculator); AXPress on the same element works

Discovered On Aug 18, 2026

Primary Metric open

## Summary `mac.click()` posts a mouse event that has no effect on native AppKit applications. It fails silently: the call returns a normal pointer dict and raises nothing, but the target application never registers the click. `mac.ax.perform(index, "AXPress")` on the *same element*, in the same process moments later, works correctly. Reproduced on two unrelated native apps (Finder and Calculator). Keyboard input (`mac.key`, `mac.type`) through the same code path works fine, so this appears specific to the `CGEventPostToPid` mouse path rather than to permissions or event posting in general. ## Environment - macOS 26.6.1 (build 25G76), Apple Silicon (arm64) - macos-harness 0.1.2, installed via `uv tool install --python 3.12`, commit `b88e4d7` - Tool venv Python 3.12.12 - `macos-harness doctor`: `accessibility: true`, `screen_recording: true`, `post_events: true` ## Reproduction With Calculator running: ```python import time from AppKit import NSWorkspace, NSApplicationActivateIgnoringOtherApps def display(): st = mac.get_app_state("Calculator", screenshot=False) return [x.get("value") for x in st["nodes"] if x["role"] == "AXStaticText" and x.get("value") is not None] calc = next(a for a in NSWorkspace.sharedWorkspace().runningApplications() if str(a.localizedName() or "") == "Calculator") calc.activateWithOptions_(NSApplicationActivateIgnoringOtherApps) time.sleep(1.0) st = mac.get_app_state("Calculator", screenshot=False) btn = next(x...

View Raw Thread

Developer & User Discourse

fredchu • Aug 19, 2026

Independent reproduction on a different macOS build and a multi-display setup.

## Environment

- macOS **26.5.2 (25F84)**, Apple Silicon (arm64) — the report is on 26.6.1 (25G76), so this is not specific to one build
- macos-harness 0.1.2 @ `b88e4d7`, installed via `uv tool install --python 3.12`
- Tool venv Python 3.12.9
- `macos-harness doctor`: `accessibility: true`, `screen_recording: true`, `post_events: true`
- Three displays, mixed DPI: DELL P2719H 1920x1080 (main), built-in Retina 3456x2234, DELL U2417H 1920x1080

## Ruling out coordinate mapping (relevant to #4)

I tested with the Calculator window on the secondary display (button center at x≈2406) and again after moving it to the main display (x≈154). In both positions `mac.ax.at(cx, cy, coordinate_space="screen")` hit the intended element:

```
hit test -> {'role': 'AXButton', 'description': '7'}
```

The coordinates are correct in global screen space; the mouse event simply has no effect. This appears independent of the mu...

Ryanm218 • Aug 19, 2026

Thanks @fredchu — that reproduction is more rigorous than my original report, and the pixel-diff method is the right call. Two things to add: a retraction of one of my claims, and stronger evidence for the main one.

## Retracting my "keyboard requires frontmost" note

You are right and I was wrong. Re-tested with the target backgrounded for the entire run:

```
frontmost: Google Chrome | calculator backgrounded: True
before background key: ['751']
after background key8: ['7,518'] | frontmost still: Google Chrome
after background typ2: ['75,182']
```

Keyboard delivery to a background app works exactly as documented. My claim came from `cmd+w` failing against a background Finder — but `cmd+w` is window-scoped, and a background Finder has no key window for it to act on. That is a missing target, not a delivery failure. Window-scoped chords still need a key window; digits, text, and app-scoped commands do not. Please disregard that part of the original report.

## Stronger evidence for...

Ryanm218 • Aug 20, 2026

Root cause found, and I have opened #7 with a fix.

Short version: `mac.click()` posts mouse events via `CGEventPostToPid`. AppKit hit-tests mouse events against the window server's pointer state, which that transport bypasses, so they are silently discarded. Keyboard events carry no position, which is exactly why `mac.key`/`mac.type` work over the same `_post` helper — that asymmetry is the bug.

| transport | keyboard | mouse |
| --- | --- | --- |
| `CGEventPostToPid` | works | silently discarded |
| `CGEventPost(kCGHIDEventTap)` | works | works |

Ruled out by direct test: coordinates (AX hit-test at the click point returns the intended element), app not frontmost, the desktop being a special surface, the stationary cursor (warped onto the target, still nothing), event source state (private and HIDSystemState both fail over PID), and a missing preceding `kCGEventMouseMoved`. All four PID variants failed; the HID tap worked first try.

The awkward part is that the working transport m...