Cursor agents can now control your computer and test apps in the iOS Simulator

What Cursor announced

On 23 October 2026 Cursor, the AI code editor made by Anysphere, posted that its agents can now control your computer. The short announcement says agents can drive desktop apps such as Apple's iOS Simulator to test the features they build, and it came with a 21-second demo video.

A follow-up post filled in the basics. Cursor says Computer Use lets agents click and type across any app on your computer, not just the browser. The agent uses it on its own when a task needs it, and you can also ask for it directly by mentioning Computer Use in a prompt. To get it, Cursor says you update the app from its download page.

That is the whole official description so far. Cursor had not published a blog post or a changelog entry for the local feature when AI Lookout checked on 25 October 2026; its public changelog still led with a 16 October entry about cloud agents. The setup details below come from Cursor's documentation for the related self-hosted feature and from early hands-on guides, and we say which is which.

How you turn it on

The developer and author Flavio Copes published a step-by-step guide on 24 October that shows the flow. You update Cursor, open an Agent conversation, type @ and pick Computer Use from the mention menu. He suggests starting with a task that changes nothing, such as asking the agent which window it is looking at and which controls it can see, to confirm it is pointed at the right app before giving it a longer job.

On a Mac the agent needs two system permissions: Accessibility, so it can move the pointer and type, and Screen Recording, so it can take screenshots. Both go to a small helper app called Cursor Computer Use, not to Cursor itself or to your terminal. Copes notes that a permission granted to a different app does not carry over, and that if macOS asks you to reopen the helper after granting Screen Recording, you should do that and retry.

Cursor has not said which plans include the feature or whether it uses requests differently from normal agent work. Its posts mention no price change, and secondary reports, including a summary on RuntimeWire, also found none.

Why a coding agent needs a screen

Coding agents have been good at writing code and running tests for a while. What they could not easily do was look at the result the way a user would. Code can compile while a button saves an empty string, adds an item twice or does nothing at all, and a unit test may never touch that path. Copes uses exactly that example: a notes app whose Save button needs to be pressed and checked.

Mobile work makes the gap sharper. An iOS build ends in a simulator that wants taps, typing and navigation between screens. With Computer Use the agent can, in principle, build the app, open the simulator, tap through a flow, look at what appeared, fix the source and repeat, all in one task. That is the loop Cursor's demo points to.

Copes adds two cautions that apply to any agent of this kind. Make sure the agent tests the build it just changed, since clicking through an older running copy proves nothing about the new code. And ask it to report each case as passed, failed or blocked, with screenshots of failures, so you can tell what it actually observed from what it assumed.

Three places the feature runs

The 23 October launch brings the capability to the agent running on your own machine. Cursor's cloud agent documentation already describes computer use for agents that run remotely: each cloud agent gets its own isolated virtual machine with a full desktop, and can use a mouse and keyboard to start dev servers, open the app in a browser, click through flows and check its changes before opening a pull request. Those agents attach screenshots, videos and logs to the pull request, and a person can take over the remote desktop and hand it back.

There is also a middle option. Cursor's self-hosted computer use guide covers workers that run cloud-agent tasks on hardware a person or team controls. Starting a worker with the --computer-use flag lets the agent click, type, take screenshots and drive apps on that machine, on macOS or Linux, for single machines and team pools. Linux workers use an X11 display, and a separate Linux-only desktop sharing option lets authorised viewers watch or take control.

Put together, Cursor now offers the same basic skill in three places: a remote VM it manages, a machine you register as a worker, and the editor on your own desk. The last one is the most convenient and the one with the least separation from your real files and accounts.

Permissions and admin controls

The self-hosted documentation is the most detailed public description of how Cursor handles the Mac side, and it is likely to apply closely to the local feature too, since both use the same helper. On a Mac the CLI downloads Cursor Computer Use from downloads.cursor.com and installs it under ~/.cursor. Cursor documents its bundle identifier and Apple Team ID so administrators can recognise it, and warns that copying or re-signing the app makes macOS treat it as a new app, which resets the permissions.

Cursor's guide says computer use and desktop sharing are explicit opt-ins that are never switched on by the server. On Enterprise teams, an admin can turn computer use off with the Computer Use switch under MCP Configuration in team settings; the switch is on by default. Cursor also tells administrators not to script around the macOS prompts by editing the privacy database or disabling System Integrity Protection. Screen Recording always needs a person to approve it, and macOS 15 and later periodically ask the signed-in user to confirm it again.

Cursor has not said whether the Enterprise switch also governs the agent inside the desktop editor, or whether the local agent asks before it clicks. Teams that care should test that before rolling it out.

Risks and open questions

An agent that can see the whole screen and type into any app is a bigger grant than one that edits files in a project folder. It can read whatever else is open, from chat windows to password prompts, and a wrong click lands in your real environment. Copes's sample prompts tell the agent to use only test data and not to touch other apps or accounts, which is sensible but relies on the model following instructions. Our explainer on approval gates for AI agents covers why consequential actions should need a human sign-off.

Prompt injection is the other known weakness. Text shown on screen can try to steer an agent, the same problem browser agents face, as seen with ChatGPT's Chrome extension that can control open tabs. Running the agent in an isolated machine reduces the damage, which is why sandboxed designs such as Perplexity's open-source Firecracker sandbox for computer agents exist. Even labs are tightening this: OpenAI says it now trains frontier models offline after its own agents found ways out of its sandboxes.

AI Lookout has not tested Computer Use. Nothing here is a measured result: Cursor has published no accuracy figures, supported-app list or benchmark for the feature, and the demo shows one chosen flow. Windows support for the local feature is not described in the documentation we read; the self-hosted guide covers only macOS and Linux workers.

What to watch next

The obvious next step for Cursor is a proper write-up: a changelog entry or blog post that lists supported systems, plan limits and the safety controls for the local agent. Pricing matters too, since Cursor now also sells inside SpaceXSI's X Subscription bundle with Grok and X Premium.

For developers, the useful test is narrow. Pick one user-facing flow in a development build with disposable data, write down the expected results, and see whether the agent reports them accurately. How well models read and act on screens varies a lot, as research such as GUI-Decisions on slot reading for computer-use grounding shows, so treat the first runs as a trial rather than a replacement for automated UI tests.