Remote Control fails silently on Bitbucket — handoff never reaches iOS

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor for iOS

Describe the Bug

Remote Control does not work with my Bitbucket repository.

I attached a screen recording showing the full behavior (dropdown select doing nothing, then normal chat, then /remote-control with no session on iOS).

On Cursor Desktop (Agents window, Glass layout), behavior is inconsistent:

  1. In a new/empty agent chat, if I type /remote-control, it appears in the slash-command dropdown. When I select it from the dropdown, nothing happens — no handoff, no message sent, no error.

  2. If I first send a normal message (e.g. “hello”) and the agent replies, then /remote-control is recognized as a slash command. But the session still never appears on my iPhone.

  3. If I paste and send “/remote-control hello” as one line, there is no normal AI reply (expected for the handoff path), then after a few seconds nothing happens and there is no error in the UI.

The session never appears in the Cursor iOS app inbox when signed in with the same account.

Normal desktop agent chat works fine. Only the Remote Control handoff fails.

SCM: Bitbucket ([email protected]:/.git).

Steps to Reproduce

  1. Open a Git-backed Bitbucket workspace in Cursor Desktop (Agents window).
  2. Go to Settings → Agents and enable Remote Control.
  3. Start a new agent chat.
  4. Type /remote-control and send it.
  5. Send a follow-up message (e.g. “test from iPhone”).
  6. Open the Cursor iOS app on the same account and check the inbox.

Expected Behavior

After /remote-control and a follow-up message, the agent session should be handed off to my machine’s worker and appear in the Cursor iOS inbox, so I can continue directing the same session from my phone while tools run on my Mac.

Operating System

MacOS

Version Information

Cursor: 3.9.16
VS Code Extension API: 1.105.1
Commit: 042b3c1a4c53f2c3808067f519fbfc67b72cad80
Date: 2026-06-27
Layout: Glass / Agents window
OS: Darwin arm64 25.5.0 (Apple Silicon)

Additional Information

  • Canonical Bitbucket remote URL ([email protected]:/.git)
  • Privacy Mode Active (not Legacy)
  • Remote Control enabled under Settings → Agents
  • Reloaded Cursor window
  • Confirmed on latest stable 3.9.16 (no newer update available)

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Thanks for moving Bitbucket to a separate thread, as agreed.

This is the same issue as in the main thread: resolving the target for non-GitHub remotes was failing, so /remote-control silently did nothing and the session never reached iOS. Good news: the fix for parsing non-GitHub URLs landed in a build newer than 3.9.16 (you’re currently on 3.9.16). It’s provider-agnostic, so Bitbucket should be covered by the fix.

Once you update to a build newer than 3.9.16, please rerun your test using the same steps and reply here with whether the session reaches iOS. If it’s still silent on the new build, we’ll collect Bitbucket-specific details separately.

6

Update after upgrading to 3.10.11

I updated from 3.9.16 to 3.10.11 and retested Remote Control on my Bitbucket repo. Behavior changed, but it still doesn’t work end-to-end.

Inconsistent slash-command behavior

In a new/empty agent chat:

  • I type /remote-control nothing happen
  • When I select it from the dropdown, nothing happens — no handoff, no message sent, no error, Remote Control does not enable

After I send a normal message first (e.g. “hello”) and the agent replies:

  • Selecting /remote-control from the dropdown is then recognized
  • Handoff appears to start (keep-awake activates)
  • But it fails with the error below, and the session never appears on my iPhone

Error (after hello + dropdown select)

Request ID: bc-1fd4c495-2f19-4d9c-8f00-a2d7dda7e542

{"error":"ERROR_BAD_REQUEST","details":{"title":"Bad Request","detail":"environment_id is invalid for the current user/team",...}}

ConnectError: [invalid_argument] environment_id is invalid for the current user/team
    at startBackgroundComposerFromSnapshot

Steps to reproduce

  1. Open Bitbucket repo in Cursor Desktop (Agents window, Glass layout)
  2. Settings → Agents → Remote Control enabled
  3. Start a new agent chat
  4. Type /remote-control → select from dropdown → nothing happens
  5. Send “hello” → wait for agent reply
  6. Select /remote-control from dropdown again → error above, no session on iOS
  7. Open Cursor iOS app (same account) → inbox empty

Setup

  • Cursor: 3.10.11
  • Plan: Pro+
  • Privacy: Privacy Mode Active (not Legacy)
  • SCM: Bitbucket
  • OS: macOS, Apple Silicon
  • Screen recording from original report still applies; happy to attach an updated one showing the 3.10.11 behavior

What I tried

  • Brand-new agent chat each time
  • Removed stuck cloud agents from cursor.com/agents
  • Reloaded Cursor window

@deanrie

7

Thanks for the update and the detailed retest. Good news, the silent no-op on Bitbucket is gone. Before, the handoff target wasn’t resolving at all. Now the handoff starts (keep-awake turns on) and we see a clear error. So the non-GitHub URL parsing fix worked.

The remaining error environment_id is invalid for the current user/team is a known one. It usually means the run is pointing to an environment that became invalid. It may have been recreated or replaced, or the repo or branch it referenced changed, and the client is reusing a stale reference. That’s why it can feel like it works sometimes and fails other times.

Step by step:

  1. Open the environment picker (Agents window in the IDE or cursor.com/agents), re-select or recreate the environment, then reload the window (Cmd+Shift+P → Reload Window) and retest. You mentioned you removed stuck cloud agents on cursor.com/agents. After that, it’s best to recreate or re-select the environment so there’s no old reference left.
  2. Check that the repo and branch the environment points to still exist.

If it still fails after recreating the environment, check the account. Make sure you’re logged into the same account in Cursor Desktop and in the iOS app. They must match. Also make sure that account is on a paid plan. Remote Control isn’t available on free accounts.

One small detail on the steps: /remote-control in an empty chat won’t do anything visible by itself. It just arms the handoff, and the next message is what gets sent to the worker, so the order pick /remote-control then send a message is correct.

Let me know what you see after recreating the environment.

8

@deanrie Follow-up after your last reply — still failing.

What I did since your message

  • Upgraded to 3.10.11
  • Confirmed same account on Cursor Desktop, Cursor iOS, and cursor.com (Pro+)
  • Re-selected environment in IDE picker (This Mac and This Mac Remote Control)
  • Reloaded window
  • Cleared stuck cloud agents on cursor.com/agents
  • Deleted all My Machines workers, quit Cursor, reopened one workspace, fresh worker registered
  • Remote-control enabled on dashboard + desktop; no source control connected (local-only)
  • Brand-new chat, retested Remote Control

Result
Still: environment_id is invalid for the current user/team at startBackgroundComposerFromSnapshot
Latest Request ID: bc-675acbdf-347f-4fe3-97ab-d7ff3edda1e2
Session still never appears on iOS inbox (same account).

Recreating/re-selecting environment and wiping workers did not fix it. For local-only Remote Control (no dashboard Git/source connection), is a server-side environment still required? Can you check this Request ID on your side?

@deanrie

image
image1912×1161 91.3 KB

image
image1912×1161 146 KB

10

Thanks for the detailed retest and the screenshots. I can see My Machines with the keevana_delivery worker, and Cloud Agents settings where the worker is registered as Unknown repository and source control isn’t connected (Default Repository = Connect Git).

First, the main point. The fix for parsing non GitHub URLs is confirmed. Before, handoff didn’t start at all. Now it gets to session creation and returns a clear error. The remaining environment_id is invalid for the current user/team on startBackgroundComposerFromSnapshot is a separate known issue and it’s on our radar. I can’t share an ETA yet. I also noted the Request ID and added it to the issue.

About your question, yes. Even in local only mode, handoff still goes through the server side background composer, which references an environment. So you still need a valid environment link even without dashboard Git connected. And I think that’s where the problem is. Since the worker comes up as Unknown repository, the environment reference might not resolve correctly.

For diagnostics, please try this. On cursor.com/agents, connect your Bitbucket repo (Connect Source Control / Default Repository), then restart the worker (remove it in My Machines, quit Cursor, open the workspace again) and rerun the test. I’m curious if the behavior changes once the worker has a resolvable repo instead of Unknown repository.

Let me know what you get. If the error stays even with the repo connected, then it’s definitely the server side environment reference, and that’s fully on our side.

11

@deanrie — Follow-up with corrected finding

Quick update since my last message.

To keep things clear, I’ll use these names:

  • Bitbucket Account A — the one I connected on the Cursor dashboard (~1 week ago), then disconnected
  • Repo A — my repo on Bitbucket Account A
  • Project A — my local project for Repo A
  • Bitbucket Accounts B, C… — my other Bitbucket accounts, never connected on the dashboard
  • Other projects — local projects on Bitbucket Accounts B, C…

What I did on Project A

I connected Bitbucket Account A on the Cursor dashboard and used web/cloud agents on Repo A. Later I disconnected Bitbucket Account A from the dashboard.

After that, Remote Control on Project A started failing with:

environment_id is invalid for the current user/team

When it worked once

I reconnected Bitbucket Account A on the dashboard, opened cursor.com/agents, saved an errored agent, then on my Mac I selected Remote Control and sent hello.

The session appeared on iOS.

  • Success: request 1a08f759-602e-4419-94dd-8d9e9f5aadaa, bcId bc-1ee401c8-...

Then I disconnected Bitbucket Account A again to test — and Project A broke again with the same error.

  • Failure: request 9dae22e2-e4f5-481f-b61c-86ecf987a832, bcId bc-c8ba3025-...

Same repo URL and worker both times. Only the dashboard connection for Bitbucket Account A changed.

What I see on my other projects

My other projects use Bitbucket Accounts B, C…. I never connected those Bitbucket accounts on the Cursor dashboard — only local git remotes.

Remote Control works on iOS for those projects.

So I don’t think this is a general Bitbucket problem. I think it’s specific to Bitbucket Account A / Repo A / Project A, after I connected it on the dashboard, used web agents, then disconnected.

Git remote and worker for Project A look correct on my side (right repo label in My Machines).

Questions

  1. When I disconnect Bitbucket Account A after using web agents, can that leave a stale environment for Repo A only?
  2. How can I reset/clear the environment for Repo A ?
12

Great troubleshooting. Your A/B test connecting Account A works, disconnecting breaks, with the same repo URL and worker is super helpful. It’s the cleanest repro we have for this issue right now.

On your questions:

  1. Yep, that’s exactly what it looks like. When you connect Bitbucket Account A on the dashboard and run web/cloud agents on Repo A, the server creates an environment tied to that repo. After you disconnect the account, the client still points to that environment, but it no longer resolves, so you get environment_id is invalid for the current user/team. Your other projects (Accounts B, C) were never connected on the dashboard, so no server-side environment was created for them, and Remote Control works there. This confirms the issue isn’t Bitbucket itself. It’s a stuck reference to the environment for Repo A.

  2. The working workaround right now is what you found. Keep Bitbucket Account A connected at cursor.com/agents. While that link is active, the environment resolves and the handoff reaches iOS. If you want to recreate the environment, with Account A connected go to cursor.com/agents, recreate or re-save the environment for Repo A, then restart the worker (remove it in My Machines, restart Cursor, and open the workspace again).

A full cleanup of the stale environment without reconnecting the account has to be done on our side. This is a known bug and it’s on our radar, but I can’t give an ETA yet. I saved both request IDs (the success and the failure) and added them to the issue.

Let me know if reconnecting Account A keeps the handoff stable. That’s an important signal.