Trying to set up agent handoff but the /remote-control command is missing. Running latest version of Cursor though. Tried it in standalone Agents window, as well as in a project window > Agent.
Steps to Reproduce
Open Cursor
Open project or “Try new window for running parallel tasks”
Select New Agent
Enter /remote-control in Agent field
Tried it on a variety of projects (github / gitlab based, non-git etc.)
Expected Behavior
Expect to see the /remote-control slash command and be able to handoff to mobile / web for remote control
First, please make sure you have remote control enabled here: https://cursor.com/dashboard/cloud-agents. Enabling remote control will also enable the self-hosted pool toggle.
Thank you @kevinn, in fact I had those enabled, but it appears the way my projects were set up was blocking the “Remote Control” from appearing. Specifically, the projects were set up as the project root folder with several git repos inside. It only worked after I created a new workspace and added the repos individually inside it. (yay!)
However, I’m not sure why the limitation? This isn’t (or shouldn’t be) git/cloud env-dependent, I expected it to be merely a proxy to my local agent, regardless of the project’s or agent’s root. Eg. I often use Cursor for non-dev tasks where I use it simply as a “claude code” drop-in in any folder that I need to work in (like arranging files, folders, documents, audio/video cutting, etc.). And often times I simply want to use my Cursor as an “OpenClaw” or “Hermes” because I have so many custom local integrations / skills set up. So I was really hoping iOS app will allow me to do exactly that (spin up agents on my Mac from my iPhone). Seems like we’re not quite there yet But I appreciate the direction
Today, converting a session hands it off to a private worker on your machine, and that handoff is tied to a git repo detected at the workspace root. Your original setup was a root folder with separate repos nested inside, so the root itself had no repo to bind to, and the option stayed hidden. Adding each repo as its own workspace folder gave each a detected repo, which is why it appeared.
The part you wanted is coming: an upcoming update drops the git requirement, so Remote Control can bind to the workspace itself. Plain non-git folders (and folders that just contain other repos) will surface it without the workaround, which is exactly the “drop-in agent in any folder” case you described.
This will probably ship in 3.11.x, and until then, the individual-folder approach is the way to get it today
Hi @kevinn thanks for the explanation here. As a user who has been struggling with Remote Control in the last few days, I wanted to share my 2 cents.
This feature seems way too complicated to use. I would expect any session I start locally (either in the Agent window or the Editor window) to be visible on mobile. If my computer is online, the mobile app would establish a connection with my computer and send my prompts over for execution as if I were sitting in front of the computer.
The fact that I need to pick between “This Mac” and “This Mac (Remote Control)” makes me think this is not the way this is implemented. It seems the local session needs to be “committed” to the Cloud before remote control works; is that right?
I am sure there are technical reasons why it does not work as smoothly as I would expect. Just wanted to share my feedback.
Regarding your main question, you have the gist correct. When a session becomes remote-controlled, Cursor does create a cloud-side representation of it, and that representation is what your phone and the web app actually connect to. So the session is “registered” with the cloud in that sense. What it does not do is upload your code to a cloud machine and run it there. Every tool call (editing files, running terminal commands, and so on) is routed back down to a small worker running on your Mac and runs against your local files, so your working tree never leaves your computer. The cloud coordinates the session, but the real work still happens on your machine.
That split is also why you see “This Mac” versus “This Mac (Remote Control)”. A plain “This Mac” session lives entirely inside your desktop app, with no cloud-side representation, so nothing outside that window can see or drive it. Picking Remote Control is what creates the cloud connection point and wires up the local worker so your phone can attach. Today, that setup carries enough overhead that we make it an explicit choice per session rather than doing it automatically for every local agent.
The iPhone app and the remote control feature is public beta, so we are still working to refine it and we appreciate your feedback here
FWIW I’ve just gone looking for remote control, and discovered to my surprise and dismay that it’s all based on remote agents linked to a git repo.. i’m sure that’s a fine feature, but i was expecting the (to me) more obvious and immediately useful feature of just letting me view and interact with the same agent conversations that are open on my computer, from my phone. Basically proxy the agents window interface to my mobile browser somehow. Please add something like this! I want to check and talk to my existing agents from my phone when afk.
But I appreciate the direction