Cursor Computer Use: Agents That Test What They Build

Cursor posted a short announcement on X on October 23: "Cursor can now control your computer." Agents can now drive desktop apps like the iOS Simulator to test the features they build. I use Cursor every day for PHP, WordPress and Next.js work, so this one got my attention right away. It goes after the slowest part of working with an agent: checking that the code it wrote actually works.

I haven't tried it yet. This is a first look at what Cursor actually announced, what it hasn't said, and how I plan to put it to work.

In a follow-up post, Cursor says Computer Use lets agents "click and type across any app on your computer, not just the browser." Cursor uses it on its own when a task needs it, and you can also ask for it by @-mentioning Computer Use in your prompt. To try it, you update Cursor.

The 21-second demo video is worth a watch. Someone types "@Computer Use add the ability to favorite trails and demo it" into an agent pointed at This Mac, in a hiking app project. The agent edits the app, builds it, opens it in the iPhone Simulator, scrolls the trail list and taps the heart icon. While it works, a small "Cursor is using Simulator" badge with a stop button sits at the bottom of the screen. Build the feature, then go use it, in one prompt.

Cursor agents could already use a computer, just not yours. Since February, cloud agents have run in their own virtual machines with a full desktop, and they can start dev servers, click through UI flows and record their work before opening a pull request. Teams running their own machines could also turn on computer use for self-hosted workers on macOS and Linux. And the agent in the editor has had a built-in browser for web pages, with console logs and network traffic.

The new part is the agent in your local Cursor reaching the desktop apps on your own machine. Simulators, desktop clients and settings windows are now in reach, not just a browser tab or a remote VM.

The handoff between "the code is written" and "I've confirmed it works" is where a lot of the back-and-forth happens when I work with an agent. An agent can write a tidy WordPress settings page quickly, and then I'm the one clicking through wp-admin to make sure the save button actually saves. An agent that can check its own work before it tells me it's done is a real step up, not a gimmick.

It's also just fun to watch an agent read a screenshot, find a heart icon and tap it.

Here's where I'll point it first, starting on throwaway local environments:

• WordPress admin flows. Plugin settings screens, custom post type editors and WooCommerce checkout on a local install. A lot of that is browser work the built-in browser already handles. Computer Use helps with the rest: a desktop database client to confirm a row changed, or a mail catcher app to check that a notification email actually went out.
• Next.js apps. Asking the agent to run the dev server, walk the new page and check it at a couple of window sizes before it hands the work back.
• Mobile work. The iOS Simulator is Cursor's headline example. If a client project ever has an app attached, the agent can tap through a build before I pick up a phone.

My rule going in: the agent's demo is evidence, not a sign-off. I'll still read the diff, and I'll still click through anything that touches money, logins or customer data myself.

An agent that can click and type in any app on your computer can also click the wrong thing in any app on your computer. Cursor's short announcement doesn't cover local permissions, so I'm going by what its self-hosted worker docs say about the same capability. There, computer use is an explicit opt-in. On macOS it runs through a helper app that needs Accessibility (to move the mouse and type) and Screen Recording (to take screenshots). That's a useful reminder of what you're granting: the agent sees your screen and drives your input.

What I'll do until I know more:

• Close password managers, email and banking tabs before I let an agent drive the desktop. Anything on screen can end up in a screenshot.
• Test against local or staging sites, never a live client admin.
• Watch the first few runs instead of walking away, and keep that stop button in mind.
• Treat "it worked in the demo" as a starting point. UI tests that pass because the agent clicked the right thing once aren't the same as a test suite.

Cursor's post is short, and as of this writing its changelog and docs don't have an entry for the local feature. So I can't tell you yet which operating systems it supports beyond the Mac shown in the demo, which plans or models it's on, or whether there are usage limits. I'll update this post when Cursor publishes the details.

Agents that test what they build is the direction I've been waiting for. The less time I spend clicking through a feature to confirm the basics, the more time I have for the parts of a project that need judgment. I'll be trying it on a local WordPress install and a Next.js project first, and I'll write up what holds up and what doesn't.

If you're curious what agent-assisted testing could look like on your site or app, let's talk.

• Cursor on X, "Cursor can now control your computer" (Oct 23, 2026), with demo video
• Cursor on X, follow-up on how Computer Use works and how to get it (Oct 23, 2026)
• Cursor download page
• Cursor blog, "Cursor agents can now control their own computers" (Feb 24, 2026)
• Cursor Docs, Cloud Agent capabilities: Computer use
• Cursor Docs, Computer use and desktop sharing (self-hosted workers)
• Cursor Docs, Browser tool
• Cursor changelog
• Cursor on X, "New in Cursor design mode: Annotate" (Oct 27, 2026)
• Cursor Docs, Design Mode
• Cursor release notes (3.25, Oct 14 and 3.27, Oct 22, 2026: Annotate fixes and responsive design mode presets)