Can MacOS Actually Have Two Mouse Cursors Simultaneously?

In OpenAI’s Codex Computer Use release on April 16th, there was a striking scene: two mouse pointers existing simultaneously on the screen — one controlled by the user themselves, and the other a floating cursor belonging to the AI agent. It can click windows, type text in the background, without disrupting your normal computer use at all.

Two Mouse Pointers Simultaneously

Two Mouse Pointers Simultaneously

Actually, that floating cursor is just a visual trick; technically, there’s no need to actually draw a pointer. What really matters is how background clicks take effect — this article explains the underlying principles: from the basic capabilities of the Accessibility API, to directly posting events to background windows using CGEvent, and the most critical step — “tricking” macOS’s window system into making a background window enter an active state.

Before diving into details, I must especially mention a very important reference: the CUA driver from the CUA team. This article was published very early, roughly a week after Codex Computer Use came out, and initially replicated a similar background computer use setup. However, over the past month, I’ve gathered more information and also discovered some errors in that article, as well as some missing key details — such as their heavy reliance on private SkyLight.framework APIs. After testing, I found there are simpler and more stable solutions.

First, a disclaimer: This approach relies on very low-level principles of the macOS window system, possibly even bugs. Many things remain unknown, and some techniques work for certain apps but fail for others.

The relevant implementations are all open-sourced alongside OpenBridge in kwwk-computer-use-core, including the full logic for reading windows, clicking, and keyboard input in the background.

If you want to experience the agent equipped with this computer use system, you can join the Bridge waiting list: https://bridge.surf/

Computer Use in Bridge

Computer Use in Bridge

First: Accessibility as the Workhorse, But Insufficient

For computer use, the first instinct for most people is to simulate mouse and keyboard actions by bringing the target window to the foreground and clicking. Actually, macOS has the built-in Accessibility API (commonly called AX). After obtaining permissions, you can directly read the UI of any app and also manipulate some controls — it works in the background, doesn’t require the target app to be frontmost, and doesn’t necessarily move the system mouse.

Specifically, what you can do:

• Read: Enumerate windows, traverse the AX tree, get role, title, frame, value, etc.
• Write: Native AppKit controls allow direct actions — clicking buttons via AXPress, changing text fields via setValue, scrolling with AXIncrement / AXDecrement.

These actions are sent to the app for processing; the window doesn’t need to be the key window, and the cursor doesn’t need to move. For native apps like TextEdit, Finder, and System Settings, the agent can read the AX tree, find the corresponding element, and invoke actions — often completing the entire task chain.

But AX doesn’t cover all scenarios:

• For Chrome and Electron in the background, the AX tree is often incomplete, and AXPress is unreliable, requiring fallback to simulated mouse clicks.
• Keyboard character-by-character input also relies on postToPid to send key events.

These are where the window system tricks come in. For native apps, Accessibility is the workhorse; the magic later fills the gaps where AX fails.

Using CGEvent.postToPid to Directly Dispatch Events to Windows

When AX fails, the next step is to use CGEvent directly to send mouse and keyboard events to the target window. The core API is postToPid — not via the global HID channel, but directly into the event queue of the specified process.

The SLEventPostToPid mentioned in the CUA driver article is actually not the focus; in practice, CGEvent.postToPid is sufficient.

The steps roughly involve:

• Obtain the target pid, windowNumber, and control coordinates.
• Construct mouse/keyboard events, fill in eventTargetUnixProcessID and window-related fields so the system knows which window to send to.
• Call postToPid to dispatch the event; a single click consists of a down and up event.

A left-click is ultimately composed of two events:

The specific implementation can be found in BackgroundInputDispatcher.swift.

Activation of Background Windows: Tricking the Window into Thinking It’s Active

postToPid can send events to background windows, but many apps, before receiving a click, check whether their window is “alive” — is it the key window, main window, does it have focus? Background windows don’t meet these conditions by default, and events sent to them might be ignored.

Chrome and Electron have an additional problem: when the window is not frontmost, they often don’t expose a complete AX tree, so the agent can’t even read what to click.

So we need to trick it: make the target window enter an “active” state internally, but without actually bringing it to the front of the screen, so the app the user is using remains frontmost.

Apple Music window activated in the background

Apple Music window activated in the background

In the image, the traffic light 🚥 in the top-left corner of the Apple Music window and the Chrome window are both lit, indicating that both apps consider themselves active. Normally, the traffic light for a background window is gray — this shows we successfully tricked Apple Music into entering an active state while in the background.

Activation is just a click on the window

The approach is straightforward: send a postToPid click (center primer) to the target window. After the app receives a legitimate mouse down/up, it internally goes through the normal window activation process — the window becomes the key window, starts accepting input, and Chrome/Electron expose the AX tree. This is essentially the same as when a user actually clicks.

The difference comes after the click. Normally, this click would cause macOS to bring the target app to the front, and the user’s current app would be deactivated. What we want is the first half (process-level activation) but not the second half (visual frontmost switch).

We choose coordinates at the exact center of the window; this click won’t trigger any application behavior, only window activation.

This exploits a macOS feature: the first click received when a window is not active typically doesn’t trigger real actions; instead, it first goes through the activation flow. You can choose any click location, but avoid the top-left corner — the traffic lights can respond even in the inactive state, inadvertently triggering close/minimize.

How to intercept focus messages

When an application receives the click, it sends a deactivation to the frontmost app and an activation to the target app — thus switching the foreground. The solution is to install an event tap on the relevant processes, intercepting the focus message before it reaches the app. So the order is crucial: install the tap first, then send the activation click.

Implementation uses CGEvent.tapCreateForPid — installs a per-process event tap for a given pid, placed at the head of the process’s event queue, passing through the callback before the app sees it. This is different from a global HID tap. This logic is encapsulated in BackgroundActivationSession in the code.

BackgroundActivationSession.start installs two taps:

• previous: the pid of the current frontmost app (the one the user is using)
• target: the pid of the background app the agent wants to manipulate

Registration uses CGEventMask.max to listen for all event types, then narrows down in the callback. Focus messages don’t have a stable public CGEventType; names may vary across macOS versions, so we rely on raw values: 13, 19, 20.

The rule is simple — drop focus messages intended for the previous app (return nil), and allow the target’s activation:

Once the taps are installed, actual activation proceeds in two steps:

Step 1: appKitDefined primer

Send an NSEvent.otherEvent(type: appKitDefined, subtype: 1) to the target pid. According to Apple’s public header files, subtype 1 corresponds to applicationActivated, which is an internal AppKit app activation event.

Key points about this event:

• It’s sent via postToPid directly into the target process’s event queue, bypassing WindowServer’s normal frontmost routing.
• The event carries a windowNumber and writes fields 51/58 (setWindowAddressingFields) so AppKit knows which window it relates to.
• Effectively, it’s like telling the target app “you should enter active state” ahead of time, paving the way for the center primer.

At the end, we send subtype 2 (applicationDeactivated) to return the target app to background state. The exact handler path is not publicly documented by Apple; it’s an internally effective mechanism discovered through testing.

Step 2: Center primer

Then, send a postToPid click at the exact center of the window — this is the “click the window” step described above.

A complete operation:

1. Create BackgroundActivationSession, first install the event tap.
2. activateWindow: appKitDefined primer + center primer.
3. Execute the real click/type/scroll action.
4. Keep the tap running until the session ends, preventing subsequent operations from stealing focus again.

If the target app is already frontmost or has already been activated by us, the activation flow is unnecessary. For this, I also wrote FrontmostApplicationMonitor to track frontmost switches — whether the user switches windows manually or the agent operates in the background, state remains consistent. See BackgroundActivationSession.swift and ComputerUseSession.swift for details.

In the CUA driver article, private SkyLight APIs were used for background activation, but I found them unstable in practice. This appKitDefined primer + center primer approach has been very stable in my testing, working for every app I tried.

Through the steps above, we successfully trick the window into thinking it is active, enabling clicks, input, etc. in the background.

In the next article, I’ll discuss another important part of this computer use system: how to build an agent-friendly interface (harness) that allows the agent to truly use the computer effectively.