I wanted to run the app on my Mac and view the live actions on my iPhone, but I haven’t been able to make it work. The remote control feature does not work regardless of what I try.
I also noticed that Cursor CLI recommends working through the web version, but I specifically want to use the Mac application and see the live actions on my iPhone.
I asked Composer for troubleshooting steps, and it only suggested disabling Privacy Mode, but that did not solve the issue either.
Hey, thanks for the report. Quick important note: Composer’s advice to disable Privacy Mode is wrong. Remote Control works with Privacy Mode in shared mode. It only gets disabled if you fully block cloud data storage, so that’s not the reason.
Your version 3.9.16 and plan Pro are supported, so it’s not that either. Let’s go step by step:
Remote Control is enabled on desktop, not in the iOS app. On Mac: Settings > Agents, then turn on Remote Control. Or in the agent input run /remote-control and send the next message, the session will be handed off to the worker on your machine.
Your Mac must stay online and logged in. You can enable Keep this computer awake.
After that, the session should show up in the iOS app inbox under the same account.
The key requirement that often breaks this: the workspace must be Git-backed, and its remote must be resolvable by Cursor Cloud. If your repo is on a self-hosted Git server like your own GitLab or GitHub Enterprise, Cursor Cloud can’t see it unless that instance is configured separately, and then the session won’t surface on your phone.
To confirm the self-hosted case: what host is your repo on? As a quick test, try Remote Control in a project whose remote is on github.com or gitlab.com. If it works there, the blocker is the self-hosted repo resolution.
When I open Settings → Agents, the Remote Control toggle re-enables itself with an animation every time. I turned it on, but it looks like it resets or reactivates itself when I open the settings again. This might be a bug.
My Git repository is hosted on the official gitlab.com, so it is not a self-hosted GitLab issue. However, I still don’t see the Remote Control session appearing on my iPhone.
Could you please check if the toggle behavior is expected or if there is a known issue with Remote Control not syncing to iOS?
Thanks for checking, and yes, gitlab.com is the key detail here. Let me clarify what I said earlier.
In my previous message I pointed at self-hosted repos, but the GitLab issue turned out to be broader. It affects the official gitlab.com too, not just self-hosted. So the test “try on gitlab.com” would not isolate it in your case, since it also failed on gitlab.com.
First, an important distinction. Remote Control is not Cloud Agents. Remote Control runs an agent on your local machine and streams view and control to your phone. Nothing gets cloned to the cloud. So GitLab restrictions for Cloud Agents are not relevant here.
This specific case is a known Remote Control issue. The client was parsing GitLab repo URLs incorrectly. The parser was tailored for GitHub. It dropped the session during handoff to the worker, so it never showed up on the iPhone. This is not caused by your settings. The fix is already merged internally, but it was not included in 3.9.16 released on June 27. It should land in one of the next updates. After you update, please try again.
To confirm the blocker is GitLab. If you have a project with a remote on github.com, run Remote Control there. If the session appears on your phone, then the cause is exactly the GitLab URL parsing.
Two more things so we do not have to guess:
What layout are you using, Glass or the classic editor? Remote Control depends on Glass.
About the toggle in Settings > Agents. The “turning on” animation each time you open the panel might just be a UI redraw, not a real reset. Please share a short screen recording showing open settings, show the toggle, close, reopen. I want to confirm whether the setting is actually resetting to off. If it is, that is a separate issue and we can dig into it.
I tested it with a GitHub repository, and Remote Control worked there. Thank you for helping me identify the issue.
Now I have another limitation: I can’t use a custom model with Remote Control. If possible, could you consider adding support for custom models in future updates? This would make the feature much more useful for my workflow.
The GitHub test cleared things up. It confirms the issue is in how Remote Control parsed the GitLab repo URL during handoff. This is a bug on our side, not your settings. The fix is already merged and should ship in one of the next updates. After you update, please try again with the GitLab repo.
About the toggle in Settings > Agents, based on the video, that looks like a UI redraw animation when the panel opens, not an actual reset. Since Remote Control worked with a GitHub repo, the toggle is really enabled and working. If you ever notice it actually turning off in practice and handoff stops working after you’ve enabled it, let me know and we’ll dig in separately.
Regarding custom models in Remote Control, that isn’t supported right now.
Title: Remote Control fails silently on Bitbucket (same as GitLab URL parsing bug?)
Where does the bug appear?
Cursor for iOS + Cursor Desktop (Remote Control)
Describe the bug
Remote Control does not work with my Bitbucket repo. When I run /remote-control (with or without a follow-up message), nothing useful happens: no agent response, and the session never appears in the Cursor iOS inbox. Normal desktop agent chat works; only the handoff fails.
Symptoms match the GitLab Remote Control issue in this thread (non-GitHub repo URL parsing during handoff).
My setup
Cursor Desktop: 3.9.16
Plan: Pro+
Privacy: Privacy Mode Active (not Legacy)
Remote Control: enabled (Settings → Agents)
Layout: Agents window (Glass)
SCM: Bitbucket ([email protected]:<org>/<repo>.git — details available to staff if needed)
OS: macOS, Apple Silicon
Steps to reproduce
Open a Git-backed Bitbucket workspace in Cursor (Agents window).
Enable Remote Control.
New agent chat → /remote-control → follow-up message.
Check Cursor iOS inbox (same account).
Actual behavior
/remote-control recognized as slash command; no normal AI reply.
After a few seconds, silent failure — no UI error.
Session never appears on iPhone.
Worker stays connected; Remote Control handoff never completes.
I’m getting an error when I’m trying to start a remote local agent from my phone. The error is “You don’t have access to this repo anymore.”. Everything is fine with the access and the toggle in settings is enabled.
If I start a local agent and try /remote-control, it just doesn’t have any effect — neither does the session ever appear on the phone, nor does Cursor locally provide any output (no errors or any reaction). Everything is in the latest versions.
About the GitLab case: this is a confirmed bug in how Remote Control parsed the repo URL during handoff. The fix is already merged, but it did not make it into 3.9.16 released on June 27. It’ll land in one of the next updates. After you update, please try again with your GitLab repo.
@ZuniShahid: important note. The merged fix was made specifically for GitLab, so I can’t guarantee it will also fix Bitbucket. Your symptom looks similar, but to avoid mixing different providers in one thread and to track it properly, please open a separate Bitbucket thread. In that thread, also share the result of a quick test: run Remote Control on a project that has a remote on github.com. If the session shows up on your phone, then the blocker is specifically Bitbucket URL parsing, and it’s likely the same class of issue.
@Roman_Mogylatov: your case is different. “You don’t have access to this repo anymore” when starting from the phone is a different error, not GitLab URL parsing. Please open a separate thread and include: which Git provider the repo is on, your desktop and iOS app versions, and the Request ID in chat menu in the top right > Copy Request ID. Also mention that hitting /remote-control locally does nothing, we’ll look at that separately.
@HelKyle: can you confirm which provider your repo is on GitHub, GitLab, Bitbucket, or self-hosted and your desktop plus iOS versions. If it’s GitLab, please wait for the next update as described above. If it’s another provider, it’s better to open a separate thread.
@deanrie Just out of curiosity, why does the Remote Control feature depend on the Git server? I noticed you mentioned ‘parsing the repo URL during handoff’ — does it use the remote URL as a unique identifier to sync the session between desktop and mobile? (Asking because I use a self-hosted Git server and want to know if it will be supported).
I’ll answer right away about self-hosted and the Git question.
@HelKyle - yep, that’s correct. Remote Control uses the git remote URL as an identifier to match and link the session between desktop and phone during handoff. If the remote can’t be parsed correctly, the session won’t show up on the phone. That’s exactly why GitLab was broken: the parser was built for the GitHub URL format.
Important note about the merged fix: it’s made specifically for gitlab.com. Self-hosted servers (self-hosted GitLab, Gitea, etc.) are a separate case, this fix doesn’t cover them, and I can’t give any guarantees for that right now.
@fabricioereche - same for Gitea: it’s self-hosted, so it’s a separate story from gitlab.com parsing.
To avoid mixing different providers in one thread (we already have GitLab, Bitbucket, self-hosted here) and to track things properly, please open a separate thread for self-hosted Remote Control. In that thread, include:
Which server you’re using (Gitea, self-hosted GitLab, etc.) and its host.
Desktop and iOS app versions.
Result of a test on a github.com repo: start Remote Control there. If the session shows up on the phone, then the blocker is specifically the URL parsing for your self-hosted server.
One more thing to check in the same test: if the session doesn’t show up even on github.com, try once on a clean network, like a phone hotspot, with no VPN, corporate proxy, or antivirus. The worker keeps a long-lived connection to the cloud, it’s more sensitive than a basic connectivity check, and something on the network path can silently drop it even if domains ping fine. The disable HTTP/2 setting doesn’t affect this specific connection. This helps separate a URL parsing issue from a network blocker for handoff.