Remote Control handoff fails for self-hosted Git on a non-standard port: worker repo label mismatch between client CLI and cloud

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Summary

Remote Control handoff never reaches the iOS app. The worker registers successfully (the machine shows up in the iOS app), but every session handoff fails with No self-hosted worker matched the requested labels.

Root cause: the worker CLI and the cloud handoff path derive the repo label from the same git origin URL using two different normalization rules, so the labels never match.

The mismatch

Same origin URL: http://<self-hosted-host>:<non-standard-port>/MyOrg/MyRepo.git

  • Worker (desktop CLI) derives: repo = "<self-hosted-host>:<non-standard-port>/MyOrg/MyRepo"
    • keeps the non-standard port
    • keeps original path casing
  • Cloud handoff side requests: repo = "<self-hosted-host>/myorg/myrepo"
    • drops the port
    • lowercases the path

These two labels can never match, so the session is never routed to the registered worker.

Steps to Reproduce

Reproduction

  1. Use a workspace whose git origin is a self-hosted Git server on a non-standard port with mixed-case path, e.g. http://<self-hosted-host>:<non-standard-port>/MyOrg/MyRepo.git
  2. Enable Remote Control in the Agents Window (Settings → Agents)
  3. In an agent session, run /remote-control and send a follow-up message
  4. Worker registers fine; the machine appears in the iOS app under the same account
  5. Session never appears in the iOS inbox; the cloud returns No self-hosted worker matched the requested labels: repo=<self-hosted-host>/myorg/myrepo, ...

Expected Behavior

Expected

Both the worker CLI and the cloud handoff path derive the repo label with the same normalization, so the handoff matches the registered worker. For self-hosted servers, the host:port is part of the repository identity and should not be dropped.

Operating System

Windows 10/11

Version Information

Environment

  • Cursor: 3.10.20 (system setup), build 2026-07-07, commit 23b9fb2
  • VS Code Extension API: 1.125.0
  • Electron: 40.10.3 / Chromium: 144.0.7559.236 / Node.js: 24.15.0
  • OS: Windows_NT x64 10.0.26200
  • Plan: Ultra (paid)
  • Workspace: local, git-backed, origin points to a self-hosted Git server on a non-standard port (not GitHub/GitLab/Bitbucket cloud)
  • Remote Control: enabled in Agents Window (Settings → Agents)

Additional Information

Logs (sanitized; real host/port/org/repo replaced with placeholders)

Worker side (cursor-agent-worker daemon log):

INFO  Derived repo label from git origin meta={repo: "<self-hosted-host>:<non-standard-port>/MyOrg/MyRepo"}
INFO  Worker registration arguments meta={... x-repository-url: "http://<self-hosted-host>:<non-standard-port>/MyOrg/MyRepo.git", x-worker-labels: [{key: "name", value: "<worker-name>"}, {key: "repo", value: "<self-hosted-host>:<non-standard-port>/MyOrg/MyRepo"}], x-shared-assignment-allowed: "true"}

Handoff side (error returned to the iOS app / cloud):

No self-hosted worker matched the requested labels: repo=<self-hosted-host>/myorg/myrepo, name=<worker-name>, cursor.private_worker.shared_assignment_allowed=true.

Note the two differences in the cloud-side label vs the registered one:

  1. port :<non-standard-port> is dropped
  2. MyOrg/MyRepo is lowercased to myorg/myrepo

Why user-side workarounds don’t fix it

  • Renaming the repo to all-lowercase removes the casing difference but the port mismatch remains.
  • Moving the Git server to a standard port (80/443) removes the port difference but the casing difference remains.
  • Both have to be changed at the same time, server-side, affecting the whole team — not a reasonable ask for a client-side feature.
  • Changing the local origin URL doesn’t help because the port is the real service port; altering it breaks fetch/push.

Suggested fix

Normalize the repo label identically on both paths, or match labels case-insensitively and treat an explicit standard port (80/http, 443/https) as equal to no port — while still treating a non-standard port as a significant part of the identity. Today the worker CLI and the cloud use two different normalizers for the same URL, which is the bug.

Additional context

This is the same family of issues previously reported for GitLab and Bitbucket (URL parser was GitHub-shaped). The non-GitHub URL parsing fix that landed after 3.9.16 got the handoff started (worker registers, machine shows up on iOS), but the label normalization divergence above still prevents the session from actually matching the worker.

This is still reproducible on the latest stable build (3.10.20, 2026-07-07) — the non-GitHub URL parsing fix got the handoff started (worker registers, machine shows up on iOS), but the label normalization divergence still prevents the session from matching the worker.

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Hey there,

Your diagnosis is right: the desktop Remote Control handoff and the worker build the repo label from the same origin differently, and for a self-hosted server on a non-standard port the handoff side drops the port, so the two labels can’t match. That’s a real bug on our side, separate from the casing mismatch, and I’m flagging it with the team to track.

In the meantime, the cleanest unblock is to start the session from cursor.com/agents instead of the desktop /remote-control handoff. That path builds the repo identity without dropping the port (or changing its casing), so it should route to your already-registered worker - and once it’s running you can drive it from the iOS app as usual.

If the session still doesn’t land on the worker from the web, let me know and I’ll dig in further.