Title: Cloud Agent on self-hosted worker: Azure DevOps SSH repo label does not match repository URL

[Emir_Hadzimahmutovic]

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Starting a Cloud Agent against a self-hosted worker for an Azure DevOps repo fails with:
Private-worker repo label does not match the repository URL
This only happens for the Azure DevOps checkout. GitHub repos on the same machine, same CLI, same agent worker start flow work.
The worker connects and registers. The failure is routing/claim, not worker startup.
Root cause: the worker CLI and Cursor cloud derive different repo identities from the same Azure DevOps origin.

• Local origin: [email protected]:v3/{org}/{project}/{repo}
• Worker-derived repo label: ssh.dev.azure.com/v3/{org}/{project}/{repo}
• Cloud / Azure DevOps integration canonical URL: https://dev.azure.com/{org}/{project}/_git/{repo}
• Cloud also documents Azure repos as {project}/{repository} and org/project/repo
  Those strings never match. Changing origin to HTTPS would break SSH-key git access (no ADO HTTPS credentials on the machine), so that is not a usable workaround.
  This setup worked until recently. Nothing local changed: same SSH remote, same worker dirs, same script. The agent CLI on the worker was 2026.10.14-941492e (15 Oct). Updating to 2026.11.11-b912975 and restarting the worker did not change the label. The new CLI still has no Azure-specific URL canonicalization (ssh.dev.azure.com / v3/... → dev.azure.com/.../_git/...). Known hosts in the worker repo-label parser are still GitHub/GitLab/Bitbucket/etc. only.
  This is the same family as:
  Remote Control handoff fails for self-hosted Git on a non-standard port: worker repo label mismatch between client CLI and cloud
  (worker CLI vs cloud normalize the same git origin differently.)

Steps to Reproduce

1. Clone an Azure DevOps Services repo over SSH:
   [email protected]:v3/{org}/{project}/{repo}
2. Start a My Machines worker on that checkout:
   agent worker --name {worker name} --worker-dir /path/to/repo start
3. Worker log: Derived repo label from git origin → ssh.dev.azure.com/v3/{org}/{project}/{repo}
4. On cursor.com/agents, select that Azure DevOps repo (connected via Azure DevOps integration) and send the run to the self-hosted worker.

Expected Behavior

Cloud should treat Azure DevOps SSH (ssh.dev.azure.com:v3/{org}/{project}/{repo}) as the same repo as https://dev.azure.com/{org}/{project}/_git/{repo} and claim the already-connected worker.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

• Cursor IDE: 3.29.15
• Agent CLI: 2026.11.11-b912975 (also reproduced on 2026.10.14-941492e)
• Worker id: 3b5d0a32-d525-43b2-96d2-936fcec99732

Additional Information

Worker debug (after CLI update, still the SSH label).

Does this stop you from using Cursor

Yes - Cursor is unusable

[Colin]

Hi @Emir_Hadzimahmutovic, this is on our side, and updating the CLI won’t change it. The cloud now converts Azure DevOps SSH remotes to the https://dev.azure.com/{org}/{project}/_git/{repo} form when a run starts, but your worker’s label is still compared in its SSH form, so the start gets rejected. I’ve passed this to the team.

As a workaround, you can point origin at the HTTPS form and have git keep using SSH underneath, so your keys still work:

git remote set-url origin https://dev.azure.com/{org}/{project}/_git/{repo}
git config url."[email protected]:v3/{org}/{project}/{repo}".insteadOf "https://dev.azure.com/{org}/{project}/_git/{repo}"

Then restart the worker. Its log should show the derived repo label as dev.azure.com/{org}/{project}/_git/{repo}, and git fetch should still go over SSH. Let me know if the run is still rejected after that.