HomeAIAI AgentsCursor Agents Can Now Drive Desktop Apps; Macs Need 2 Permissions

Cursor Agents Can Now Drive Desktop Apps; Macs Need 2 Permissions

Cursor’s AI agents can now click, type and take screenshots inside desktop applications, so they can test the features they build in tools such as Apple’s iOS Simulator. The company announced the feature on 23 October, and it works on Mac and Linux machines that teams run themselves, provided someone switches it on.

“Cursor can now control your computer,” the company said on X at 16:59 BST. “Agents can drive desktop apps like the iOS Simulator to test the features they build.” The post came with a short video of the feature in use.

In brief

  • What’s new: Cursor agents on self-hosted Mac and Linux machines can operate desktop apps, not just write code.
  • Why it matters: An agent can check its own work in a real app, such as an iPhone app running in the simulator.
  • What to watch: On a Mac the agent drives the real signed-in desktop, so access needs careful control.

The feature runs on machines teams control

The detail is in Cursor’s documentation for computer use. It applies to Self-Hosted Machines, Cursor’s option for running its cloud agents on a company’s own computers rather than Cursor’s servers, both on personal machines and on shared team pools. An agent on such a machine can “click, type, take screenshots, and drive applications with a UI”, and can also drive a browser if Chrome or Chromium is installed.

Cursor’s agents on its own managed service already had a version of this. Its capabilities page says each of those agents runs in “its own isolated VM with a full desktop environment”, where it can start apps and click through them. The new step is bringing the same ability to hardware that customers own, which matters for work such as iPhone apps, where the iOS Simulator needs a Mac.

The documentation stresses that it is off by default: “Both features are explicit opt-ins and are never enabled by the server.” An administrator turns it on by starting the worker software with a --computer-use setting.

On a Mac, a person has to approve screen access

On macOS the agent works through a small helper app called Cursor Computer Use, which the command-line tool downloads and installs the first time. It controls the desktop session of whichever user is signed in and running the worker. It needs two macOS privacy permissions: Accessibility, to move the mouse and type, and Screen Recording, to take screenshots.

Cursor says plainly that “the worker doesn’t check or request these for you”, and that its own diagnostic check does not report whether they have been granted. Companies that manage their Macs centrally can pre-approve Accessibility on most macOS versions, though Cursor notes Apple is ending that from macOS 26.2. Screen Recording cannot be pre-approved at all. “A profile can’t allow it. Apple requires a person to approve it,” the documentation says. From macOS 15, Macs also periodically ask the user to confirm the screen-recording permission again.

Cursor warns against workarounds. It says editing the Mac’s privacy database or turning off System Integrity Protection “breaks the protections your Mac relies on and isn’t supported”.

For fleets, Cursor suggests granting the permissions once on a template Mac, checking they work, and copying that disk image to every worker. Machines that restart unattended need automatic login switched on and the display kept awake.

Linux gets an isolated desktop for live viewing

On Linux, the agent uses an X11 display. It can reuse a display that is already running or start its own desktop on machines with no screen attached. Cursor does not install the required system packages itself.

Linux machines also get desktop sharing, which lets authorised colleagues watch the agent’s screen from Cursor or take over the mouse and keyboard. Taking control is the default setting; a watch-only mode is available. Cursor says sharing uses a separate desktop created by the worker, not the machine’s own session, with a “fail-closed input filter” and clipboard transfer blocked. The picture leaves the machine only over the worker’s existing outbound connection, and “no inbound ports open”.

The security burden shifts to whoever runs the machine

This is a useful feature with a clear purpose. Coding agents that can only read and write files have to guess whether a button works; one that can open the simulator and tap through the app can check. That closes a gap that comparisons of AI coding tools have tended to skip over.

But the Mac version gives an agent the run of a real, signed-in desktop. Anything visible on that screen, from email to password prompts, is visible to the agent, and anything it can click it can change. Text an agent reads on screen is also input it may act on, which makes a dedicated machine with nothing else signed in the safer choice. Cursor’s own controls help: the feature is opt-in, a human must approve screen recording on each image, and the Linux sharing desktop is isolated. Yet the documentation also shows where responsibility falls on the customer, from a worker that does not check its own permissions to golden images that carry the grants to every clone and machines left signed in with screens awake.

That contrasts with the direction others are taking. Google, for example, is building microVMs that isolate each agent in hardware. Cursor’s managed agents already work that way; its self-hosted ones are only as contained as the machine they run on. For teams already using Cursor’s Origin code host and agents, the sensible first test is a spare Mac with a fresh user account, not a developer’s own laptop.

Sources

Related stories

Follow @tsnmediahub on X for breaking AI news as it happens.

Follow on X

Share this story

Latest stories

More in this category

Latest stories

Explore the TSN Atlas: Every topic we cover, mapped. Click a bubble to dive in.