I’m trying to use Remote Control with the new iOS app, but handed-off sessions from my mac desktop app never appear on my phone… or in a browser at cursor.com/agents.
The agent only ever runs locally. I’ve done a fair bit of troubleshooting and would love a definitive answer on whether I’m doing something wrong here?
Setup:
Cursor desktop 3.9.16 on macOS
Plan: Ultra
Repositories are hosted on Bitbucket, but I work on local repo clones and then push manually to bitbucket, so I don’t have a ‘source control’ connection set up in Cursor, I prefer to push manually.
What I did:
Enabled Remote Control in Settings → Agents.
Started an agent, selected /remote-control from the command menu, and sent a message.
The agent runs and replies in the desktop app, but the session does NOT show up at cursor.com/agents or in the iOS app.
Troubleshooting already done:
Confirmed I’m signed into the same account on desktop and iPhone.
Confirmed network reachability to api2.cursor.sh and api2direct.cursor.sh.
Fully stopped the background worker process and let a brand-new one start. It still behaves the same.
Quit and reopened the desktop app, refreshed the browser, restarted the iOS app
The worker daemon log consistently reports:
User ghost mode meta={ghostMode: true, bridgeType: “privacy”}
and registers as a private worker, but the session never reaches the cloud.
Privacy setting:
My account privacy control offers two options: “Share Data” and “Privacy Mode”.
I’m on “Privacy Mode”, which states “No training. Code may be stored for Background Agent and other features.”
My questions:
Should Remote Control work while on “Privacy Mode”, or does it specifically require “Share Data”?
Is this failing because I haven’t added a source control connection to Bitbucket? And does Remote Control fully support Bitbucket Cloud, or only GitHub/GitLab?
Privacy Mode vs Share Data: Remote Control works fine on Privacy Mode. It does not require Share Data. The only privacy setting that disables it is the older Legacy privacy mode (the one that turns off cloud data storage entirely), and your account isn’t on that. The ghostMode: true / bridgeType: "privacy" lines in your worker log are expected and normal for Privacy Mode. They’re not an error and not the cause. (Docs)
Bitbucket / no source-control connection: also not the cause. Remote Control runs the agent on your machine against your local checkout. It doesn’t clone your repo in the cloud the way Cloud Agents do, so it doesn’t need a connected GitHub/GitLab/Bitbucket integration. It just needs the folder to have a normal git remote, which is host-agnostic, so Bitbucket is fine. A source-control connection only matters for Cloud Agents.
So what’s actually happening: the handoff of your local session up to the cloud isn’t completing, which is why the agent runs locally but never shows up on the web or in the app. That’s on our side. Remote Control is newly launched (public beta) and we’re actively hardening its reliability right now.
A couple of things worth trying:
The most useful test is to run it once on a genuinely clean network, e.g. your phone’s hotspot, with any VPN, corporate proxy, or security/antivirus software turned off. The worker’s connection to our cloud is a long-lived one and more sensitive than a basic reachability check, so even though api2.cursor.sh and api2direct.cursor.sh reach fine, something on the network path can quietly drop it. (Side note: the HTTP/2 disable settings won’t affect this particular connection.)
Before you retest, fully quit Cursor (Cmd+Q), make sure no leftover worker process is still running, then reopen and start a fresh /remote-control session rather than converting an existing chat.
If it still doesn’t show up on a clean network, reply here with the full worker log you referenced and I’ll dig in from there.
I’ve now tried multiple wifi networks inc phone hotspot, quitting all workers and restarting cursor. The issue is now different… now when I type /remote-control on a fresh session, sometimes this command doesn’t show up in the popup list at all… and then if I restart Cursor again when it does show up I can’t actually select it, it just closes the list without it being selected.
I’m on the latest version of Cursor available to me - 3.9.16
Is there a private way for me to send you any log files if that would be helpful?
UPDATE - this has started (partially) working after updating the Mac App to v3.10.20 and the iOS App to v1.2.0
@mohitjain FYI I’m still seeing some of the issues above - sometimes the /remote-control command doesn’t show up in the list at all, and then sometimes after restarting the mac app its shows up again… one flow that recreates it every time for me is having a workspace folder connected to a folder on my mac which isn’t a bitbucket repo clone, just a folder of personal items, pdfs etc used for personal agent work not coding - this never allows remote control to be chosen. Are you guys aware of this bug?
Thanks for the update, and glad it’s mostly working now!
The folder that never lets you pick /remote-control isn’t a bug. Remote Control currently only works in a Git-backed workspace (one with a Git remote), so a plain folder of files that isn’t a git repo won’t show the option at all. It’s listed under Current limitations here: Cursor for iOS.
The flakiness in your actual repos (the command sometimes missing, or showing but not selecting) is a separate, known rough edge. Remote Control warms up a worker in the background when you open a workspace, and the command only becomes usable once that’s ready. When it shows but selecting does nothing, it’s usually still warming up. A couple of things that help:
Give the workspace a few seconds to finish loading after you open it, then run /remote-control.
If it’s still stuck, fully quit Cursor (Cmd+Q) and reopen.
It’s still in beta, so we’re smoothing these edges out. If it keeps failing in a proper Git-backed repo even after warm-up, drop the worker log from that session here (or email [email protected] and reference this thread if you’d rather not post it publicly) and I’ll take a look.
