# How to use Cursor Computer Use

> Use Cursor Computer Use to test desktop apps and iOS Simulator flows, reproduce UI bugs, and verify fixes with clear prompts and expected results.

Author: [Flavio Copes](https://flaviocopes.com/about/) | Published: 2026-10-24 | Topics: [AI](https://flaviocopes.com/tags/ai/) | Canonical: https://flaviocopes.com/cursor-computer-use/

Cursor can click and type inside desktop apps. You can ask an agent to build a feature, open the application, and test the feature through its interface.

That includes the iOS Simulator, which Cursor shows in its [Computer Use announcement](https://x.com/cursor_ai/status/2113661506634305834).

Think about a button that saves a note. The code can compile while the button saves an empty string, adds the note twice, or does nothing. Asking the agent to enter a note and press the button gives it a way to discover those problems.

Let's walk through how to ask for that, using a small notes app as our example.

The prompts below are a workflow you can try with your own project. They aren't results from a completed test run.

## What Computer Use does

Computer Use gives the agent access to a graphical interface. It can inspect what is on screen, click controls, and type into fields.

Cursor says the agent can choose it when a task needs it. You can also request it explicitly by [mentioning Computer Use in your prompt](https://x.com/cursor_ai/status/2113661518780998003).

The useful part is combining this with the tools the agent already has. It can read the source, change a file, build the application, then interact with the result.

For example, we want to check whether a note survives reopening the app:

```mermaid
flowchart TD
  accTitle: Verify that a note survives reopening the app
  accDescr: Cursor enters a note and saves it, reopens the app, then checks whether the note is still there. A missing note leads to a source fix and another test.
  A[Enter a test note] --> B[Press Save]
  B --> C[Reopen the app]
  C --> D{Is the note still there?}
  D -->|Yes| E[Report the observed result]
  D -->|No| F[Inspect and fix the source]
  F --> G[Build the changed app]
  G --> A
```

A screenshot after pressing Save only proves what appeared at that moment. Reopening the app checks whether the save persisted.

## Update Cursor and select Computer Use

Start by updating Cursor from the [official download page](https://cursor.com/download), then open the project you want to work on.

Use an Agent conversation. Type `@` in the prompt field and select **Computer Use** from the mention menu.

In the examples below, `@Computer Use` represents that selected mention. Pick it from the menu when composing your request.

Start with a small task that doesn't change anything:

```text
@Computer Use

Inspect the notes app that is already open.
Tell me which window you are looking at and what controls are visible.
Do not edit the source or interact with the app yet.
```

This checks that the agent can see the intended application before you give it a longer job.

If Computer Use is missing from the menu, confirm that Cursor is updated. If it is still unavailable, stop at that point and check Cursor's current availability information. Typing the name into an ordinary message doesn't prove that the tools are available.

### Allow the macOS permissions

On macOS, Computer Use needs **Accessibility** to interact with apps and **Screen Recording** to capture their interfaces.

Follow the **Enable Computer Use** window when Cursor shows it. If you need to check manually, open **System Settings → Privacy & Security** and find the relevant permission sections.

Grant the permissions to **Cursor Computer Use**, the helper named in the request. Granting a permission to your terminal doesn't grant it to a different app.

If macOS asks you to reopen the helper, follow that instruction, then retry the small inspection task.

## Choose a small flow to test

For a first attempt, use a development copy of your app with disposable data.

Our notes app needs a text field, a Save button, and a list of saved notes. If you already have a project with a similar form, use that. The feature itself is less important than having an outcome you can check.

For an iOS app, prepare Xcode and a Simulator with your development build installed. Getting Computer Use working and getting an unfamiliar Xcode project to build are separate problems. Start from an app you can already launch.

If you're new to the UI code, the free [SwiftUI course](https://flaviocopes.com/courses/swiftui/) covers fields, buttons, and state.

Write down the expected behavior before sending the task:

| Action | Expected result |
|---|---|
| Save `Buy coffee` | One note appears with that text |
| Save an empty field | No empty note is added |
| Save only spaces | No blank note is added |
| Reopen the app | The saved note is still there |

This gives the agent something concrete to compare with what it sees.

Only include persistence in the test if your app is meant to support it. An in-memory demo losing its state on restart isn't a persistence bug.

## Ask Cursor to use the app

Give the agent the application name and the exact steps. A request like “test everything” leaves too much room for interpretation.

Try this:

```text
@Computer Use

Test the development notes app in iOS Simulator.
Use the Simulator that is already open.

Enter Buy coffee and press Save.
Check that exactly one note appears with that text.
Then try saving an empty field and a field containing only spaces.
Neither should add a note.

Do not edit code yet. Report what you observed for each case,
and include a screenshot of any failure.
Use only test data. Do not interact with other apps or accounts.
```

Replace the Simulator reference with your Mac app's name if you're testing a desktop application.

The first run is about observing the behavior. You want to know which action failed and what happened afterward, so the next request can target that problem.

For example, “blank note appears after saving spaces” is useful. “There may be a validation issue” is too vague to guide a fix.

## Fix a failure and repeat the same steps

Suppose the app accepts a field containing only spaces.

Now ask Cursor to inspect the source and fix that specific behavior:

```text
Fix the whitespace-only note bug you reproduced.
Keep the change focused on note validation.
Preserve the text of valid notes.

Run the relevant tests and build the app.
Then use Computer Use on the changed build to repeat the same cases:
Buy coffee, an empty field, and a field containing only spaces.

Report the observed result of each case.
If the changed build cannot be launched, report that blocker.
```

Notice the requirement to test the **changed build**. Clicking through an older running copy tells you nothing about the code the agent just edited.

If the app persists notes, add a separate check:

```text
Save a note named Check persistence.
Close and reopen this development app, then check whether the note remains.
Do not reset its data or reinstall it during this check.
```

Resetting the app's data while testing persistence would change what you are measuring.

## Review the result

Ask Cursor to distinguish what it observed from what it couldn't test.

A useful report identifies the app and build it used, lists the cases it exercised, and says what happened in each one. Any blocked case should stay marked as blocked.

You can ask for this format:

```text
For each test, report:
- the action you performed
- the expected result
- the result you observed
- whether it passed, failed, or was blocked

Include the relevant screenshot for a failure.
List any cases you did not run.
```

Read the diff too. A successful click-through doesn't tell you whether the fix changed unrelated behavior.

Keep automated tests for the logic you need to check repeatedly. A unit test can exercise note validation with many inputs. Computer Use helps you check whether the running interface connects the field and button to that logic correctly.

The free [testing course](https://flaviocopes.com/courses/testing/) explains how to choose tests for different kinds of failures.

## Browser, local desktop, or cloud agent?

Cursor has several ways to interact with a running application. Choose the one that matches where your app runs.

| Your task | Where to start |
|---|---|
| Test a website's form and inspect console errors | Cursor's built-in Browser |
| Interact with a native desktop app or iOS Simulator | Computer Use |
| Let an agent test in Cursor's remote environment | Cloud Agents |
| Run a cloud agent's tools on hardware you own | Self-hosted machines |

The [Browser tools](https://cursor.com/docs/agent/tools/browser) include console and network inspection, which are useful when debugging a web application.

[Cloud Agents](https://cursor.com/docs/cloud-agent/capabilities) have their own desktop environment in a remote VM. That desktop is separate from the apps running on your laptop.

A [self-hosted worker](https://cursor.com/docs/cloud-agent/self-hosted/computer-use) is another setup. It supports computer use on macOS and Linux, enabled with `--computer-use`. You don't need to set up a worker just to follow the local workflow in this tutorial.

I covered that option in [running Cursor cloud agents on your own Mac mini](https://flaviocopes.com/cursor-self-hosted-agents/).

## How I would use it

I would use Computer Use after changing a user-facing flow, especially when testing requires moving through several screens.

For a notes app, I'd ask for the save and reopen sequence we used here. For a settings window, I'd change a preference, close the window, and reopen it to check the value.

I'd keep each task small enough to review. Once the agent has proved it can test one flow reliably, I would add the next one.

I would also use a separate test machine or VM when the task needs to restart apps or manipulate desktop state. That's how I keep [Mac app testing from interrupting my work](https://flaviocopes.com/mac-test-vm/).

Computer Use is less useful for checking a pure function or an API response. Those are easier to test directly. Save the UI interaction for behavior that depends on the running interface, and ask the agent to show the steps it completed.