Cursor's Computer Use lets agents click through desktop apps on your machine

Agents get hands on the GUI

On October 23, Cursor announced that its agents can now operate desktop applications on the machine a developer actually works on. The feature, called Computer Use, lets an agent interact with GUI software so it can test what it has just built — the announcement's example is an agent that builds a signup screen, opens the iOS Simulator, works through the flow, and then fixes the code based on what rendered.

How it is triggered

According to a walkthrough by Flavio Copes, you invoke the tool by typing @ in an agent conversation and selecting Computer Use from the mention menu. Runtime Wire reports that the agent can also choose it on its own when a task calls for it. The capability ships as an update to Cursor's desktop app, and AlphaSignal notes that Cursor announced no pricing change alongside it.

This is not an entirely new capability for the company. Cursor's documentation describes cloud agents that already run in isolated virtual machines with full desktop environments, where they control a mouse and keyboard. Self-hosted workers running on a user's own Mac or Linux hardware have an opt-in --computer-use flag. The October 23 release extends the same concept to the agent inside the editor itself.

What local actually means

One clarification from AlphaSignal is worth underlining: local refers to the machine being controlled, not to where the model runs. Inference does not move on-device. The agent perceives the screen through screenshots, so anything visible during a task — mail clients, password managers, signed-in browser tabs — should be treated as input to the model.

macOS permissions go to a helper app

On macOS, the feature needs two system permissions: Accessibility, to interact with apps, and Screen Recording, to capture their interfaces, according to Flavio Copes. Both are granted to a separate helper application named Cursor Computer Use rather than to the editor itself — permissions given to a terminal, or even to Cursor, have no effect here.

Cursor's self-hosted documentation adds detail. The helper installs under ~/.cursor/cursor-computer-use/ with the bundle identifier co.anysphere.cursor-computer-use. Screen Recording approvals belong to the macOS user who granted them, and on macOS 15 and later the system may periodically ask that user to re-confirm the grant. The approvals are tied to the helper's code-signing identity, so the app should not be copied, re-signed or rebuilt.

There is also a verification gap. The agent worker debug command confirms the helper is installed but does not report whether permissions are in place. The documented way to check is to run a real task that opens a browser and takes a screenshot, then see whether the image appears in the chat.

Team deployment has limits

For organizations managing Macs with MDM, Cursor ships no ready-made configuration profile. Accessibility can be silently allowed on most macOS versions, but the docs warn that Apple is deprecating silent allow from macOS 26.2. Screen Recording cannot be granted by a profile at all; the documented workaround is AllowStandardUserToSetSystemService, which lets a standard user approve it without an administrator password.

Linux self-hosted workers are a different setup entirely: they drive an X11 display and require xdotool, ffmpeg and X11 utilities to be installed manually. Desktop sharing, where a person can watch or take over an agent's desktop, is Linux-only, runs on an isolated desktop created by the worker, and blocks clipboard transfer.

Documentation has not caught up

The release appears to have arrived ahead of its paperwork. When the dev.to write-up by Gabriel Anhaia was published, the newest entry in Cursor's changelog was dated October 16, and the documented setup steps concerned self-hosted workers. ExplainX reported that no permission or approval behaviour for the IDE version had been documented at publication, and that supported operating systems were not stated.

The feature also lands after visible demand. A July 17 forum request asked for local desktop control with opt-in permission and an audit of actions, and as recently as October 6 a Cursor staff member replied that it was still being explored with no timeline to share. Questions that remain open include whether the agent confirms before acting in a new app, whether it can be restricted to a list of apps, how long screenshots are retained, and whether Windows is supported.

Why it matters

This closes a loop that coding agents have historically left open. An agent that can tap through the interface it just built can verify its own work before a human ever looks at it, turning the usual cycle of writing code and handing testing to a person into something closer to end-to-end delivery.

The trade-off is that verification now happens on the developer's real, logged-in session rather than a disposable cloud VM, and the safeguard of record is a pair of macOS permissions handed to a helper app. Until Cursor documents approval flows, app restrictions and screenshot retention, teams will have to treat Computer Use as powerful but under-specified. The dev.to write-up's practical advice — a separate macOS user account for agent work, closing anything you would not paste into a prompt, and revoking the helper's permissions between sessions — is sensible in the meantime.