Nicheloom

Market intelligence for builders — see what's gaining traction before it's crowded.

Drive any macOS app in the background without stealing the cursor

Details

External ID
47936312
Source
HN
Company
—
Product
Drive any macOS app in the background without stealing the cursor
Website domain
github.com
Launched
April 28, 2026
Cohort
—
Upvotes
192
Upvotes percentile
0.9601542416452442
Tags
—
Fetched at
Sept. 7, 2026, 9:26 p.m.
Updated at
Sept. 7, 2026, 9:26 p.m.

Description

Hi HN, Francesco from Cua here. I hacked this project together last weekend, inspired by the Codex Computer-Use release and lessons learned from deploying GUI-operating agents for our customers.The main problem: when a UI automation process controls a desktop app today, it usually takes over the human’s session. Your cursor moves, keyboard focus gets stolen, windows jump to the front, and you have to stop working until the agent is done. That is why we have historically avoided encouraging users to run these processes directly on their host machine, instead relying on VMs or GUI containers for concurrency and background execution.But computer-use - the tools we give agents to operate computers like humans - does not scale cleanly that way. As models get smarter, agents need to share hosts safely, run in the background, and avoid collisions with the human or other agents using the same machine.We realized macOS has no first-class API for "drive this app without touching the cursor". CGEventPost routes through the hardware input stream, so it moves your cursor. CGEvent.postToPid avoids the cursor warp, but Chromium treats those events as untrusted and silently drops clicks at the renderer boundary. Activating the target app first raises the window and pulls focus, defeating the point of background execution.Cua Driver is our attempt at a real fix: a background computer-use driver for macOS that lets an agent click, type, scroll, and read native apps while your cursor, frontmost app, and Space stay where they are. The default interface is a CLI, so it is easy to script or call from any coding agent shell.Try it on macOS 14+:/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/trycua/cua/main/libs/cua-d...)"The first internal use case was delegated demo recording. We ask Claude Code to drive an app while 'cua-driver recording start' captures the trajectory, screenshots, actions, and click markers. The result is an agent-generated product demo, Screen Studio inspired.Other things we have used it for:- Replacing Vercel’s agent-browser and other browser-use CLIs. With Claude Code and Cua Driver, you do not need Chrome DevTools Protocol at all.- A dev-loop QA agent that reproduces a visual bug, edits code, rebuilds, and verifies the UI while my editor stays frontmost.- Personal-assistant flows that use iMessage from Claude Code, Hermes, or other general-purpose agent CLIs.- Pulling visual context from Chrome, Figma, Preview, or YouTube windows I am not looking at, without relying on their APIs.What made this harder than expected:- CGEventPost warps the cursor because it goes through the HID stream.- CGEvent.postToPid does not warp the cursor, but Chromium drops it at the renderer IPC boundary.- Activating the target first raises the window and can drag you across Spaces.- Electron apps stop keeping useful AX trees alive when windows are occluded without a private remote-aware SPI.The unlock was SkyLight. SLEventPostToPid is a sibling of the public per-PID call, but it travels through a WindowServer channel Chromium accepts as trusted. Pair it with yabai’s focus-without-raise pattern, plus an off-screen primer click at (-1, -1), and the click lands without the window ever raising.One thing we learned: the right addressing mode depends on the app. Native macOS apps usually have rich AX trees, Chromium-family apps often need a hybrid of AX and screenshots, and apps like Blender or CAD tools may expose almost no useful AX surface. The mistake is defaulting to pixels everywhere - or defaulting to AX everywhere.Long technical writeup: https://github.com/trycua/cua/blob/main/blog/inside-macos-wi...I would like feedback from people building Mac automation, agent harnesses, or accessibility tooling. If it breaks on an macOS app you care about, that is useful data for us.

Enrichment

Theme
cross-device control and OS utilities
Vertical
Horizontal
Function
Dev tools
Audience
Developer
AI stance
Not AI
Project type
Hobby / open-source project
Normalized one-liner
background automation for macos applications
Manually corrected
False

Could you build this?

Partial Controlling background macOS windows without cursor stealing requires reverse-engineering private macOS Accessibility, CoreGraphics, and WindowServer APIs.

What it would actually take: Requires native Swift/Objective-C code hooking into the macOS Accessibility API (AXUIElement) and CGEvent post systems directed specifically to window/process targets rather than the global hardware cursor. The hard part is bypassing macOS WindowServer limitations where synthetic events often steal focus or fail for non-standard Cocoa/Metal views without deep OS internals expertise.

Discussion

20 comments analyzed.

Competitors mentioned: PostHog (session replay/telemetry), Tart (VM for app control), RemoteApp (Windows)

Concerns raised: Privacy/telemetry collection without explicit opt-in consent, Default-enabled telemetry tracking user behavior and inputs, Session stealing and cursor interference with multi-tasking, Unclear data collection practices and misrepresentation, VM approach feels overkill for solo development

Feature requests: Background driver option for agent control (middle ground between VM and direct access), Agents verify their own code changes in real applications, Agents record product demos automatically, CLI and API generation by reverse-implementing GUI

Competitors

Other products that read as similar to this one — 144 launches clear the similarity bar, closest 8 shown.

Attention rank: #10 of 145 (itself plus its competitors, highest first — normalized so YC and Product Hunt are compared fairly).

Launched 181 days after the earliest competitor.

Other launches for this product

Same idea, different domain

Nobody's really built a dev tools tool for Sales yet.