Cursor Remote Control: Drive Agents From Your Phone

Remote Control is the official name in Cursor's docs for driving a local agent, one executing on your own machine, from your phone. It is the part of Cursor's mobile story that goes beyond cloud agents: the iOS launch post pitches launching always-on agents in the cloud, or "control agents running on your computer from your phone." Cloud agents run on Cursor's machines and never needed your desktop; Remote Control is specifically about the machine on your desk.

Local agents are where a lot of real work happens, on your own checkout with your own build caches. Remote Control means walking away from the desk without abandoning a run in progress.

The architecture is one backend, three windows onto it. An agent started on any surface shows up on the others, which is what makes handoff feel like continuing rather than reconnecting. Each surface has a distinct job.

Read the middle row as a constraint rather than a feature list. Environments, secrets, MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. servers and automations all live on the web surface, and while that page does load on a phone, authorizing an MCP server or editing a secret one-handed is not something you want to be doing. Configure the repository and watch one run finish at your desk, then supervise from the phone.

Cursor documents the requirements precisely, and each one follows from a single fact about where the work happens. Your machine executes the tool calls. The phone is the steering wheel here, and four of the six rows below are about your desktop. None is about the app.

The list is printed in a sensible order, which for a rollout is the wrong one. On Teams and Enterprise the org toggle is the gate, so it goes first; upgrading everyone to 3.9.8 and writing a runbook against a feature your admin has not switched on is work you will do twice.

On an individual plan the printed order is fine. The row people forget is enablement, since the docs put that toggle in the desktop Agents WindowCursor's surface listing your agent runs; open a run to read its diff and search transcripts from the command palette. Press Enter for the full definition. settings. I would make it a before-you-leave step, because nothing in the documentation suggests a phone can reach it.

Begin where the context is richest, at your desktop, then carry the supervision in your pocket. That handoff is what Remote Control is for. Here is the sequence end to end.

1. 1Start the run at your desk: kick off a local agent in the desktop Agents window, or a cloud agent from any surface.
2. 2Enable Remote Control in the Agents WindowCursor's surface listing your agent runs; open a run to read its diff and search transcripts from the command palette. Press Enter for the full definition. settings, and leave the machine awake and online.
3. 3Open Cursor for iOS. The same run is already listed, because the app reads the same backend.
4. 4Supervise from the phone: follow the log, answer the agent's questions, redirect with typed or dictated follow-ups.
5. 5Review the result in the app: full diffs, commits, deployments and review threads all render on the phone.
6. 6Close it out: merge with squash, toggle auto-merge, update the branch, or leave it for a desktop-grade review in the morning.

The eight in the Live Activities row is a lock-screen number. What your machine can carry is a separate question, since eight cloud runs each get their own isolated VM while eight local runs share one laptop. For several local runs, give each a worktree and keep the count to what your machine can actually build.

Whoever needs the local checkout is who needs Remote Control, because their build or their simulator lives on that machine. Everyone else is better served by cloud agents, which keep running with the laptop shut. Gating it on seniority was my first instinct and it is the wrong axis, since the most senior person is rarely the one whose environment is hardest to reproduce.

Two people can keep track of which machines are awake without writing it down. Forty cannot, and on Teams and Enterprise an admin decides who has Remote Control at all.

Work from the cheapest check to the most expensive. Is the desktop awake and online, is Remote Control still enabled in the Agents WindowCursor's surface listing your agent runs; open a run to read its diff and search transcripts from the command palette. Press Enter for the full definition. settings, is this the Git-backed workspace with a remote, and on Teams has an admin enabled the feature for the organization. Version 3.9.8 gets checked first by most people and I would check it last, since it only bites the day someone has been postponing updates.

The usual cause is a sleeping machine. A laptop on battery hits its sleep timer, the agent stops because the work was running there, and you find out when you next pick up the phone. If a run has to survive the lid closing, start it as a cloud agent instead, and fix your power settings before you trust local runs to stay up.

Bisect it with a cloud agent. If the cloud run shows up on the phone and the local one does not, your account and the backend are fine. Which narrows it to the machine you walked away from, and that usually means going back to it.

Mechanically, yes: a merge from the iOS app goes through the same pull request as a merge from anywhere else. Branch protections, required checks and code-owner rules still gate it. The app gives you the controls (merge with squash, mark ready for review, update the branch, toggle auto-merge, publish, close) and no bypass around your repo's rules.

Judgment is the harder half. A phone screen shows you a diff; it does not give you the desktop's room to read the surrounding code or run the change. In practice the line I would draw is this: supervise, comment and redirect freely from the phone, merge the small low-risk changes, and hold anything touching auth, payments, data migrations or infrastructure for a desktop review.

Write that list down, and revisit it when the app leaves beta.