SaaS Metrics
GitHub Issue
mac.click() silently has no effect on native AppKit apps (Finder, Calculator); AXPress on the same element works
## 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
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...
## 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...
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...
## 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...