browser-use/macos-harness

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

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

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